Re: [PATCH] format-patch: add support for mailmap file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 14, 2024, 12:26 AM Jeff King <peff@xxxxxxxx> wrote:
> On Tue, Aug 13, 2024 at 05:20:41PM -0700, Jacob Keller wrote:
> > The internal tree commits are already baked and can't be changed. We can
> > of course fix the generated patches from these commits manually. It
> > seemed convenient to get mailmap to do this for us.
>
> I think that makes sense, especially if the caller is specifically
> asking to enable address mapping. I do wonder if the new format.mailmap
> might be surprising for some callers, though. For example, would a
> rebase using the "apply" backend quietly rewrite commit authors using
> the mailmap?
>
> -Peff

Ya, I think the config probably doesn't make sense thinking about it.

I also realized the actual problem we have is that the mail we send is
including a dead address. It would make more sense to just allow
send-email to translate from the old addresses to the canonical ones.

Specifically the issue we had is that an old commit to the internal
repo was prepped for submission by a new owner, and when he sent the
email, it automatically included the address of the original author,
which ofcourse no longer is valid. This resulted in the mail annoying
several people due to bouncing.

So the real problem to solve here is perhaps some way to filter the
mails either via translation or removal so that we don't have it
tagged to or cc a dead email. As I said above, its not like we expect
the original author to actually respond or own the change, but we did
not want to completely remove their name from the change, because they
are the original person who wrote it.

In our case, it may be more useful to have the mailmap not at
format-patch time but instead at email time...

Thanks,
Jake





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux