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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
