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

Re: [PATCH v7 5/6] refs: allow reference location in refstorage config

From
Karthik Nayak <karthik.188@gmail.com>
Date
Feb 22, 2026, 20:15 UTC
Message-ID
<CAOLa=ZQsfOpP1cxFCjLWqbfxQ_upzuKHDojhNYtU=oFmeZsjVw@mail.gmail.com>
In-Reply-To
<xmqqbjhjz793.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 39 quoted lines
> Toon Claes <toon@iotcl.com> writes:
>
>>> +static void parse_reference_uri(const char *value, char **format,
>>> +				char **payload)
>>> +{
>>> +	const char *schema_end;
>>> +
>>> +	schema_end = strstr(value, "://");
>>> +	if (!schema_end) {
>>> +		*format = xstrdup(value);
>>> +		*payload = NULL;
>>> +	} else {
>>> +		*format = xstrndup(value, schema_end - value);
>>> +		*payload = xstrdup_or_null(schema_end + 3);
>>
>> Also here, why did you put the negated condition in the if clause?
>
> Hmph, would it make it easier to follow if you swap them?
>
> 	if (schema_end) {
> 		*format = xstrndup(value, schema_end - value);
> 		*payload = xstrdup_or_null(schema_end + 3);
> 	} else {
> 		*format = xstrdup(value);
> 		*payload = NULL;
> 	}
>
> Maybe it is just me, but I often find it easier to follow if the
> case that require shorter and/or simpler body, or the case that is
> narrower (e.g., error condition), comes first before the main logic.
> It is in line with preferring an early return on a more specific
> condition.  It frees readers from having to worry about these cases
> early and let them concentrate on what is expected to usually happen
> in the code.
>
> In this particular case, I do not know which one I would prefer,
> though.
>
> Thanks.

Kinda similar thought process. Since the URI format is new, the most likely case here is that 'strstr' will not find a match. That's why the negative case is first.

But I'd be happy to change, if others feel differently.
Karthik
Previous: Junio C HamanoNext: Karthik Nayak
Message 12 of 15 in “refs: allow setting the reference directory”
  1. 0/6 refs: allow setting the reference directoryKarthik Nayak, Feb 19, 2026
  2. 1/6 setup: don't modify repo in `create_reference_database()`Karthik Nayak, Feb 19, 2026
  3. 2/6 refs: extract out `refs_create_refdir_stubs()`Karthik Nayak, Feb 19, 2026
  4. 3/6 refs: move out stub modification to generic layerKarthik Nayak, Feb 19, 2026
  5. Toon ClaesFeb 20, 2026
  6. 4/6 refs: receive and use the reference storage payloadKarthik Nayak, Feb 19, 2026
  7. Toon ClaesFeb 20, 2026
  8. Karthik NayakFeb 22, 2026
  9. 5/6 refs: allow reference location in refstorage configKarthik Nayak, Feb 19, 2026
  10. Toon ClaesFeb 20, 2026
  11. Junio C HamanoFeb 20, 2026
  12. Karthik NayakFeb 22, 2026
  13. 6/6 refs: add GIT_REFERENCE_BACKEND to specify reference backendKarthik Nayak, Feb 19, 2026
  14. Patrick SteinhardtFeb 19, 2026
  15. Karthik NayakFeb 20, 2026

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.