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

Re: [PATCH] builtin/commit.c: memoize git-path for COMMIT_EDITMSG

From
Pranit Bauva <pranit.bauva@gmail.com>
Date
May 24, 2016, 05:54 UTC
Message-ID
<CAFZEwPN3L5Y-7wNj6TMjg-jPb_oDQYjukBj1uL6OJ8rWAoqjcQ@mail.gmail.com>
In-Reply-To
<xmqq7feka8kk.fsf@gitster.mtv.corp.google.com>
Hey Junio,
On Tue, May 24, 2016 at 12:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 47 quoted lines
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> This is a follow up commit for f932729c (memoize common git-path
>> "constant" files, 10-Aug-2015).
>>
>> It serves two purposes:
>>   1. It reduces the number of calls to git_path() .
>>
>>   2. It serves the benefits of using GIT_PATH_FUNC as mentioned in the
>>      commit message of f932729c.
>
> All of that is a good idea, but I have huge doubts about its use.
>
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index 391126e..ffa242c 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -92,8 +92,10 @@ N_("If you wish to skip this commit, use:\n"
>>  "Then \"git cherry-pick --continue\" will resume cherry-picking\n"
>>  "the remaining commits.\n");
>>
>> +static GIT_PATH_FUNC(git_path_commit_editmsg, "COMMIT_EDITMSG")
>> +
>>  static const char *use_message_buffer;
>> -static const char commit_editmsg[] = "COMMIT_EDITMSG";
>> +static const char commit_editmsg_path[] = git_path_commit_editmsg();
>
> The function defined with the macro looks like
>
>         const char *git_path_commit_editmsg(void)
>         {
>                 static char *ret;
>                 if (!ret)
>                         ret = git_pathdup("COMMIT_EDITMSG");
>                 return ret;
>         }
>
> so receiving its result to "const char v[]" looks somewhat
> suspicious.
>
> More importantly, when is this function evaluated and returned value
> used to fill commit_editmsg_path[]?  In order for git_pathdup() to
> produce a meaningful result, it needs to know where .git/ directory
> is, which (roughly) means setup_git_dir() must have been called from
> a callchain from main() somewhere already.
>
> But I do not think the linker knows that fact.

I think otherwise. git_pathdup() calls get_worktree_git_dir() which calls get_git_dir() which if uninitialized calls setup_git_env(). So technically the code gets to know the .git/ directory quite early. Though I am not very sure whether this one is a desirable fact. There would be later instances which would in turn call to know where the .git/ directory.

Show 24 quoted lines
>
>> @@ -771,9 +773,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
>>               hook_arg2 = "";
>>       }
>>
>
> Instead, what you could do is to call git_path_commit_editmsg() when
> you refer to that global variable whose initialization is suspect.
>
>> -     s->fp = fopen_for_writing(git_path(commit_editmsg));
>> +     s->fp = fopen_for_writing(commit_editmsg_path);
>
> i.e.
>
>         s->fp = fopen_for_writing(git_path_commit_editmsg());
>
> As you can see in its definition, when the original code used to
> call git_path(), it is safe to call git_path_commit_editmsg(),
> because for the original git_path() to be correct, the code should
> already have established where $GIT_DIR is, so it is safe to call
> git_pathdup(), too.  Also, as you can see in its definition, calling
> the function many times would not cause git_path() called many
> times.  The first invocation will keep its value that is constant
> within the program that works with a constant $GIT_DIR.

I agree that it is actually not required to again compute the location of .git/ directory and can only return the value.

Overall I agree to your idea of just using git_path_commit_editmsg() instead of git_path() so as to not disturb any previous implementations which can lead to some complications. Also if I am changing some internal semantics there should be a valid reason which there isn't really as I don't see any benefit in getting the location of .git/ early in the program.

> And you do not free its return value.

This is one of the thing that bugging me with GIT_PATH_FUNC. Wouldn't not freeing the memory lead to memory leaks?

Regards, Pranit Bauva

Previous: Junio C HamanoNext: Pranit Bauva
Message 3 of 12 in “builtin/commit.c: memoize git-path for COMMIT_EDITMSG”
  1. builtin/commit.c: memoize git-path for COMMIT_EDITMSGPranit Bauva, May 23, 2016
  2. Junio C HamanoMay 23, 2016
  3. Pranit BauvaMay 24, 2016
  4. Pranit BauvaMay 24, 2016
  5. Matthieu MoyMay 24, 2016
  6. Pranit BauvaMay 24, 2016
  7. Junio C HamanoMay 24, 2016
  8. builtin/commit.c: memoize git-path for COMMIT_EDITMSGPranit Bauva, May 24, 2016
  9. Pranit BauvaJun 7, 2016
  10. Jeff KingJun 9, 2016
  11. Pranit BauvaJun 9, 2016
  12. Junio C HamanoJun 9, 2016

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.