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

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

Hi,

On Wed, 26 Nov 2008, Ondrej Certik wrote:

quoted

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?