Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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)) This is too subtle, or I am missing something. I have to wonder what would happen if a much higher level caller caused the objects to get parsed before coming into the revision walking machinery, e.g. after the command line processing for A...B walked the ancestry chain until their common ancestors are found. So these commits between A and B are parsed, but the revision limiting machinery hasn't done its operation to set TREECHANGE and/or UNINTERESTING in add_parents_to_list() on these commits yet. I think the fix will not trigger for such parents, but the processing just goes on. - 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
