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

Re: [PATCH 2/2] cleanup submodule_config a bit.

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Aug 12, 2015, 22:01 UTC
Message-ID
<CAPig+cT0+zh2v=NfB3RTwadfHoqB+VRTvbnMcdZ_g3RwtVzisg@mail.gmail.com>
In-Reply-To
<CAGZ79kbV45LqxCha516dRNYAjAH71mxce6Xazvfmf1deLMzUxQ@mail.gmail.com>
On Wed, Aug 12, 2015 at 5:34 PM, Stefan Beller <sbeller@google.com> wrote:
Show 38 quoted lines
> On Wed, Aug 12, 2015 at 2:13 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Wed, Aug 12, 2015 at 3:13 PM, Stefan Beller <sbeller@google.com> wrote:
>>>         if (!gitmodule_sha1_from_commit(commit_sha1, sha1))
>>> -               return submodule;
>>> +               return NULL;
>>
>> There are a couple other places which return 'submodule' when it is
>> known to be NULL. One could rightly expect that they deserve the same
>> treatment, otherwise, the code becomes more confusing since it's not
>> obvious why 'return NULL' is used some places but not others.
>
> They were slightly less obvious to me, fixed now as well!
>
>>> @@ -420,14 +420,12 @@ static const struct submodule *config_from(struct submodule_cache *cache,
>>>         switch (lookup_type) {
>>>         case lookup_name:
>>> -               submodule = cache_lookup_name(cache, sha1, key);
>>> -               break;
>>> +               return cache_lookup_name(cache, sha1, key);
>>>         case lookup_path:
>>> -               submodule = cache_lookup_path(cache, sha1, key);
>>> -               break;
>>> +               return cache_lookup_path(cache, sha1, key);
>>> +       default:
>>> +               return NULL;
>>>         }
>>> -
>>> -       return submodule;
>>
>> Earlier in the function, there's effectively a clone of this logic to
>> which you could apply the same transformation. Changing it here, while
>> ignoring the clone, makes the code more confusing (or at least
>> inconsistent) rather than less.
>
> Not quite. Note the `if (submodule)` in the earlier version, so in case
> cache_lookup_{name, path} return NULL, we keep going. The change I
> propose is at the end of the function and we definitely return no matter
> if it is NULL or not.

Okay, cache_lookup_{name, path}() can indeed return NULL, so the same transformation won't work. Sorry for the noise.

Previous: Stefan BellerNext: Junio C Hamano
Message 6 of 7 in “Re: [PATCH v5 0/4] submodule config lookup API”
  1. Stefan BellerAug 12, 2015
  2. 1/2 Fixup hv/documentationStefan Beller, Aug 12, 2015
  3. 2/2 cleanup submodule_config a bit.Stefan Beller, Aug 12, 2015
  4. Eric SunshineAug 12, 2015
  5. Stefan BellerAug 12, 2015
  6. Eric SunshineAug 12, 2015
  7. Junio C HamanoAug 12, 2015

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.