Re: git-fast-export bug, commits emmitted in incorrect order causing parent data to be lost from commits turning essentially linear repo into "islands"

[Michael J Gruber <michaeljgruber+gmane@fastmail.fm>]

Yves Orton venit, vidit, dixit 12.06.2008 14:16:
> We want a more or less linear repo as the result. This bug with
> fast-export was the main showstopper in our efforts.  However, I can
> imagine that this is a problem that many people will want to solve. It
> would be nice if there was an easier way to do it that what we currently
> are doing (merging and munging multiple fast-export streams into a
> single fast-import process). While at this point its probably academic
> any suggestions as to the Best Way to do this would be very much
> welcome.

I've done something like this, "stitching" the history of different 
repos together in order to produce one repo, with each of the 
constituents in a subdir. What I did was an adaption of

http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

but as a multistep version:

1. Create an empty repo
2. Add your to-be-stitched repos as remotes, say A B C
3. Create an empty commit
4. "git merge -s ours --no-commit a b c", where a b c are the root 
commits of A B C
5. "git read-tree --prefix=dir-A/ -u a" and analogously for b c
6. "git commit", use the common commit message of those commits

Note that git refuses the merge (4.) into an empty (headless) repo, 
which is why you need 3. There may be smarter ways.
If you don't care about recording the commits as (octopus) merges you 
can skip 3. and 4. (4. just records merge info in the index).

Then, repeat:
3'. remove dir-A etc. (I think I used git-rm, I'm sorry I can't recall).
4. as above (if you want to record as merge)
5. as above
6. as above

If not all of A B C appear in every step then make sure to remove only 
the ones (in 3'.) which you'll update in 5. You have to remove the dir 
because read-tree wants it like that.

I used this for stitching 5 or 6 repos with a short history together, so 
I repeated these steps manually rather than scripting it; all I needed 
was a list of SHA1s listing which commits from A B C etc. corresponded 
to the same "step" in the combined repo.

Cheers
Michael