Comments on: Mercurial & Git

By: panzi

panzi — Sun, 23 Nov 2008 00:09:50 +0000

Hg has hgsubversion, which is also bidirectional. However, this needs the current development version of hg. But hg 1.1 should be released soon anyway.

http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion

By: martin langhoff

martin langhoff — Mon, 19 Mar 2007 20:05:09 +0000

Good point. There are good reasons for the hash being different — the hash reflechts a tree identity, and a particular history.

However, in the subsequent merge (at _your_ end), if the patch you mailed out was applied without conflicts, then git will recognise that and not show a merge.

OTOH, it will show a conflict if your upstream edited the patch. This identification is done by hashing the diff so if someone else sent the exact same patch, git will recognise it as merged in too.

So, GIT does deal with “patch identities” creating a SHA1 of the unified diff — but it treats those as peripheral. The _central_ concept is the content of the tree. From my experience with patch-centered SCMs (darcs, tla), tree identities win big time because it’s cheap to generate patch identities — whereas it’s a lot more expensive, complicated and failure-prone to generate full trees from series of patches. (When I write failure-prone, I’m thinking of tla…)

Hope that helps!

By: John Goerzen

John Goerzen — Mon, 19 Mar 2007 14:58:57 +0000

The nice thing about darcs send is that it looks at the remote repository, compares it to the local, and *automatically* sends the patches that local has but remote doesn’t.

But it doesn’t just send a diff, it sends the exact changeset, which, when applied remotely, will have the same hash as locally. So there is no merging later unless it is modified before applying.

By: Jan Hudec

Jan Hudec — Mon, 19 Mar 2007 07:22:00 +0000

Well, the difference between darcs send and git-format-patch is, that the former maintains the commit identity, while the later simply creates patches.

The idea in git is the logical steps and not how the work was done that should be tracked. So the contributor prepares the changes, against a whatever version, refactors them into logical steps (using stgit or patchy-git git add-on) and sends them in with git-send-email. And the maintainer will apply them to his current head, so they most likely end up with different parent and therefore slightly different anyway. Git has separate ‘author’ and ‘committer’ fields to keep track of who sent it and who applied it.

It should not be too hard to create a git command that would send whole commits though. Just find what a push would do and add it to a pack object instead.

By: martin langhoff

martin langhoff — Mon, 19 Mar 2007 06:41:09 +0000

Nice to see people playing with git-cvsserver ;-) What does darcs send do and why is it so nice?

If it formats a commit and sends it to upstream, maybe git-format-patch and git-send-email are what you are after?

(will this cc me on your reply?)

By: Anonymous

Anonymous — Mon, 19 Mar 2007 05:12:50 +0000

Git has a MinGW port.

Also, what does darcs send do that git-format-patch and git-send-email don’t?

(You might also find git-imap-send useful if you have an IMAP server.)