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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 26, 2008, 16:44 UTC
Message-ID: <492D7CF5.1020202@drmicha.warpmail.net>
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>

Johannes Schindelin venit, vidit, dixit 26.11.2008 17:40:

Show 16 quoted lines

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