Hacker News Reader

Comment by Hendrikto | Hacker News Reader

That just means you did not really try for 20 years.

UI wise git sucks. The its commands are barely related to what they do, and that little makes sense only if you have in mind the underlying storage model (which is by itself a sign of bad UI).

Almost any other version control tool I have used in my life make more sense that git.

There are many reason for why git won, being able to use it without having to look up commands is not one of them.

The commands don't require you to know the underlying storage model. e.g. I have maybe once in 15 years had an occasion to think about packfiles. I couldn't tell you basic facts about the storage like whether a git clone will mean you necessarily have the same object files as the upstream (I presume no). Content addressed (with named references) snapshots aren't the underlying storage model. They are the UI model, and they make a ton of sense for that purpose.

Come now, lets be real.

How many esoteric tools are needed for proper development?

“save my file” should not need a phd level awareness of the save model, yet it seems to because its so easy to fall off the happy path.

It ought not to, indeed. However, if you want "save my file" to include awareness of other developers concurrently working on the same project -- even the same file -- with a decent way to handle conflicts, it suddenly becomes complicated. Git is probably not the optimal way of designing a UI around this, but it's not like this is an easy problem.

  MINE | MERGED | THEIRS

where you can select elements from both and have them merge into the middle.

Or the p4 merge way of:

  MINE | THEIRS
  -------------
     MERGED

Even most GUI's for git do it this way actually.

Merging should not be a major issue, it should be a trivial annoyance.

It shouldn't drop you into an interactive rebase that invalidates every object after it (necessarily).

It doesn't "drop you into an interactive rebase" unless you tell it to. If you want to rebase, rebase. If you want to merge, merge. As you say, even most UIs for git show what you are saying you want.

you’re right, when a merge conflict happens it drops you in “detached head” and writes a diff into your files which even when modified away require you to issue a special command to continue.

Its actually worse than interactive rebase.

“detached head” and “rebase” aren’t meaningful verbs to normal people… when all you want is to save a working version

Merge conflicts don't put you into a detached head state. You stay on the branch where you ran git merge. Why would it change your checked out branch?

The special command is just `git add` to stage your changes followed by `git commit` (or do it all in one command as `git commit - a`), same as any other changes.

Rebase is something else. It's something you do on purpose because you specifically want to rewrite the history. Personally I use it a lot and expect everyone on my team to, but you can use git just fine without ever rebasing or even knowing it's there.

Like I actually have no idea what you're talking about. Is your criticism actually targeted at some specific UI tool that's not git?

Reply on news.ycombinator.com