On Thu, 30 Mar 2006, Junio C Hamano wrote:
>
> There already was a report that --boundary stuff is not quite
> right, so what you are seeing might be that the new code exposes
> its original breakage even more. I haven't looked into the
> breakage of the original version yet either, so I cannot really
> say how your change breaks it.
[ Awake and thinking about this again ]
No, I think the new breakage was just because I was being a stupid ass.
When I converted get_revision() to do the parent parsing up at the top
instead of at the bottom, I just didn't think correctly about your new
BOUNDARY code, and my conversion for that was just wrong. Part of the "do
the parents early" code was also removing the current commit early, so
suddenly your BOUNDARY case for doing that thing was just removing some
other random commit instead, which was obviously wrong.
The fix is trivial - with the new get_revision() organization, the
BOUNDARY case special-case actually goes away entirely, and this trivial
patch (on top of my 2/2 patch) should just fix it.
At least it passes my tests again now, and looking at the code everything
seems sane.
Linus
---
diff --git a/revision.c b/revision.c
index 0e3f074..753633e 100644
--- a/revision.c
+++ b/revision.c
@@ -796,18 +796,6 @@ struct commit *get_revision(struct rev_i
if (revs->parents)
rewrite_parents(commit);
}
- /* More to go? */
- if (revs->max_count) {
- if (commit->object.flags & BOUNDARY) {
- /* this is already uninteresting,
- * so there is no point popping its
- * parents into the list.
- */
- struct commit_list *it = revs->commits;
- revs->commits = it->next;
- free(it);
- }
- }
commit->object.flags |= SHOWN;
return commit;
} while (revs->commits);
-
: 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