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

[Stefan Beller <sbeller@google.com>]

On Wed, Aug 29, 2018 at 10:59 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Stefan Beller wrote:
>
> >                  And with that model, <hexdigits>^{sha256}^{tree}
> > could mean to obtain the sha256 value of <hexvalue> and then derive
> > the tree from that object,
>
> What does "the sha256 value of <hexvalue>" mean?

s/hexvalue/hexdigits/
..

And with that model, <hexdigits>^{sha256}^{tree}
could mean to obtain the object using sha256 descriptors
(for trees/blobs/commits/tags) of <hexdigits> (as defined by
the step of the transition plan, it could mean <hexdigits>
to be interpreted as SHA1 or SHA256 or DWIM).

>
> For example, in a repository with two objects:
>
>  1. an object with sha1-name abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd
>     and sha256-name ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01
>
>  2. an object with sha1-name ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01
>     and sha256-name abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd...
>

It would be super cool to have hash values to match vice versa,
but for the sake of the example, let's go with that.

> what objects would you expect the following to refer to?

That generally depends on the step of the transition plan
in that specific Git repository.

I thought these format specifiers would only describe how to
output the object names correctly for now, so it could be
possible to have:

$ git show abcdabcd^{sha1}
commit abcdabcd...
....

$ git show abcdabcd^{sha256}
commit ef01ef01e...
....

in one step and

$ git show abcdabcd^{sha1}
commit ef01ef01e...
....

$ git show abcdabcd^{sha256}
commit abcdabcd...
....

in another step, and in yet another step it could mean

$ git show abcdabcd^{sha1}
commit abcdabcd[...]^{sha1}
...

But my question was more hinting to the point that we should not
overload the syntax to mean much more than either output formatting
or hash selection.

The third meaning could be used for verifying objects as we could
use this syntax to mean

  "please verify the signature of the object (as given by ^{hash}"

or it could mean

  "please verify the signature of the object as given and ensure that
    it was signed in this ^{hash} and not in a weaker hash world".

And I would think all the verification should not be folded into this
notation for now, but we only want to ask for the output to be
one or the other hash, or we could ask for an object that is
<hexdigits> in the specified hash, but these two modes depend
on the step in the transition plan.

Stefan