The model of git feels very nice and intuitive once you grasp the central architecture - an immutable append-only content-addressed file system. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. > And I feel it in my bones that there is a revolutionary GUI waiting to be invented. it will never be as good as Git for detecting file moves, because Git is happy with a soup of blobs, whereas Pijul needs more structure (but OTOH that extra structure makes Pijul much better at "blame").
#GITKRAKEN DIFF FULL#
We just released the first full implementation a few weeks ago. it's not yet as efficient as Git for storage, but we're working on it. That said, there are still a few problems: Since there can be no "bad merge", you don't have to think about your version control system anymore, and can focus on your work. It is as powerful as Git, but beginner-friendly, infinitely faster to learn, and more flexible.
#GITKRAKEN DIFF PATCH#
If you have a patch solving a conflict between two other patches, then the conflict is solved forever, and doesn't "come back".Īs a conclusion, I'd say Git might be too technical for a normal programmer (which is why we have giant threads like this one on HN), but Pijul is the exact opposite. Sure, it sounds like `git revert`, except that `git revert` can sometimes screw things up very badly (if you `git revert` a merge commit, for instance).Īlso, in Pijul, conflicts are the normal state, so you don't need anything like `git rerere`, and two users with the same patches (even in different orders) will always see the same conflicts. "Inverses": in Pijul, all patches have inverses. Also, cherry-picking becomes the default, you don't even have to think about it. This property means that "rebasing" becomes much simpler: it's just the action of applying and unapplying patches. Applying them in any order will always yield the same result, so you can push any of them, no matter the order in which you made them. In Pijul, two patches that you could produce on different branches are "independent" anyway. "Commutativity" is also a concept of algebra, but in practice in version control, it means that you don't have to think about feature branches. If Alice pulls B, and then pulls C, associativity means that she'll get the same as pulling B and C together. "Associativity" is a concept of algebra, but when applied to version control, it just means the following: let's Alice makes a commit A, and Bob makes two commits B and C. The math can be completely ignored by the user, it is just a way to guarantee that the tool will always match the basic intuition of version control. Our goal is to make something much much easier to use than Git, and we're already succeeding in doing that. Collapsing the branch view as described will then result in the panel using >90% screen width.I'm one of the authors. This allows to pin the desired panel to the bottom when GK is in full screen mode. "Pinning to the bottom", as mentioned above, is available via button since GitKraken release 3.1.0. Or do you mean the diff itself, showing in-file changes? Collapsing the branch view on the left also helps here, although there's no way I know of to hide the file view on the right panel. If that was the panel you meant, switching from Path to Treeview might also help Doing that, the file view will cover about 90% of your screen width. You can also collapse the branch view on the left by clicking the little arrow on top of the panel.
I think that might be what you already did. The list of files? You can expand that to about 2/3rds of the screen by pinning it to the bottom and dragging the top border up. It's not clear which panel you're talking of.
0 kommentar(er)
