Re: How is the ^{sha256} peel syntax supposed to work?

[Jeff King <peff@peff.net>]

On Wed, Aug 29, 2018 at 01:46:23PM -0700, Jonathan Nieder wrote:

> > Can you elaborate on that?
> 
> What I'm saying is, regardless of the syntax used, as a user I *need*
> a way to look up $some_hash as a sha256-name, with zero risk of Git
> trying to outsmart me and treating $some_hash as a sha1-name instead.
> 
> Any design without that capability is a non-starter.

Right, this is IMHO the only thing that makes sense for ^{hash} to do:
it disambiguates the sha1 that you just gave it. Nothing more, nothing
less.

> > I.e. if I'm using this in a script I'd need:
> >
> >     if x = git rev-parse $some_hash^{sha256}^{commit}
> >         hash = x
> >     elsif x = git rev-parse $some_hash^{sha1}^{commit}
> >         hash = x
> >     endif
> 
> Why wouldn't you use "git rev-parse $some_hash^{commit}" instead?

Yes, the sane rules seem to me to be:

  # try any available hash for $some_hash
  git rev-parse $some_hash

  # look _only_ for $some_hash as a sha1
  git rev-parse $some_hash^{sha1}

  # ditto for sha256
  git rev-parse $some_hash^{sha256}

  # ditto, but then peel the result to a commit
  git rev-parse $some_hash^{sha256}^{commit}

  # this is nonsense, and should produce an error
  git rev-parse $some_hash^{commit}^{sha256}

For convenience of scripts, we may also want:

  git rev-parse --input-hash=sha256 $some_hash

to pretend as if "^{sha256}" was appended to each command-line hash we
try to resolve (e.g., consider a case where a script is feeding 0 or
more hashes).

-Peff