bug: "rev-parse --short" with "--not --remote"

Brent Casavant· Oct 11, 2019, 20:10 UTC · lore

Hello,

I noticed what appears to be a bug in rev-parse with an admittedly somewhat unusual combination of arguments.

Compare the output of the following:

% git rev-parse HEAD --not --remotes=origin 3de09080eb219149a8596dc21915d5a496cba171 ^4fb157bf360413fe3fad38d03b02ce7232d12961 ^757cfa6938c3d510d1597096d9f0b6878b884270

To this:

% git rev-parse --short HEAD --not --remotes=origin ^4fb157b ^757cfa6 ^3de0908

In the first case rev-parse emits the commit-id of HEAD, followed by negated commit-ids of all remote branches in origin.  I believe this is the correct and intended behavior.

In the second case rev-parse emits the negated short commit-ids of all remote branches in origin, followed by the negated short commit-id of HEAD.  This is inconsistent with the results of the (presumably correct) prior example.

I would expect both commands to emit the same output, modulo the number of characters emitted for the commit-id.

Thank you, Brent Casavant

-- 
Brent Casavant
Hewlett Packard Enterprise

Jeff King· Oct 11, 2019, 20:58 UTC · re: Brent Casavant · lore

Re: bug: "rev-parse --short" with "--not --remote"

On Fri, Oct 11, 2019 at 03:10:33PM -0500, Brent Casavant wrote:

Show 28 quoted lines

> I noticed what appears to be a bug in rev-parse with an admittedly
> somewhat unusual combination of arguments.
> 
> Compare the output of the following:
> 
> % git rev-parse HEAD --not --remotes=origin
> 3de09080eb219149a8596dc21915d5a496cba171
> ^4fb157bf360413fe3fad38d03b02ce7232d12961
> ^757cfa6938c3d510d1597096d9f0b6878b884270
> 
> To this:
> 
> % git rev-parse --short HEAD --not --remotes=origin
> ^4fb157b
> ^757cfa6
> ^3de0908
> 
> In the first case rev-parse emits the commit-id of HEAD, followed by
> negated commit-ids of all remote branches in origin.  I believe this
> is the correct and intended behavior.
> 
> In the second case rev-parse emits the negated short commit-ids of all
> remote branches in origin, followed by the negated short commit-id of
> HEAD.  This is inconsistent with the results of the (presumably
> correct) prior example.
> 
> I would expect both commands to emit the same output, modulo the
> number of characters emitted for the commit-id.

That's what I'd have naively expected, too, but that's not what "--short" is documented to do:

  $ git help rev-parse | grep -A2 -e --short
         --short[=length]
	     Same as --verify but shortens the object name to a unique
	     prefix with at least length characters. The minimum length
	     is 4, the default is the effective value of the core.abbrev
	     configuration variable (see git-config(1)).

and --verify itself is a bit magical:

  $ git help rev-parse | grep -m1 -A2 -e --verify
         --verify
	     Verify that exactly one parameter is provided, and that it
	     can be turned into a raw 20-byte SHA-1 that can be used to
	     access the object database. If so, emit it to the standard
	     output; otherwise, error out.

You can see the same weirdness with --verify (e.g., `git rev-parse --verify HEAD --not --remotes=origin`). And I think it is kind of buggy, in that I'd expect it to complain about seeing more than one parameter.

I'm not sure exactly what you're trying to do. If you actually want a traversal, you probably should be using rev-list (with --abbrev-commit if you want to abbreviate). If you just want to resolve some names without traversing, you might be better off using for-each-ref or similar.

-Peff