Volume XXII, number 279Tuesday, October 6, 2026Latest message 39 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

Bug report - git rev-list --exclude-first-parent-only [SEC=UNOFFICIAL]

3 messages between Jul 2, 2026 and Jul 21, 2026, from Michael Hore, Junio C Hamano, Jerry Zhang.

Plain Markdown or JSON for tools and agents.

Michael HoreJul 2, 2026, 03:59 UTC on lore
I believe I have found a bug -
My repo has a commit structure like
R2
|\
| F
|/
R1
i.e.
 - there is a merge commit R2 with parents R1 and F
 - the parent of F is R1
I ran "git rev-list --exclude-first-parent-only F ^R2"
it gave the expected result: "F"
I ran "git rev-list --exclude-first-parent-only F R1 ^R2"
I expected the same result, but I got an unexpected result - nothing at all
Suspected cause - I had a look at the code, and it looks like process_parents() in revision.c, when processing uninteresting flags, will skip the 1st parent and mark the 2nd parent as uninteresting if the 1st parent is already SEEN, even with the flag exclude-first-parent-only. I think maybe explicitly selecting R1 on the command line causes it to be marked SEEN before ^R2 is processed, thus resulting in F being marked uninteresting.
[System Info]
git version:
git version 2.54.0.windows.1
cpu: x86_64
built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
[Enabled Hooks]

Regards, Michael

Please consider the environment before printing this document.
Information collected by ASIC may contain personal information. Please refer to our Privacy Policy<https://asic.gov.au/privacy/> for information about how we handle your personal information, your rights to seek access to and correct your personal information, and how to complain about breaches of your privacy by ASIC.
This e-mail and any attachments are intended for the addressee(s) only and may be confidential. They may contain legally privileged, copyright material or personal and /or confidential information. You should not read, copy, use or disclose the content without authorisation. If you have received this email in error, please notify the sender as soon as possible, delete the email and destroy any copies. This notice should not be removed.
Junio C HamanoJul 3, 2026, 20:28 UTC in reply to Michael Hore on lore

Re: Bug report - git rev-list --exclude-first-parent-only [SEC=UNOFFICIAL]

Michael Hore <Michael.Hore@asic.gov.au> writes:
Show 13 quoted lines
> I believe I have found a bug -
>
> My repo has a commit structure like
>
> R2
> |\
> | F
> |/
> R1
>
> i.e.
>  - there is a merge commit R2 with parents R1 and F
>  - the parent of F is R1

IOW, R2 is a useless merge that could have been a simple fast-forward directly to F.

Show 7 quoted lines
> I ran "git rev-list --exclude-first-parent-only F ^R2"
>
> it gave the expected result: "F"
>
> I ran "git rev-list --exclude-first-parent-only F R1 ^R2"
>
> I expected the same result, but I got an unexpected result - nothing at all

This seems to have come from 9d505b7b49 (git-rev-list: add --exclude-first-parent-only flag, 2022-01-11). I do not know if the original author is still around, but it would have been nicer to ask for input from them (cc'ed).

A fix could be something along this line, but I've never used this feature even once (I instead use Michael Haggerty's exellent "git when-merged" thing), so I may very well be breaking _other_ use cases this feature was originally intended for without knowing.

The patched part is inside a huge "while (parent)" loop. The idea is to break out before the loop goes on to smudge later parents when we are in the "smudge only first parent as uninteresting, without contaminating the history leading to other parents" mode.

 revision.c                   | 10 ++++++++--
 t/t6012-rev-list-simplify.sh | 18 ++++++++++++++++++
 2 files changed, 26 insertions(+), 2 deletions(-)
diff --git c/revision.c w/revision.c
index e91d7e1f11..1f50d42a7a 100644
--- c/revision.c
+++ w/revision.c
@@ -1151,12 +1151,18 @@ static int process_parents(struct rev_info *revs, struct commit *commit,
 			if (p)
 				p->object.flags |= UNINTERESTING |
 						   CHILD_VISITED;
-			if (repo_parse_commit_gently(revs->repo, p, 1) < 0)
+			if (repo_parse_commit_gently(revs->repo, p, 1) < 0) {
+				if (revs->exclude_first_parent_only)
+					break;
 				continue;
+			}
 			if (p->parents)
 				mark_parents_uninteresting(revs, p);
-			if (p->object.flags & SEEN)
+			if (p->object.flags & SEEN) {
+				if (revs->exclude_first_parent_only)
+					break;
 				continue;
+			}
 			p->object.flags |= (SEEN | NOT_USER_GIVEN);
 			if (queue)
 				prio_queue_put(queue, p);
diff --git c/t/t6012-rev-list-simplify.sh w/t/t6012-rev-list-simplify.sh
index 4cecb6224c..2284bbba12 100755
--- c/t/t6012-rev-list-simplify.sh
+++ w/t/t6012-rev-list-simplify.sh
@@ -285,4 +285,22 @@ test_expect_success 'log --graph --simplify-merges --show-pulls' '
 	test_cmp expect actual
 '
 
+test_expect_success 'exclude-first-parent-only with parent already seen' '
+	git checkout --orphan test-seen &&
+	git rm -rf . &&
+	test_commit r1 &&
+	git checkout -b branch-f &&
+	test_commit f &&
+	git checkout test-seen &&
+	git merge --no-ff --no-edit -m r2 branch-f &&
+	git tag r2 &&
+
+	git rev-list --exclude-first-parent-only f ^r2 >actual &&
+	git rev-parse f >expect &&
+	test_cmp expect actual &&
+
+	git rev-list --exclude-first-parent-only f r1 ^r2 >actual2 &&
+	test_cmp expect actual2
+'
+
 test_done
Jerry ZhangJul 21, 2026, 00:35 UTC in reply to Junio C Hamano on lore

Re: Bug report - git rev-list --exclude-first-parent-only [SEC=UNOFFICIAL]

On Fri, Jul 3, 2026 at 1:28 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 37 quoted lines
>
> Michael Hore <Michael.Hore@asic.gov.au> writes:
>
> > I believe I have found a bug -
> >
> > My repo has a commit structure like
> >
> > R2
> > |\
> > | F
> > |/
> > R1
> >
> > i.e.
> >  - there is a merge commit R2 with parents R1 and F
> >  - the parent of F is R1
>
> IOW, R2 is a useless merge that could have been a simple
> fast-forward directly to F.
>
> > I ran "git rev-list --exclude-first-parent-only F ^R2"
> >
> > it gave the expected result: "F"
> >
> > I ran "git rev-list --exclude-first-parent-only F R1 ^R2"
> >
> > I expected the same result, but I got an unexpected result - nothing at all
>
> This seems to have come from 9d505b7b49 (git-rev-list: add
> --exclude-first-parent-only flag, 2022-01-11).  I do not know if the
> original author is still around, but it would have been nicer to ask
> for input from them (cc'ed).
>
> A fix could be something along this line, but I've never used this
> feature even once (I instead use Michael Haggerty's exellent "git
> when-merged" thing), so I may very well be breaking _other_ use
> cases this feature was originally intended for without knowing.

fwiw when-merged seems to be asking the question "when was X branch merged into the baseline", while exclude-first-parent-only is asking "when did X branch first split off from the baseline". of course that property may not be interesting to you if you're looking for the former.

Show 63 quoted lines
>
> The patched part is inside a huge "while (parent)" loop.  The idea
> is to break out before the loop goes on to smudge later parents when
> we are in the "smudge only first parent as uninteresting, without
> contaminating the history leading to other parents" mode.
>
>  revision.c                   | 10 ++++++++--
>  t/t6012-rev-list-simplify.sh | 18 ++++++++++++++++++
>  2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git c/revision.c w/revision.c
> index e91d7e1f11..1f50d42a7a 100644
> --- c/revision.c
> +++ w/revision.c
> @@ -1151,12 +1151,18 @@ static int process_parents(struct rev_info *revs, struct commit *commit,
>                         if (p)
>                                 p->object.flags |= UNINTERESTING |
>                                                    CHILD_VISITED;
> -                       if (repo_parse_commit_gently(revs->repo, p, 1) < 0)
> +                       if (repo_parse_commit_gently(revs->repo, p, 1) < 0) {
> +                               if (revs->exclude_first_parent_only)
> +                                       break;
>                                 continue;
> +                       }
>                         if (p->parents)
>                                 mark_parents_uninteresting(revs, p);
> -                       if (p->object.flags & SEEN)
> +                       if (p->object.flags & SEEN) {
> +                               if (revs->exclude_first_parent_only)
> +                                       break;
>                                 continue;
> +                       }
>                         p->object.flags |= (SEEN | NOT_USER_GIVEN);
>                         if (queue)
>                                 prio_queue_put(queue, p);
> diff --git c/t/t6012-rev-list-simplify.sh w/t/t6012-rev-list-simplify.sh
> index 4cecb6224c..2284bbba12 100755
> --- c/t/t6012-rev-list-simplify.sh
> +++ w/t/t6012-rev-list-simplify.sh
> @@ -285,4 +285,22 @@ test_expect_success 'log --graph --simplify-merges --show-pulls' '
>         test_cmp expect actual
>  '
>
> +test_expect_success 'exclude-first-parent-only with parent already seen' '
> +       git checkout --orphan test-seen &&
> +       git rm -rf . &&
> +       test_commit r1 &&
> +       git checkout -b branch-f &&
> +       test_commit f &&
> +       git checkout test-seen &&
> +       git merge --no-ff --no-edit -m r2 branch-f &&
> +       git tag r2 &&
> +
> +       git rev-list --exclude-first-parent-only f ^r2 >actual &&
> +       git rev-parse f >expect &&
> +       test_cmp expect actual &&
> +
> +       git rev-list --exclude-first-parent-only f r1 ^r2 >actual2 &&
> +       test_cmp expect actual2
> +'
> +
>  test_done
>

Its been a while since i've looked at the code, but the rationale and test case make sense to me. thanks

Reviewed-by: Jerry Zhang <jerry@skydio.com>

Back to recent threads