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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Ævar Arnfjörð Bjarmason wrote:
> On Fri, Aug 24 2018, Jonathan Nieder wrote:
>> Ævar Arnfjörð Bjarmason wrote:

>>> Or is this expected to be chained, as e.g. <object>^{tag}^{sha256} ?
>>
>> Great question.  The latter (well, <hexdigits>^{sha256}^{tag}, not the
>> other way around).
>
> Since nobody's chimed in with an answer, and I suspect many have an
> adversion to that big thread I thought I'd spin out just this small
> question into its own thread.
>
> brian m. carlson did some prep work for this in his just-submitted
> https://public-inbox.org/git/20180829005857.980820-2-sandals@xxxxxxxxxxxxxxxxxxxx/
>
> I was going to work on some of the peel code soon (digging up the type
> disambiguation patches I still need to re-submit), so could do this
> while I'm at it, i.e. implement ^{sha1}.

Cool!

> But as noted above it's not clear how it should work. Jonathan's
> chaining suggestion (<hexdigits>^{sha256}^{tag} not
> <hexdigits>^{tag}^{sha256}) makes more sense than mine, but is that what
> we're going for, or ^{sha256:tag}?

I don't have a strong opinion about this, but since it affects the
interpretation of <hexdigits>, my assumption has been that, in the
spirit of referential transparency, you would put
'<hexdigits>^{format}' and could put any additional specifiers after
that.

In other words, ^{format} changes the interpretation of <hexdigits> so
my assumption is that people would want it to be close by.

But if something else is easier to implement, we can start with that
something else and figure out whether we like it in review.

Thanks,
Jonathan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux