When we do history simplification in early-output, we end up in the interesting situation that the early output may do simplification with a partial tree - in particular, there may be parents that simply haven't been handled yet, and don't have their parenthood parsed. The history simplification would get this case totally wrong, and assume that the parent list of a parent being NULL meant that it was a root commit, and rewrite the whole parent as such. This would cause unconnected commits in the gitk output. This fixes it, by saying that if you reach a parent that hasn't been parsed yet, history simplification will simply stop and leave it alone: later on, when we have the full history, we will *continue* the simplification and eventually get the right information. 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! On the kernel, at least with my machine, I can trigger this with something like gitk fs/read_write.c where currently the log (with --parents) reads like this: commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca Author: Pavel Emelyanov <xemul@xxxxxxxxxx> Date: Mon Oct 1 14:41:11 2007 -0700 Cleanup macros for distinguishing mandatory locks .. commit d96e6e71647846e0dab097efd9b8bf3a3a556dca d6b29d7cee064f28ca097e906de7453541351095 Author: Jens Axboe <jens.axboe@xxxxxxxxxx> Date: Mon Jun 11 12:18:52 2007 +0200 Remove remnants of sendfile() ... but with early-output (and this fixed patch), I get something like this: Final output: 1 incomplete commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 31b54f40e12e4d04941762be6615edaf3c6ed811 Author: Pavel Emelyanov <xemul@xxxxxxxxxx> Date: Mon Oct 1 14:41:11 2007 -0700 Cleanup macros for distinguishing mandatory locks ... Final output: 26 done commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca Author: Pavel Emelyanov <xemul@xxxxxxxxxx> Date: Mon Oct 1 14:41:11 2007 -0700 Cleanup macros for distinguishing mandatory locks .. ie notice how the early-output doesn't have the right parent, since it hasn't gotten that far back in history yet. So now the final output will have the parenthood rewritten (correctly), but gitk will have cached the old random incorrect parenthood, and doesn't react properly to the updated and fixed one at replay time. Anyway, this is a real fix, but gitk remains a bit useless as is. Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> --- revision.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/revision.c b/revision.c index 931f978..8872a91 100644 --- a/revision.c +++ b/revision.c @@ -1352,6 +1352,8 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp if (!revs->limited) if (add_parents_to_list(revs, p, &revs->commits) < 0) return rewrite_one_error; + if (!p->object.parsed) + return rewrite_one_ok; if (p->parents && p->parents->next) return rewrite_one_ok; if (p->object.flags & (TREECHANGE | UNINTERESTING)) - 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
