git import/export bug?

Benjamin Lynn· Jun 10, 2008, 08:41 UTC · lore

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.

Benjamin Lynn· Jun 10, 2008, 08:44 UTC · re: Benjamin Lynn · lore

Re: git import/export bug?

Sorry about the dupe, I clicked the send button on the wrong email account. This is an earlier edit of my intended post. Please ignore. (Or preferably, an admin can delete these?)

On Tue, Jun 10, 2008 at 1:41 AM, Benjamin Lynn <blynn@google.com> wrote:

Show 41 quoted lines

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