From: Junio C Hamano <junkio@cox.net>
To: "Marco Costalba" <mcostalba@gmail.com>
Cc: git@vger.kernel.org, Paul Mackerras <paulus@samba.org>
Subject: Re: Possible --boundary bug
Date: Thu, 30 Mar 2006 23:58:00 -0800 [thread overview]
Message-ID: <7v64lvvyev.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <e5bfff550603301255j52c68963v4b8eebea697eeecf@mail.gmail.com> (Marco Costalba's message of "Thu, 30 Mar 2006 22:55:44 +0200")
"Marco Costalba" <mcostalba@gmail.com> writes:
> Sorry, the good description is below, please ignore the wrong previous one.
I think this patch should fix it.
-- >8 --
rev-list --boundary: fix re-injecting boundary commits.
Marco reported that
$ git rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d
misses these two boundary commits.
c649657501bada28794a30102d9c13cc28ca0e5e
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
Indeed, we can see that gitk shows these two commits at the
bottom, because the --boundary code failed to output them.
The code did not check to avoid pushing the same uninteresting
commit twice to the result list. I am not sure why this fixes
the reported problem, but this seems to fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/revision.c b/revision.c
index abc8745..c2a95aa 100644
--- a/revision.c
+++ b/revision.c
@@ -420,24 +420,33 @@ static void limit_list(struct rev_info *
p = &commit_list_insert(commit, p)->next;
}
if (revs->boundary) {
- list = newlist;
- while (list) {
+ /* mark the ones that are on the result list first */
+ for (list = newlist; list; list = list->next) {
struct commit *commit = list->item;
+ commit->object.flags |= TMP_MARK;
+ }
+ for (list = newlist; list; list = list->next) {
+ struct commit *commit = list->item;
struct object *obj = &commit->object;
- struct commit_list *parent = commit->parents;
- if (obj->flags & (UNINTERESTING|BOUNDARY)) {
- list = list->next;
- continue;
- }
- while (parent) {
+ struct commit_list *parent;
+ if (obj->flags & UNINTERESTING)
+ continue;
+ for (parent = commit->parents;
+ parent;
+ parent = parent->next) {
struct commit *pcommit = parent->item;
- parent = parent->next;
if (!(pcommit->object.flags & UNINTERESTING))
continue;
pcommit->object.flags |= BOUNDARY;
+ if (pcommit->object.flags & TMP_MARK)
+ continue;
+ pcommit->object.flags |= TMP_MARK;
p = &commit_list_insert(pcommit, p)->next;
}
- list = list->next;
+ }
+ for (list = newlist; list; list = list->next) {
+ struct commit *commit = list->item;
+ commit->object.flags &= ~TMP_MARK;
}
}
revs->commits = newlist;
next prev parent reply other threads:[~2006-03-31 7:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-30 18:34 Possible --boundary bug Marco Costalba
2006-03-30 20:55 ` Marco Costalba
2006-03-31 7:58 ` Junio C Hamano [this message]
2006-03-31 16:39 ` Marco Costalba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v64lvvyev.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=mcostalba@gmail.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).