this post was submitted on 07 Oct 2023
19 points (88.0% liked)

Git

2874 readers
16 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

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. 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
Ategon@programming.dev
canpolat@programming.dev
jnovinger@programming.dev
19
Why Git is hard (roadrunnertwice.dreamwidth.org)
submitted 1 year ago* (last edited 1 year ago) by canpolat@programming.dev to c/git@programming.dev
8 comments fedilink hide all child comments
top 8 comments
sorted by: hot top controversial new old
[–] technom@programming.dev 8 points 1 year ago (2 children)

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:

  • Taking snapshots of the source tree (perhaps as a zip or tar), along with a file that indicates what snapshot was for, you understand trees.
  • Applying patch queues (with something like quilt), you understand commits, rebasing and cherrypicks.
  • Reversing a patch - you get reverts.
  • Modifying a patch - you get commit amends.
  • Do a 3 way merge - that's a git merge.

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).

[–] o11c@programming.dev 9 points 1 year ago

I've only ever seen two parts of git that could arguably be called unintuitive, and they both got fixes:

  • git reset seems to do 2 unrelated things for some people. Nowadays git restore exists.
  • the inconsistent difference between a..b and a...b commit ranges in various commands. This is admittedly obscure enough that I would have to look up the manual half the time anyway.
  • I suppose we could call the fact that man git foo didn't used to work unintuitive I guess.

The tooling to integrate git submodule into normal tree operations could be improved though. But nowadays there's git subtree for all the people who want to do it wrong but easily.

The only reason people complain so much about git is that it's the only VCS that's actually widely used anymore. All the others have worse problems, but there's nobody left to complain about them.

[–] lysdexic@programming.dev 8 points 1 year ago* (last edited 1 year ago) (2 children)

Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases.

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?

[–] bttk@programming.dev 3 points 1 year ago (1 children)

I had a really pleasant experience using mercurial. Some of the things git may be missing:

  • excellent tui for selecting chunks like incommit -i. Arrow keys quickly fold and unfold files/chunks/individual lines
  • commits come in 3 categories:
    • public commits were seen by other people and are considered immutable
    • draft commit is your regular WIP local commit and can't be a parent to a public commit.
    • secret commit with your printf debugging won't be uploaded by accident
  • when you rebase, your previous commits are marked obsolete and 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.
[–] lysdexic@programming.dev 3 points 1 year ago* (last edited 1 year ago)

excellent tui for selecting chunks like incommit -i. Arrow keys quickly fold and unfold files/chunks/individual lines

git add -p might 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.

commits come in 3 categories:

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.

when you rebase, your previous commits are marked obsolete and hidden from most UI.

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.

[–] technom@programming.dev 0 points 1 year ago (1 children)

I use git almost every hour and I rarely have to deal with git problems (just enough practice to avoid them). I'm also confident about resolving problems if they do arise. Heck, I even configure my entire system and manage my life using text files managed by git. So I don't claim that it's all that bad.

But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have. I'm saying this as someone who trained a lot of people in using git from the very beginner level, all the way up to emailing patches - as part of a community and as a corporate trainer. I can write essays about every single problem that can trip a beginner due to git's inconsistency - but am not going to - because they are acknowledged problems (by git devs) and they actively work on it.

[–] lysdexic@programming.dev 0 points 1 year ago* (last edited 1 year ago) (1 children)

But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have.

And yet you were not capable of providing a single example. You managed to put together personal attacks, but no example.

[–] technom@programming.dev 1 points 1 year ago

Sorry. I am not willing to waste my time typing out examples for someone who is too stubborn and lazy to just Google it - It's a topic that has been discussed a billion times. If you want to paint me as incapable for that, go ahead - your opinion is worth as much as your willingness to just search for an answer yourself.