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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Aug 29, 2018, 19:37 UTC
Message-ID: <87y3cpc6bt.fsf@evledraar.gmail.com>
In-Reply-To: <20180829191232.GC7547@aiede.svl.corp.google.com>

On Wed, Aug 29 2018, Jonathan Nieder wrote:

Show 31 quoted lines

> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>
>>> 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.
>
> Sorry, I'm still not understanding.
>
> I am not attached to any particular syntax, but what I really want is
> the following:
>
> 	Someone who only uses SHA-256 sent me the commit id
> 	abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd... out of band.
> 	Show me that commit.

This is reasonable.

Show 7 quoted lines

> 	I don't care what object id you show me when you show that
> 	commit.  If I pass --output-format=sha1, then that means I
> 	care, and show me the SHA-1.
>
> In other words, I want the input format and output format completely
> decoupled.  If I pass ^{sha1}, I am indicating the input format.  To
> specify the output format, I'd use --output-format instead.

This is also a reasonable thing to want, but I don't see how it can be sensibly squared with the existing peel syntax.

The peel syntax <thing>^{commit} doesn't mean <thing> is a commit, it means that thing might be some thing (commit, tag), and it should be (recursively if needed) *resolved* as the thing on the RHS.

So to be consistent <thing>^{sha1} shouldn't mean <thing> is SHA-1, but that I want a SHA-1 out of <thing>.

> That lets me mix both hash functions in my input:
>
> 	git --output-format=sha256 diff abcdabcd^{sha1} abcdabcd^{sha256}

Presumably you mean something like:

     git diff-tree --raw -r -p bcdabcd^{sha1} abcdabcd^{sha256}

I.e. we don't show any sort of SHAs in diff output, so what would this --output-format=sha256 mean?

> I learned about these two commits out of band from different users,
> one who only uses SHA-1 and the other who only uses SHA-256.

I think for those cases we would just support:

     git diff-tree --raw -r -p bcdabcd abcdabcd

I.e. there's no need to specify the hash type, unless the two happen to be ambiguous, but yeah, if that's the case we'd need to peel them (or supply more hexdigits).

Show 12 quoted lines

> In other words:
>
> [...]
>> 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.
>
> The opposite of this. :)

Can you elaborate on that? What do you think that should do? Return an error if $some_hash is SHA-1, even though we have a $some_hash = $some_hash_256 mapping?

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

As opposed to the thing I'm saying is the redeeming quality of the peel syntax:

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