Re: [Bug???] In `git-rev-list(1)`, using the `--objects` flag doesn't work well with the `--not` flag, as non-commit objects are not excluded

Karthik Nayak [off-list ref] writes:

Hello!

What did you do before the bug happened? (Steps to reproduce your issue)

Assume a repository structure as follows:

- commit1 9f2aa2eb987c2281bb4901dbccd1398ad2c39722
  - tree: 205f6b799e7d5c2524468ca006a0131aa57ecce7
    - 100644 blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99    foo
      - content: foo
- commit2 9e02481f4df3a8997335b0a68882580e3b9b588f (parent:
9f2aa2eb987c2281bb4901dbccd1398ad2c39722)
  - tree: 672d0aa883d095369c56416587bc397eee4ac37e
    - 100644 blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99    foo
      - content: foo
    - 100644 blob eec8c88a93f6ee1515fb8348f2c122cfda4302cd    moo
      - content: moo
- commit3 91fa9611a355db77a07f963c746d57f75af380da (parent:
9e02481f4df3a8997335b0a68882580e3b9b588f)
   - tree 0c16a6cc9eef3fdd3034c1ffe2fc5e6d0bba2192
     - tree 086885f71429e3599c8c903b0e9ed491f6522879    bar
       - 100644 blob 7a67abed5f99fdd3ee203dd137b9818d88b1bafd    goo
         - content: goo
     - 100644 blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99    foo
       - content: foo
     - 100644 blob eec8c88a93f6ee1515fb8348f2c122cfda4302cd    moo
       - content: moo
     - 100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903    abc
       - content: abc
- commit4 6b52ed5b176604a0740689b5bb9be7bd79f4bced (parent:
9f2aa2eb987c2281bb4901dbccd1398ad2c39722)
  - tree ff05824d2f76436c61d2c971e11a27514aba6948
    - tree 086885f71429e3599c8c903b0e9ed491f6522879    bar
      - 100644 blob 7a67abed5f99fdd3ee203dd137b9818d88b1bafd    goo
        - content: goo
    - 100644 blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99    foo
      - content: foo
    - 100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903    abc
      - content: abc

The differences in commit object names become distracting, but I do
not think your example depends on them, so a minimum reproduction
recipe should be

	$ rm -fr new ; git init new ; cd new
	$ echo foo >foo
	$ git add -A; git commit -m one; git rev-parse HEAD:
	205f6b799e7d5c2524468ca006a0131aa57ecce7
	$ echo moo >moo
	$ git add -A; git commit -m two; git rev-parse HEAD:
	672d0aa883d095369c56416587bc397eee4ac37e
	$ mkdir bar; echo goo >bar/goo; echo abc >abc
	$ git add -A; git commit -m three; git rev-parse HEAD:
	0c16a6cc9eef3fdd3034c1ffe2fc5e6d0bba2192
	$ git rm moo; git commit -m four; git rev-parse HEAD:
	ff05824d2f76436c61d2c971e11a27514aba6948

	$ git rev-list --objects HEAD^..HEAD
	5a1b93c9c4c0c9e5c969f8e0b92a02184f8f9aab
	ff05824d2f76436c61d2c971e11a27514aba6948

that output lists HEAD and HEAD^{tree} in this order, which seems to
be what you are expecting.

I am consistently getting the same result with Git 2.42-rc2, 2.41,
2.21, and 2.20 (I do not have ones older than 2.20 around).

What did you expect to happen? (Expected behavior)

In such a repository, the output for the command, should have the
output provided below

❯ git rev-list --objects 6b52ed5b176604a0740689b5bb9be7bd79f4bced
--not 91fa9611a355db77a07f963c746d57f75af380da
6b52ed5b176604a0740689b5bb9be7bd79f4bced
ff05824d2f76436c61d2c971e11a27514aba6948

What happened instead? (Actual behavior)

Instead, the output is as follows:

❯ git rev-list --objects 6b52ed5b176604a0740689b5bb9be7bd79f4bced
--not 91fa9611a355db77a07f963c746d57f75af380da
6b52ed5b176604a0740689b5bb9be7bd79f4bced
ff05824d2f76436c61d2c971e11a27514aba6948
8baef1b4abc478178b004d62031cf7fe6db6f903 abc
086885f71429e3599c8c903b0e9ed491f6522879 bar
7a67abed5f99fdd3ee203dd137b9818d88b1bafd bar/goo

So, there is something else going on in *your* build of Git, or the
repository you prepared for testing, or both.