Re: Time to add a Git .mailmap? - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Time to add a Git .mailmap?
Date
Msg-id 4A514864-E673-4B96-9A8A-B4241B13AD1E@yesql.se
Whole thread Raw
In response to Re: Time to add a Git .mailmap?  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
> On 1 Nov 2024, at 13:53, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 01.11.24 12:53, Alvaro Herrera wrote:
>> On 2024-Oct-31, Daniel Gustafsson wrote:
>>> When looking at our Git tree for a recent conference presentation I happened to
>>> notice that we have recently gained duplicate names in the shortlog.  Not sure
>>> if we care enough to fix that with a .mailmap, but if we do the attached diff
>>> makes sure that all commits are accounted for a single committer entry.
>> LGTM.  I'd also add this line while at it:
>> Peter Eisentraut <peter@eisentraut.org> <peter_e@gmx.net>
>> This takes care of all the duplicate "identities" in the history AFAICT.
>
> I'm not sure if this is a good use of the mailmap feature.  If someone commits under <peter@companyfoo.com> for a
whileand then later as <peter@companybar.com>, and the mailmap maps everything to the most recent one, that seems kind
ofmisleading or unfair?  The examples on the gitmailmap man page all indicate that this feature is to correct
accidentalvariations or obvious mistakes, but not to unify everything to the extent that it alters the historical
record.

I agree with this and propose to leave it at the originally proposed mailmap
contents.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Repeat the condition check twice in function distribute_qual_to_rels
Next
From: Alexander Korotkov
Date:
Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure