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>
p = &commit_list_insert(commit, p)->next;
}
if (revs->boundary) {
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 *commit = list->item;
struct object *obj = &commit->object;
- struct commit_list *parent = commit->parents;
- if (obj->flags & (UNINTERESTING|BOUNDARY)) {
- list = list->next;
+ struct commit_list *parent;
+ if (obj->flags & UNINTERESTING)
+ for (parent = commit->parents;
+ parent;
+ parent = parent->next) {
struct commit *pcommit = parent->item;
struct commit *pcommit = parent->item;
if (!(pcommit->object.flags & UNINTERESTING))
continue;
pcommit->object.flags |= BOUNDARY;
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;
}
p = &commit_list_insert(pcommit, p)->next;
}
+ }
+ for (list = newlist; list; list = list->next) {
+ struct commit *commit = list->item;
+ commit->object.flags &= ~TMP_MARK;
}
}
revs->commits = newlist;
}
}
revs->commits = newlist;