GNU bug report logs - #50072
[PATCH WIP 0/4] Add upstream updater for git-fetch origins.

Previous Next

Full log

Message #164 received at 50072 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Sarah Morgensen <iskarian <at> mgsn.dev>, 50072 <at> debbugs.gnu.org
Subject: Re: bug#50072: [PATCH WIP 0/4] Add upstream updater for git-fetch
 origins.
Date: Wed, 05 Jan 2022 16:08:54 +0100

Hi Maxime,

On Wed, 05 Jan 2022 at 14:06, Maxime Devos <maximedevos <at> telenet.be> wrote:

> A low-level argument like #:nar-hash? #true/#false would make file-
> hash* much more complicated: this patch series uses file-hash* to
> compute the hash for 'origin' records, and the documentation of
> 'origin' doesn't mention 'nar' anywhere and if I search for 'nar hash'
> in the manual, I find zero results.

I agree, it was my point #1. :-)

> Instead, file-hash* talks about directories, regular files, recursion
> and claims that the default value of #:recursive? usually does the
> right thing, so I don't have to look up any complicated terminology
> to figure out how to use file-hash* to compute hashes for 'origin'
> records.

I also agree, it was my point #3. :-)

> And in the rare situation where file-hash* doesn't do the right thing,
> the documentation tells me I can set #:recursive? #true/#false.

Yes.


>> Just, to be sure, I am proposing:
>> 
>>  1) It is v4 and ready, I guess.  About ’auto’, I could have waken up
>>  earlier. :-) And it can be still improved later as you are saying in
>>  the other answer.  So, we are done, right?
>
> I think so, yes, except for a docstring change I'll send as a v5.
> I'm also out of bikeshed paint.
> Anway, keep in mind that I'm not a committer.

I am not either.  If I had this power, I would have already pushed your
v4 with the docstring reword. :-)


>>  2) From my point of view, ’#:recursive?’ needs to be adapted in
>>  agreement with the discussion [1], quoting Ludo:

[...]

>>    And I do not have a strong opinion.  Just a naive remark.

[...]

> Possibly some name like
> #:treat-it-as-a-directory-or-an-executable-file-or-a-symlink-and-
> compute-the-alternative-hash-even-if-it-is-regular?
> would be clearer and technically more accurate than #:recursive?, but
> that's a bit of a mouthful.

I trust you, I do not have a strong opinion.  I was just a naive remark.


>>  3) Whatever the keyword for the current v4 ’#:recursive?’ is picked, I
>>   still find the current docstring wording unclear.  In fact, reading
>>   the code is more helpful. :-) I am just proposing a reword which
>>   appears to me clearer than the current v4 one.  Maybe, I am missing
>>   the obvious.  Or maybe this proposed rewording is not clearer. :-)
>
> I've reworded it a bit; it falsely claimed that the nar hash was always
> computed when recursive? is 'auto' (even if FILE is a regular file). It
> also mentions executable files and SELECT? now.

Thank you for your patient work.


Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.