19
Why Git is hard
(roadrunnertwice.dreamwidth.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 Oct 2023
19 points (88.0% liked)
Git
2632 readers
1 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 1 year ago
MODERATORS
Git is a hack that was created by a bunch of kernel hackers with a UI that wasn't originally meant to be the final user-facing UI. If you have done what the kernel devs do, you would understand git. That includes:
There were a whole bunch of ad-hoc kernel dev operations that got consolidated in git. Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases. (No. xkcd doesn't apply here. Git does everything. It just needs a better design).
With regards to Git I'm a victim of Stockholm syndrome, thus it's hard for me to see where are all those alleged unintuitive design choices.
This analysis is rendered even more difficult as these criticisms of Git are depicted in vague terms without mentioning a single concrete example.
To make matters worse, these accusations become even less credible given the fact that all other Git competitors seem to copy Git's user interface almost verbatim. This means Git must be doing something right.
So given this issue, is there any concrete example of where Git is lacking in the UI department?
I had a really pleasant experience using mercurial. Some of the things git may be missing:
commit -i. Arrow keys quickly fold and unfold files/chunks/individual linespubliccommits were seen by other people and are considered immutabledraftcommit is your regular WIP local commit and can't be a parent to apubliccommit.secretcommit with your printf debugging won't be uploaded by accidentrebase, your previous commits are markedobsoleteand hidden from most UI. For an obsolete commit it is easy to find it's updated version. The graph of obsolete revisions is an orthogonal DAG on top of the regular commit DAG.git add -pmight not have a fancy TUI interface but it supports picking files/chunks without an issue. I'm not sure how this could be described as a UI problem.I'm not sure how that would be useful in Git's perspective. In Git, public commits are commits pushed to a shared remote repository, and draft/secret commits are just local commits that you don't push. I'm not sure what value those specialized types of commits add.
Git's approach sounds simpler, consistent, and coherent, and thus simple to learn. I'm not sure what was gained by pushing that level of complexity onto Mercurial.
I'm also not sure if that makes sense. If you rebased a branch, you don't expect the original branch to stay there. As the name implies, what you want to do is to replay a sequence of commits onto another branch. In the rare cases you wish to keep the original branch in place, you just create a new branch alongside the old branch and rebase the new one instead.
Keeping the old branch in place after rebasing it feels inconsistent and illogical.