But whoa!, I didn’t know about hg fetch. Talk about implicit, not only does it implicitly merge, it even implicitly commits the results of the merge. (Ok, I imagine you’ll get prompted for a commit message, so you’re unlikely to do so by accident, but still… IMHO something as wacky as fetch should be an Hg extension so you have to explicitly enable it….)

roy

I’m probably being unfair in my complaint about implicit merges – all source code control systems implicitly merge into the working copy all the time.

But in source code control systems I have some familiarity with (SVN, a little Hg) the only merges that I can think of that happen without typing the command ‘merge’ happen when there are uncommitted changes in the working copy, and an operation is performed that updates the working copy (and hence has to merge those changes in). And AIUI that’s not what we’re talking about here.

There’s also something odd going on with command naming – why is it that a pull is not the opposite of a push? To have push and fetch be the actual direct counterparts, with pull being something different, is… unnaturual to say the least…

roy

I hadn’t realized this one before, not being familiar with Mercurial, but, indeed, it seems that “hg pull” is closest to “git fetch”, while “hg pull -u” (or “hg fetch” – aargh again!) is closest to “git pull”.

With regard to explicit / implicit, I dunno. I’d probably argue that using “git pull” is to explicitly request a merge as well as a fetch, since the summary in its man page says “Fetch from and merge with another repository or a local branch” (my emphasis). However, part of the point of this blog post is that a lot of newcomers to git don’t realize that you can do “git fetch” instead of “git pull” to avoid the automatic merge.

The thing that I might change in your definition of a merge to make it more “git worldview” is that (usually) merges in git are between two commits (and thus the state of two complete source code trees) rather than a file-by-file operation. (I say “usually” because you can merge between more than two commits (octopus merges), there are subtree merges, etc. etc.)

To me, a merge is when you take two different sets of edits to the same file, and try to combine the intent of the edits to produce a single resulting file. It is a process that can in some cases be performed automatically, and in other cases is impossible without (sometimes significant) manual work.

Are you saying that a “git pull” (unlike an “hg pull”) implicitly performs a merge (in the above sense) without it being explicitly requested? That sounds… surprising… Either I don’t get git yet, or I don’t get git yet. (Or maybe both. Which is fine. It took me quite a while to evn start to get Hg, too, and I’m still only in the “reading about” phase with git.)

roy

Thanks for the comments. Personally, I’ve always avoided the automatic rebase feature of git, since I like to decide just before pushing whether to rebase or keep any merge commits there – there’s nothing to stop one from pulling normally and rebasing later, after all.