On Fri, Nov 03, 2023 at 08:22:05AM +0000, Andy Koppe wrote: > > On 27/10/2023 19:40, Kousik Sanagavarapu wrote: > > So, if we have a domain-name, we grab it, else (the case where we don't > > have '@') we grab it as-is. Looks good. > > I'm not sure that this is the right way to handle a missing '@' here > actually, because %al already returns the whole email field in that case, > which makes sense as the likes of the 'mail' command would interpret it as a > local username. > > And if someone was going to use %al and the new specifier together to format > the parts of the email field differently, they probably wouldn't want the > field to appear twice. > > Therefore I think it would be more appropriate to expand to nothing in that > case. Tools that consume this output would already need to be able to deal > with the empty case, as it could also happen if there's a single '@' at the > end of the email field, or if the field is empty. I originally thought since localpart and the new domainpart are like counterparts (or are symmetrical, like Peff mentioned), falling back like in the case of localpart was the correct way here (again, symmetry). Having read your reasoning though I think it makes sense to not fall back the same way as localpart (%al) and return empty instead. This goes in favor of what Liam said in the original commit message of this feature being used to keep track of commits from different organizations (as in from GitHub or GitLab) or at least domains that make sense. As, if we return the whole email (where the email is with no domain-part or '@' is at the end of the email), the whole purpose of our new feature is lost. Thanks
