git import/export bug?

Sorry if this is a well-known problem, but I only just came across it. I tried searching for it briefly, but to no avail. Maybe nobody cares because there's usually no need to export from git! And it's only one of the satellite features, not the core. Nonetheless, if you export git repos, you might want to know about it.

Try this:

$ git clone git://git.kernel.org/pub/scm/git/git.git # clone git source $ git checkout -b test 60ea0fdd7de001405fcc7591beb18a66a1f0dd09 $ git fast-export test > /tmp/x

$ cd /some/empty/dir $ git init $ git fast-import < /tmp/x $ git checkout test

You'd expect exporting a pristine import to result in a faithful copy. But type "git log" and you'll see the hash of the top commit differs. (It's 56fe9d6d474f5c88c5c9af578802a5479346ea4a.) In fact, most hashes are wrong, because two distinct initial commits are now related. The root cause is git-fast-import: give it two commits with the same branch name, and it assumes the latter is the descendant of the former.

Normally this is what you want. But if your project, like git, ever merges distinct initial commits, then all but the first will unexpectedly gain parents, corrupting all their descendants' hashes.

-Ben

P.S: I found this because I wrote a git importer/exporter (mostly copying git's fast-import.c) for my git clone for testing. To work around it, I have a special "git-import" command that looks for "from" commands: the current git-fast-export omits them from initial commits. But clearly a better solution is needed.

It can't be fixed in the code. The importer language simply is too weak. They ought to add a "initial" command that explicitly marks a commit as such.