On 2022-09-19 at 16:31:25, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > Your statement that you intended to write exactly such a feature was the > > main reason I dropped the SHA-256 hashed mailmap series. I don't think > > it's constructive to offer or propose to offer such a feature in Git if > > we're trying to obscure people's names in the mailmap, ... > > Yes, I remember that exchange, and I find your position reasonable. > Yes, we all know how to build such a feature. Yes, we know a > third-party implementation of such a feature may materialize. > > But we do not have to be the ones to encourage use of such a > feature. Sure. The goal is to make the tool more friendly (at least to some folks) to use. Other people can worsen the experience; we don't have to do that. As I said, if we're willing to commit to not add such a decoding feature to Git, I'm happy to resurrect my hashed mailmap approach with or without changes and get it ready to merge. It sounds like that might be an approach we're comfortable with here. > > I also have an alternate proposal which I pitched to some folks at Git > > Merge and which I just finished writing up that basically moves personal > > names and emails out of commits, replacing them with opaque identifiers, > > That part I can agree with. > > > and using a constantly squashed mailmap commit in a special ref to store > > the mapping. > > This part only half (the "special ref" half, not "constatntly > squashed" part, even though I know why it matters more to your > goal). My gut feeling is that auditing and merging will become > nightmare. Since it's not clear to me, you're saying you think a special ref is fine, but having it be constantly squashed is not? If so, I will say that my proposal in the other thread will let folks keep a history if they want with a config option (although that means you may need to rewrite history once in a while if someone changes their name). In my workflow and in the workflow of folks who primarily work with forges, that isn't necessary, and the mailmap, if it's even required, can be maintained independently or even automatically. For example, I could imagine GitHub writing my display name into the mailmap file automatically when one of my pull requests is merged if I and the repository owner have such an option configured. However, in my proposed patch workflow, git am does the work for you by updating the ref automatically, so all you need to do is literally apply patches with mailmap headers and then push the ref once in a while. I'm definitely open to discussing this approach more if we think it can be formed into something viable. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
