threads / bug / 17670

git fast-export issue -- anyone know if this is a bug or a feature?

Subject: git fast-export issue -- anyone know if this is a bug or a feature?

## tl;dr

4 messages between Feb 9, 2009 and Feb 11, 2009.

replies: 3people: 2as markdown or json

Elijah Newren· Feb 9, 2009, 05:31 UTC · lore

Hi,

The git-fast-export manpage, under the first example, says that $ git fast-export --all | (cd /empty/repository && git fast-import) should create a one-to-one mirror of the source repository (other than reencoding commits that are not in UTF-8).

Either I am misunderstanding this comment, or it's not quite true: while I've gotten identical mirrors using this recipe with most repositories I have tried, I have one which shows some changes under this process. The changes I noticed are that, for example, the master branch has fewer commits in the "mirrored" repository than the source one, and that the history of commits has changed. (The content at the heads of all branches do match, so the changes seem restricted to the history of obtaining that content). Unfortunately, (a) this repository is pretty unwieldy, (b) I can't share it, and (c) it's defied my attempts so far to find a small reproducible testcase. However, from what I have found, it looks like this could be a feature, because I actually like one of the changes I noticed so far.

The "source" repository is one that has been created by cvs2git (which operated on a franken cvs repository munged together from lots of different places; I'm running git-fast-export & git-fast-import based on it since I want to do some extra changes outside of cvs2git). In the source repository, I noticed that 6 of the earliest commits in one root of history looked like:

     /--E
    /  /
A--C--D
  /
 B

In the "mirrored" repository, I notice this history had been modified so that it looked like

        E
       /
A--C--D
  /
 B

The latter history seems much more sane to me; since D is a child of C, making E a merge of C and D seemed really weird. I did pour over the output of git fast-export --all to see if the merge directives were as expected, in order to see whether git fast-export or git fast-import were to be credited with the history fix. It looks to me like git-fast-export reports no merge parents for E, so this seems to be on the fast-export side.

Is this, by chance, intentional?  (I'm using git-1.6.0.6, if it matters.)

Thanks, Elijah

Johannes Schindelin· Feb 9, 2009, 11:17 UTC · re: Elijah Newren · lore

Re: git fast-export issue -- anyone know if this is a bug or a feature?

Hi,

On Sun, 8 Feb 2009, Elijah Newren wrote:

Show 27 quoted lines

> In the source repository, I noticed that 6 of the earliest commits in 
> one root of history looked like:
> 
>      /--E
>     /  /
> A--C--D
>   /
>  B
> 
> In the "mirrored" repository, I notice this history had been modified
> so that it looked like
> 
>         E
>        /
> A--C--D
>   /
>  B
> 
> The latter history seems much more sane to me; since D is a child of
> C, making E a merge of C and D seemed really weird.  I did pour over
> the output of git fast-export --all to see if the merge directives
> were as expected, in order to see whether git fast-export or git
> fast-import were to be credited with the history fix.  It looks to me
> like git-fast-export reports no merge parents for E, so this seems to
> be on the fast-export side.
> 
> Is this, by chance, intentional?  (I'm using git-1.6.0.6, if it matters.)

Nope.

Please try to make a reproduction recipe (preferably as a patch to t9301); it seems that you are half-way there already.

Thanks, Dscho

Elijah Newren· Feb 9, 2009, 14:15 UTC · re: Johannes Schindelin · lore

Re: git fast-export issue -- anyone know if this is a bug or a feature?

On Mon, Feb 9, 2009 at 4:17 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 36 quoted lines

> Hi,
>
> On Sun, 8 Feb 2009, Elijah Newren wrote:
>
>> In the source repository, I noticed that 6 of the earliest commits in
>> one root of history looked like:
>>
>>      /--E
>>     /  /
>> A--C--D
>>   /
>>  B
>>
>> In the "mirrored" repository, I notice this history had been modified
>> so that it looked like
>>
>>         E
>>        /
>> A--C--D
>>   /
>>  B
>>
>> The latter history seems much more sane to me; since D is a child of
>> C, making E a merge of C and D seemed really weird.  I did pour over
>> the output of git fast-export --all to see if the merge directives
>> were as expected, in order to see whether git fast-export or git
>> fast-import were to be credited with the history fix.  It looks to me
>> like git-fast-export reports no merge parents for E, so this seems to
>> be on the fast-export side.
>>
>> Is this, by chance, intentional?  (I'm using git-1.6.0.6, if it matters.)
>
> Nope.
>
> Please try to make a reproduction recipe (preferably as a patch to t9301);
> it seems that you are half-way there already.

Okay, I'll work on it. Sadly, making a branch based on commit E and trying to run using <E> instead of "--all" didn't reproduce the bug, so it must require some additional things to trigger this issue. I think I triggered the same issue on a closely related cvs2git-created repository that's only about 350M, so at least I have something smaller to work with. It may take me a while, but I'll report back when I've found more.

Elijah

Elijah Newren· Feb 11, 2009, 06:12 UTC · re: Elijah Newren · lore

Re: git fast-export issue -- anyone know if this is a bug or a feature?

Hi,

On Sun, Feb 8, 2009 at 10:31 PM, Elijah Newren <newren@gmail.com> wrote:

Show 24 quoted lines

> The "source" repository is one that has been created by cvs2git (which
> operated on a franken cvs repository munged together from lots of
> different places; I'm running git-fast-export & git-fast-import based
> on it since I want to do some extra changes outside of cvs2git).  In
> the source repository, I noticed that 6 of the earliest commits in one
> root of history looked like:
>
>     /--E
>    /  /
> A--C--D
>  /
>  B
>
> In the "mirrored" repository, I notice this history had been modified
> so that it looked like
>
>        E
>       /
> A--C--D
>  /
>  B
>
> The latter history seems much more sane to me; since D is a child of
> C, making E a merge of C and D seemed really weird.  I did pour over

I think I found the source of the bug, and have sent out a couple patches in separate emails. However, I wanted to correct my statement here. The repositories created by cvs2git did not have such a commit history; I think it was simply too late at night and I wasn't reading things correctly.

Elijah