Im amazed git survived at all. Such a mess of complexity and exotic jargon to abstract away something that should be inherently simple. After 20 years I can use it with ease thanks to llms.

▲ superb_dev a day ago | parent | next [-]

I genuinely think you have to be trying to not pick up git after 20 years. Have a little more faith in yourself, it's not super complicated

▲ ndriscoll a day ago | parent | prev | next [-]

It is inherently simple? It's a couple tools to manipulate a graph of snapshots. You can make commits, checkout commits, make/move references to commits, diff commits, and apply diffs to commits. If you wrap your head around that you've pretty much mastered it.

▲ pxmpxm a day ago | parent | prev | next [-]

I love that comments like these incept million tech bro look-at-my-clout responses for having learned some subset of the magic incantations to make git barely usable... As if you get an award for mental heuristics to put up with a poorly architected product with leaky abstraction all over.

If you mentions reflogs, i'm yelling bingo.

Bonus points: You have 3 new commits and in one there is a change in file.stupid, how many git bs things does it take to revert file.stupid to previous version while keeping the rest of the change set.

	▲	perpetualpear 17 hours ago \| parent [-]
		One: git checkout <commit of previous version> -- file.stupid

▲ Hendrikto a day ago | parent | prev | next [-]

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

▲ mrighele a day ago | parent | next [-]

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.

	▲	ndriscoll a day ago \| parent [-]
		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.

▲ dijit a day ago | parent | prev [-]

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.

▲ tomsmeding a day ago | parent [-]

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.

▲ dijit a day ago | parent [-]

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

▲

ndriscoll a day ago | parent [-]

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.

▲

dijit a day ago | parent [-]

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

	▲	ndriscoll a day ago \| parent [-]
		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?

▲ redsocksfan45 a day ago | parent | prev [-]

[dead]