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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Aug 29 2018, Jonathan Nieder 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?
>
> 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...

I'm not saying this makes sense, or that it doesn't honestly my head's
still spinning a bit from this mail exchange (these are the patches I
need to re-submit):
https://public-inbox.org/git/878t8txfyf.fsf@evledraar.gmail.com/#t

But paraphrasing my understanding of what Junio & Jeff are saying in
that thread, basically what the peel syntax means is different in the
two completely different scenarios it's used:

 1. When it's being used as <object>^{<thing>}[...^{<thing2>}] AND
    <object> is an unambiguous SHA1 it's fairly straightforward, i.e. if
    <object> is a commit and you say ^{tree} it lists the tree SHA-1,
    but if <object> is e.g. a tree and you say ^{blob} it produces an
    error, since there's no one blob.

 2. When it's used in the same way, but <object> is an ambiguous SHA1 we
    fall back on a completely different sort of behavior.

    Now it's, or well, supposed to be, I haven't worked through the
    feedback and rewritten the patches, this weird sort of filter syntax
    where <ambiguous_object>^{<type>} will return SHA1s of starting with
    a prefix of <ambiguous_object> IF the types of such SHA1s could be
    contained within that type of object.

    So e.g. abcabc^{tree} is supposed to list all tree and blob objects
    starting with a prefix of abcabc, even though some of the blobs
    could not be reachable from those trees.

    It doesn't make sense to me, but there it is.

Now, because of this SHA1 v.s. SHA256 thing we have a third case.

> what objects would you expect the following to refer to?
>
>   abcdabcd^{sha1}
>   abcdabcd^{sha256}
>   ef01ef01^{sha1}
>   ef01ef01^{sha256}

I still can't really make any sense of why anyone would even want #2 as
described above, but for this third case I think we should do this:

    abcdabcd^{sha1}   = abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd
    abcdabcd^{sha256} = ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01
    ef01ef01^{sha1}   = ef01ef01ef01ef01ef01ef01ef01ef01ef01ef01
    ef01ef01^{sha256} = abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd...

I.e. a really useful thing about this peel syntax is that it's
forgiving, and will try to optimistically look up what you want.

So e.g. <hash>^{commit} is not an error if <hash> is already a commit,
it could be (why are you trying to peel something already peeled!),
because it's useful to be able to feed it a set of things, some of which
are commits, some of which are tags, and have it always resolve things
without error handling on the caller side.

Similarly, I think it would be very useful if we just make this work:

    git rev-parse $some_hash^{sha256}^{commit}

And not care whether $some_hash is SHA-1 or SHA-256, if it's the former
we'd consult the SHA-1 <-> SHA-256 lookup table and go from there, and
always return a useful value.