On 11/13/07, Paul Mackerras <paulus@xxxxxxxxx> wrote: > 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. > Sorry to comment on a gitk thread, but the problem of different parents for the same sha while replaying was hitted by me also with qgit when tring to implement --early-output I don't know if i is suitable also for gitk but in qgit I changed the match algorithm to check also for same parents and not only for same sha during a replay to detect something has changed, so to catch different parents cases early on and avoiding "going back" that is complex. IOW when git log print outs a replay qgit enter in a state where it checks all the arrived sha against the already sent ones and at the first mismatch flushes the tail at the point of mismatch. The modified algorithm instead of chek just the sha checks also parents info (because git log is called with --parents option this ends up comparing the first line of the commit message). Marco - 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
