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

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

[Elijah Newren]

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

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

[Johannes Schindelin]

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.

Thanks,
Dscho

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

[Elijah Newren]

On Mon, Feb 9, 2009 at 4:17 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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

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

[Elijah Newren]

Hi,

On Sun, Feb 8, 2009 at 10:31 PM, Elijah Newren <newren@gmail.com> wrote:
> 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