|
|
|
|
|
by eridius
5263 days 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. |
|
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
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
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).