4 ms·

Fair assessment. This is where my bias towards git shows through. I use git and understand what it's capable of and why mercurial does it differently. The op

by xentac 15y ago

Fair assessment. This is where my bias towards git shows through. I use git and understand what it's capable of and why mercurial does it differently. The opposite isn't true. If you give me some examples, I can probably roll them into a followup post later on.

eridius 15y ago
The piece may be improved by highlighting the fact that while Mercurial users have to write extensions to work around problems, the flip side is they _can_ write extensions to do things the built-in tools don't do. For example, the Golang project has an extension that integrates with their code review system. With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension (though it can frequently accomplish the same purpose). That said, I really enjoyed the article. As a hardcore git user, I've occasionally skirted the edges of Mercurial (mostly just by poking at Golang) and always been confused at some of the stuff I saw. I knew Mercurial branches were more permanent than Git ones, but I never realized quite how permanent they were.
- xentac 15y ago
  I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example). Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.
  - aredridel 15y ago
    Interesting. I've never considered that git doesn't give access -- it's always seemed right there to me, whether I want to tweak it by calling out to a git tool to do it, or doing it myself.
    - xentac 15y ago
      It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.
      - chrisrhoden 15y ago
        Please see libgit/libgit2
- aredridel 15y ago
  Interesting. What's the difference to you? Git's extensions are shell (or whatever other language) tools is all, in my mind.
- pornel 15y ago
  > With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension Git itself is a bunch of scripts that wrap (lower-level) git tools. For example git's "native" `git rebase` command is a shell script: https://github.com/git/git/blob/master/git-rebase.sh https://github.com/git/git/blob/master/git-rebase.sh You can create your own commands simply by putting a script called `git-whatever.sh` in your path, e.g. git svn-abandon: https://github.com/nothingmuch/git-svn-abandon https://github.com/nothingmuch/git-svn-abandon I don't know hg's extensions, so perhaps I don't know what I'm missing, but I have no complaints about git's extensibility. It allows editing of its entire database and all branches (I've been able to convert SVN repo and re-create all merges, change authorship and dates of commits) and has hook scripts that can intercept and customize important actions in the workflow (I've been able to build non-trivial website deployment automation using git as a base).

by xentac 15y ago

eridius 15y ago

The piece may be improved by highlighting the fact that while Mercurial users have to write extensions to work around problems, the flip side is they _can_ write extensions to do things the built-in tools don't do. For example, the Golang project has an extension that integrates with their code review system. With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension (though it can frequently accomplish the same purpose). That said, I really enjoyed the article. As a hardcore git user, I've occasionally skirted the edges of Mercurial (mostly just by poking at Golang) and always been confused at some of the stuff I saw. I knew Mercurial branches were more permanent than Git ones, but I never realized quite how permanent they were.

xentac 15y ago
I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example). Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.
- aredridel 15y ago
  Interesting. I've never considered that git doesn't give access -- it's always seemed right there to me, whether I want to tweak it by calling out to a git tool to do it, or doing it myself.
  - xentac 15y ago
    It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.
    - chrisrhoden 15y ago
      Please see libgit/libgit2
aredridel 15y ago
Interesting. What's the difference to you? Git's extensions are shell (or whatever other language) tools is all, in my mind.
pornel 15y ago
> With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension Git itself is a bunch of scripts that wrap (lower-level) git tools. For example git's "native" `git rebase` command is a shell script: https://github.com/git/git/blob/master/git-rebase.sh https://github.com/git/git/blob/master/git-rebase.sh You can create your own commands simply by putting a script called `git-whatever.sh` in your path, e.g. git svn-abandon: https://github.com/nothingmuch/git-svn-abandon https://github.com/nothingmuch/git-svn-abandon I don't know hg's extensions, so perhaps I don't know what I'm missing, but I have no complaints about git's extensibility. It allows editing of its entire database and all branches (I've been able to convert SVN repo and re-create all merges, change authorship and dates of commits) and has hook scripts that can intercept and customize important actions in the workflow (I've been able to build non-trivial website deployment automation using git as a base).