On Thu, 2008-06-12 at 14:04 +0200, Yves Orton wrote: > On Thu, 2008-06-12 at 13:53 +0200, Johannes Sixt wrote: > > Yves Orton schrieb: > > > Hi, > > > > > > Ive been working with git-fast-export a bit recently and Ive hit a bug > > > that is causing some trouble. > > > > > > Essentially it seems that one of our repos git-fast-export fails to emit > > > the proper 'from' information for several commits in the repo. These > > > commits are emitted first without parent data even though their parents > > > ARE emitted later. > > > > Does it make a difference if you pass --topo-order to git fast-export? > > (But I don't know for certain that this is even legal.) > > Yes it does make a difference. A big difference. That would be the > workaround I really needed. At least currently thats the way it looks, > i havent thoroughly tested the result yet but it certainly looks right. > > Perhaps this should be enabled by default to avoid the problem i > encountered? At least until whatever the cause of the root problem is > identified and fixed. > > Thanks a lot. ++ to you. I should add that with this switch enabled the output order is correct, HOWEVER the mark number of the first commit is unchanged from the original. However the parent relationships are correctly restored and the resulting repo has the correct SHA1 stamps. So it looks like the original traversal order is wrong somehow, and that --topo-order fixes it up after the fact. But for my immediate needs this is the solution I needed. Again many thanks. BTW, for the record this was needed because we are trying to merge multiple git repos into a single new git repo with each original repo mapped into a subdirectory of the new repo, and with commit trees merged in more or less the correct order (by date applied more or less). IOW we dont want to have multiple "root commits" that are later merged. 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. Cheers and thanks to all you git developers for a great tool! Yves -- 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
