Hacker News Reader

Comment by xentac | Hacker News Reader

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.

View on HN

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.

> 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

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

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.

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.

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.

Please see libgit/libgit2

Interesting. What's the difference to you? Git's extensions are shell (or whatever other language) tools is all, in my mind.

Reply on news.ycombinator.com