Frans Klaver <fransklaver@xxxxxxxxx> wrote: > I always thought of the author field as being an indication of who is > ultimately responsible for its implementation (the one in the > pestering spot). Define 'ultimate responsibility for an implementation'. I'm further developing patches that Val has (at least partially) implemented. By Val's admission some of the patches she further developed beyond what Jan Blunck had implemented. The chain may extend further. To that end all three of us are authors of some of the patches. However, if you meant 'maintenance' rather than 'implementation', then, yes, that would be me (for the moment at least). But if that's the case, then shouldn't it be 'Maintainer' and not 'Author'? And, besides, that's what the MAINTAINERS file is for. > (1) may seem desirous, but doesn't (2) seem like a cleaner and more > maintainable solution? No. I would say that properly supporting multiple authors in the commit object is the cleaner solution. It's not the *easier* solution, however, and would require an upgrade to the version of GIT used to parse these commits. That I'll grant you. > Gitweb will show the entire log message if people are interested in the > exact change, right? But if I say to Gitweb "show me the patches authored by Val" it will *not* turn up these patches, and in that way will deny Val credit. Yes, you can see that Val altered that patch if you look at that patch directly - but you have to know where to go and look, in which case you already know or suspect that Val is credited with patches in that area. So to make (2) work, Gitweb needs to search for the additional authoring fields when asked to credit people with the patches they've worked on. Similarly gitk and possibly other tools would need to do the same. *That* would be fine by me, I suppose. I don't think it's the correct way to do it, but it might be the logical way since this wasn't build in from the beginning - and the main thing would be to turn up the prior or joint authorship to author-based searches. David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html