4 ms·

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 time

by juvoly 5mo ago

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 5mo ago
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 5mo ago
  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 5mo ago
> 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.
- juvoly 5mo ago
  You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.
  - ahartmetz 5mo ago
    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.
    - deleted 5mo ago
      [deleted]
- delecti 5mo ago
  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.
- eclipticplane 5mo ago
  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.

by juvoly 5mo ago

mark_undoio 5mo ago

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 5mo ago
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 5mo ago

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

juvoly 5mo ago
You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.
- ahartmetz 5mo ago
  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.
  - deleted 5mo ago
    [deleted]
delecti 5mo ago
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.
eclipticplane 5mo ago
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.