[CJefferson]

This article seemed to start off well, but at the end turned into a 'Git is better because tools can edit the DAG storing state. QED'.

It is possible that that is true, but I'd want a stronger backup. Making no negative comments about git at all sets off very strong alarm bells for me.

[chousuke]

Is it necessary to find something negative in git if you want to highlight a limitation in mercurial? (That can admittedly be worked around with extensions)

The author makes a point that git's more transparent approach makes certain things easy to implement and consistent. To reiterate his example, stashes are just objects in a place where they won't be found by default, but they still work with everything because there's no magic.

The second example shows that git trusts that the user knows best what to do. If you want to reset a branch to a certain commit, git allows you to do it, and because the data model is not hidden git can simply expose the needed operation (reset branch pointer) as is.

For the most part, git has neat porcelains for most operations nowadays, but the UI is sometimes a bit weird because it started off as nothing more than a set of tools to manipulate a DAG of content on disk. In my view this ended up becoming one of its strong points in comparison to other DVCS.

[CJefferson]

The title of the post was "The Real Difference Between Git and Mercurial". This implies to me that the article is about one, clear difference, which is the main distinction between the two.

Had the post been called "An advantage of git over mercurial", I would have placed a much lower requirement.

[xentac]

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]

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.

[pornel]

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

[xentac]

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]

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]

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]

Please see libgit/libgit2

[aredridel]

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

[OmarIsmail]

I think the author does say something negative about git, just doesn't say it in a negative way. "When a git user runs into a problem, they look at the tools they have on hand and ask, “how can I combine these ideas to solve my problem?”"

The negative here is that A) git user has to know about all the tools, which takes a long time, and then solving the issue requires quite a bit of thought.

That's one of the problems about git is that as a result of the massive flexibility there doesn't seem to a "standard" way to do things, even basic things. Each org has to develop their own processes which is annoying and difficult for new people in the org.

[gcp]

I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.

[SethRobertson]

Here is a document describing git best practices which has been liked by some of the most knowledgeable git users out there.

Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906

[dmoney]

For large projects, there is git-flow: https://www.google.com/search?q=git-flow

I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.

[lysium]

github uses a different flow. This article mentions the issues with git-flow and describes the flow used at github:

http://scottchacon.com/2011/08/31/github-flow.html

[gizzlon]

another negative sentence: "you can just point the branch pointer back at the previous commit with git reset --hard HEAD@{1}"

just? Wtf is HEAD@{1} ?

That might be simple, but as usual, only if you know a lot about git.

As a casual git user this annoys me; Even when doing basic stuff I often have to read a long blog-post about how git works internally. I can't remember having this problem when I was a casual Mercurial user.

[beaumartinez]

Run git reflog—HEAD@{1} is (at least as I understand it) "the state HEAD was at 1 commit ago"—including things such as rebasing and reverting.