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
