Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 29 2018, Jonathan Nieder wrote:
>> 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.
All the weight here is on the word "sensibly". Currently, ^{thing}
means "act on the object" and @{thing} means "act on the ref". This
^{sha1} syntax is really a new kind of modifier, ~{thing}, meaning
"act on the string".
That said, we can make it do anything we want. There is nothing
forcing us to make it more similar to ^{commit} than to
^{/searchstring}, say.
In that context:
[...]
>> Ævar Arnfjörð Bjarmason wrote:
>>> 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 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.
[...]
> 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?
Thanks,
Jonathan
