Linus Torvalds writes: > However, while the parent is now correctly rewritten, it looks like gitk > is confused by this. Gitk will remember the original parent information, > even if a replay has given new parenthood information. Since the partial > early-output information is triggered by timing, this means that gitk will > show some totally random parent that quite possibly won't even be part of > the final commit set at all! Yep. It will be a little complex to deal with that because there are bits of state that I set up for the parents, and if they're the wrong parents, I'll have to go back and undo that. In fact it would be easier for me if, instead of getting the id of some random ancestor commit, I got an explicit indication to say "unknown parent", such as just a "-" in place of the id of the unknown parent(s). Would that be doable? I could then just not do the processing for any unknown parent, and make sure to do it when I see the final version of the commit. Also, I have just about worked out an efficient way to do the commit reordering incrementally, which would let me not use --topo-order or --date-order, and display commits as they come in. I'll have to see whether that turns out to be better overall than using --early-output. Paul. - 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
