Jacob Keller <jacob.keller@xxxxxxxxx> writes: > 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. This depends on what an average user's perception is. People like I would know intimately that "format-patch" is just a glorified "log" with special features, so I wouldn't be surprised if somebody sends in a bug report saying "git -c log.mailmap=1 format-patch" does not honor the mailmap. In other words, people may expect "git log -1 -p --format=email HEAD" and "git format-patch -1 --stdout HEAD" to be pretty similar. > In our case, it may be more useful to have the mailmap not at > format-patch time but instead at email time... And probably you want not the regular mailmap but the custom one meant to be used only by send-email to ignore the recipient. You'd still want to see who wrote it back when they were employed with you in "git log" output, and not having them in your regular mailmap would be a way to do so. You can instead choose to use your regular mailmap to map them to their current address, which is what we seem to do here in this project, but it would probably be less common in $Corp settings. If the mailmap you give to send-email maps these dead mailboxes to some known pattern (e.g. a fixed string in the e-mail part, like "A U Thor <invalid@invalid>"), teaching send-email to recognise them would be trivial. Thanks.
