[macro-b]

At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?

[juvoly]

Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted.

Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.

[mark_undoio]

There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me.

It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.

Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.

I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!

[codesnik]

git's mental model is very, very small, if you care to learn it. Then all the commands and their "inconsistencies" start to make sense - they operate on the model almost without any magic, and not on whatever is user's intent (it can vary a lot)

[tasuki]

> Mercurial wasn't as simple as Subversion.

What? Subversion is by far the most complex versioning software I've ever used.

> Git has so many gotchas, bells and whistles

The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.

[eclipticplane]

Subversion pre-1.5 was a nightmare. Branch merges were by convention in commit messages. To merge 20 commits from your branch, you would do `svn merge -r 125:140 /branches/my-feature` and then note in the commit message which range you merged.

1.5 made that tracking automatic but just shoved it into a metadata field that just percolated through every directory in a project.

And if someone tried to rename a core path? In the distance, sirens.

[juvoly]

You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.

[ahartmetz]

Just an example that I recently noticed when I briefly had to use svn again:

Show a diff: svn diff / git diff

Show log with diffs: svn log --diff / git log --patch

Git calling the same or similar things different (or just terrible - tree-ish? ref?) names is one of the worst things about Git.

[delecti]

I found that doing anything even slightly unusual in Git was pretty incomprehensible until I learned its internals, and pretty easy once I did. Fortunately as you say the internals are conceptually pretty simple to learn.

[Espressosaurus]

Git doesn't give you more power, it just makes their internals your problem.

[KwanEsq]

Do you actually even have more power with git?

[12_throw_away]

Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.

[g-b-r]

No, it's the opposite