Re: [PATCH] mailmap: only look for .mailmap in work tree

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2021, 20:10 UTC
Message-ID: <xmqqblcr3crp.fsf@gitster.c.googlers.com>
In-Reply-To: <YCQGqeHB4rXi6dG0@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 28 quoted lines

> On Tue, Feb 09, 2021 at 01:23:32PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> >   If the file `.mailmap` exists at the toplevel of the repository[...]
>> >
>> > which likewise reinforces the notion that we are looking in the working
>> > tree.
>> 
>> > diff --git a/mailmap.c b/mailmap.c
>> > index eb77c6e77c..9bb9cf8b30 100644
>> > --- a/mailmap.c
>> > +++ b/mailmap.c
>> > @@ -225,7 +225,8 @@ int read_mailmap(struct string_list *map)
>> >  	if (!git_mailmap_blob && is_bare_repository())
>> >  		git_mailmap_blob = "HEAD:.mailmap";
>> >  
>> > -	err |= read_mailmap_file(map, ".mailmap");
>> > +	if (!startup_info->have_repository || !is_bare_repository())
>> > +		err |= read_mailmap_file(map, ".mailmap");
>> 
>> OK.  Do we know at this point that cwd is always/already at the root
>> level of the working tree?
>
> I think so. If we're in a non-bare repository, we'd have chdir'd during
> the setup/discovery steps. At any rate, this patch could not possibly be
> making such a situation _worse_, as we were previously reading it
> unconditionally.

But the point of the patch is to ensure that we only read from the top of the working tree---I wanted to make sure that we previously weren't reading it from any subdirectory the command started.

> If you are proposing that this become:
> ...

Not really. As long as we know we would already have moved to the top, then what we have above is perfectly fine.

Show 6 quoted lines

> .... I suspect it may even be necessary to use a mailmap in
> an in-process submodule repository (in which case we should be taking a
> "struct repository" argument and checking it in the first two branches
> of the conditional). But this is orthogonal to what my patch is doing, I
> think. And I'd rather punt on it until there is a known upside (probably
> as part of a larger effort to allow mailmaps outside of the_repository).

Yeah, I was not interested in what happens with in-process submodule, and I'd rather leave the code as close to as-is, until it becomes necessary to update it.

Thanks.