Hi, On Sun, Jan 29, 2017 at 7:06 PM, Cornelius Schumacher <schumacher@xxxxxxx> wrote: > This patch is a proof of concept implementation of support for > multiple authors. It adds an optional `authors` header to commits > which is set when there are authors configured in the git config. I am just wondering if you have read and taken into account the previous threads on this mailing list about the same subject, like for example this one: https://public-inbox.org/git/CAOvwQ4i_HL7XGnxZrVu3oSnsbnTyxbg8Vh6vzi4c1isSrrexYQ@xxxxxxxxxxxxxx/ > A new command `git-authors` is used to manage the authors settings. > Authors are identified by initials and their names and emails are > set in a `.git_authors_map` file. > > Signed-off-by: Cornelius Schumacher <schumacher@xxxxxxx> > --- > > When doing pair programming we have to work around the limitation that > git can only have a single author in each commit. There are some tools > which help with that such as [git-duet] [1], but there are still some > limits, because the information about multiple authors is not reflected > in the native git data model. > > Here is a proposal how to change that and implement native support for > multiple authors in git. It comes with a patch as a proof of concept. > The patch by no means is finished, it doesn't cover all cases and needs > more tests and error handling. It's meant as an illustration of the > concept. > > The basic idea is to introduce a new optional `authors` header in > commits which contains a list of authors. The header is set in each new > commit when there is an entry `authors.current` in the git config listing > the current authors. When this config is not there the behavior falls > back to the current standard behavior. > > When the header is there it is treated in the same way as the author > header. It's preserved on merges and similar operations, is displayed in > git show, and used to create a list of `From` addresses in `format-patch`. > Email supports multiple `From` addresses as specified in section 3.6.2 of > RFC 5322. > > When multiple authors are configured, they still write the standard author > header to keep backwards compatibility. The first author is used as author > and committer. In the future it might be good to implement something like > automatic rotation of the order of authors to give credit in a fair way. > > To make it easier to work with the authors there is a new command > `git-authors`. It sets the list of authors using initials as shortcut for > the full configuration with name and email. The mapping of initials to > names and email addresses is taken from a file `.git_authors_map` in the > home directory of the users. This way it's possible to quickly set a list > of authors by running a command such as `git authors ab cd`. This is > useful when doing pair programming because the people working together > usually switch quite frequently and using the command with the intials is > quicker and less error-prone than editing the configuration with full > names and emails. > > The command also supports setting a single author, setting more than two > authors or clearing the configuration for multiple authors to go back to > the standard behavior without the new authors header. > > The concept of the command and the mappings file is similar to what > git-duet does, so that it should be familiar to many people doing pair > programming. The behavior of git doesn't change when the new feature is > not used and when it's used it should be backwards compatible so that it > doesn't break existing functionality. This should make a smooth transition > for users who choose to make use of it. > > Adding support for multiple authors would make the life of developers doing > pair programming easier. It would be useful in itself, but it would also > need support by other tools around git to use its full potential. >From what I recall from previous discussions, the most important question is: are you sure that it doesn't break any other tool? > This > might take a while, but I think it's worth the effort. > > I'm willing to continue to work on this and create a patch which is suitable > for inclusion in git.