git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

From
Rafael Ascensão <rafa.almas@gmail.com>
Date
Nov 4, 2017, 07:33 UTC
Message-ID
<1e2e8f85-e13d-47f9-6661-1e685250c775@gmail.com>
In-Reply-To
<xmqqo9oiok10.fsf@gitster.mtv.corp.google.com>
On 04/11/17 02:27, Junio C Hamano wrote:
Show 17 quoted lines
> Rafael Ascensão <rafa.almas@gmail.com> writes:
> 
>> Signed-off-by: Kevin Daudt <me@ikke.info>
>> Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
> 
> Could you explain Kevin's sign-off we see above?  It is a bit
> unusual (I am not yet saying it is wrong---I cannot judge until I
> find out why it is there) to see a patch from person X with sign off
> from person Y and then person X in that order.  It is normal for a
> patch authored by person X to have sign-off by X and then Y if X
> wrote it, signed it off and passed to Y, and then Y resent it after
> signing it off (while preserving the authorship of X by adding an
> in-body From: header), but I do not think that is what we have here.
> 
> It could be that you did pretty much all the work on this patch
> and Kevin helped you to polish this patch off-list, in which case
> the usual thing to do is to use "Helped-by: Kevin" instead.

That's more or less what happened. I wouldn't say I did "pretty much all the work". Yes, I wrote the code but with great help of Kevin. The intention of the dual Signed-off-by was to equally attribute authorship of the patch. But if that creates ambiguity I will change it to "Helped-by" as suggested.

Show 5 quoted lines
> It is better to use "unsigned" for a single word "flags" used as a
> collection of bits.  In older parts of the codebase, we have
> codepaths that pass signed int as a flags word, simply because we
> didn't know better, but we do not have to spread that practice to
> new code.

I noticed this, but chose to "mimic" the code around me. I'll correct it. On a related note is there a guideline for defining flags or are `#define FLAG (1u << 0)`, `#define FLAG (1 << 0)` `#define FLAG 1` and `#define FLAG 0x1` equally accepted?

Show 38 quoted lines
>>   {
>> -	struct strbuf real_pattern = STRBUF_INIT;
>> -	struct ref_filter filter;
>> -	int ret;
>> -
>>   	if (!prefix && !starts_with(pattern, "refs/"))
>> -		strbuf_addstr(&real_pattern, "refs/");
>> +		strbuf_addstr(normalized_pattern, "refs/");
>>   	else if (prefix)
>> -		strbuf_addstr(&real_pattern, prefix);
>> -	strbuf_addstr(&real_pattern, pattern);
>> +		strbuf_addstr(normalized_pattern, prefix);
>> +	strbuf_addstr(normalized_pattern, pattern);
>>   
>> -	if (!has_glob_specials(pattern)) {
>> +	if (!has_glob_specials(pattern) && (flags & ENSURE_GLOB)) {
>>   		/* Append implied '/' '*' if not present. */
>> -		strbuf_complete(&real_pattern, '/');
>> +		strbuf_complete(normalized_pattern, '/');
>>   		/* No need to check for '*', there is none. */
>> -		strbuf_addch(&real_pattern, '*');
>> +		strbuf_addch(normalized_pattern, '*');
>>   	}
>> +}
> 
> The above looks like a pure and regression-free code movement (plus
> a small new feature) that is faithful to the original, which is good.
> 
> I however notice that addition of /* to the tail is trying to be
> careful by using strbuf_complete('/'), but prefixing with "refs/"
> does not and we would end up with a double-slash if pattern begins
> with a slash.  The contract between the caller of this function (or
> its original, which is for_each_glob_ref_in()) and the callee is
> that prefix must not begin with '/', so it may be OK, but we might
> want to add "if (*pattern == '/') BUG(...)" at the beginning.
> 
> I dunno.  In any case, that is totally outside the scope of this two
> patch series.
I guess it doesn't hurt adding that safety net.
> Thanks.  Other than the above minor points, looks good to me.
I'll fix the mentioned issues. Thanks.
Previous: Junio C HamanoNext: Kevin Daudt
Message 4 of 24 in “Add option to git log to choose which refs receive decoration”
  1. 0/2 Add option to git log to choose which refs receive decorationRafael Ascensão, Nov 4, 2017
  2. 1/2 refs: extract function to normalize partial refsRafael Ascensão, Nov 4, 2017
  3. Junio C HamanoNov 4, 2017
  4. Rafael AscensãoNov 4, 2017
  5. Kevin DaudtNov 4, 2017
  6. Michael HaggertyNov 5, 2017
  7. Michael HaggertyNov 5, 2017
  8. Junio C HamanoNov 6, 2017
  9. Rafael AscensãoNov 6, 2017
  10. Michael HaggertyNov 6, 2017
  11. 2/2 log: add option to choose which refs to decorateRafael Ascensão, Nov 4, 2017
  12. Junio C HamanoNov 4, 2017
  13. Rafael AscensãoNov 4, 2017
  14. Junio C HamanoNov 5, 2017
  15. Junio C HamanoNov 5, 2017
  16. Rafael AscensãoNov 6, 2017
  17. Junio C HamanoNov 6, 2017
  18. Michael HaggertyNov 6, 2017
  19. Jacob KellerNov 6, 2017
  20. Junio C HamanoNov 7, 2017
  21. Rafael AscensãoNov 10, 2017
  22. Junio C HamanoNov 10, 2017
  23. log: add option to choose which refs to decorateRafael Ascensão, Nov 21, 2017
  24. Junio C HamanoNov 22, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.