Re: git fast-export | git fast-import doesn't work

[Michael J Gruber <git@drmicha.warpmail.net>]

Johannes Schindelin venit, vidit, dixit 26.11.2008 17:40:
> Hi,
> 
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
> 
>> I am also trying to make the example simpler. I tried to squash the 
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly 
>> fails after squashing about 600 commits. Still investigating.
> 
> 1500... wow.
> 
> The best idea would probably be to just "edit" the first, delete the rest 
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on 
> the command line (when git rebase stops after the "edit" command).
> 
> rebase -i was _never_ meant for such _massive_ interactions; that's just 
> too much for a shell script.

Or chop the DAG with grafts.

Removing the tags one by one I noticed that for several of them, removal
of the tag increases the number of commits on the connected DAG
component containing master (in the ex/imported repo), and that one
reaches the correct number with still a few tags left in there. Yet, the
topology is wrong in several places; I think all of them can be
attributed to missing parent info (which even creates new roots in some
places).

Looking at the source I suspect that fast-export fails to denote
parenthood in the case of yet unmarked parents (last for-loop of
handle_commit() in builtin_fast_export.c). But I don't really know that
code at all.

Michael

P.S.: That git repo itself is a product of
hg-fast-export|git-fast-import, right?