Hello Benoit, > Akim Demaille would also like it to squash the commits added by the > merge (the new commits in OTHERS): > > YYYY-MM-DD Author <who@xxxxxxxxx> > > Merge whatever: > > YYYY-MM-DD Someone Else <foo@xxxxxxx> > Some change. > * FileChanged.c: Whatever. > > YYYY-MM-DD Who Cares <who@xxxxxxxxx> > Some other change. > * OtherFile.c: Do it. > > I thought this was mandated by the GNU Coding Standards but I > checked, it doesn't say anything about merges. Would this sort of > strategy be useful to you? Should it be default (or enabled by some > --squash option)? This merge is occurring in a different situation: The situation where we need ChangeLog merging most often is when a developer has made changes on his own and pulls in the changes from the remote repository (via "git stash; git pull; git stash apply"). The situation that Akim is describing is that he pulls changes from the repository of Someone Else and Who Cares, and then pushes them into the central repository, under his responsibility. For the first situation, the non-remote ChangeLog entries should be moved to the top, without modification or indentation. For the second situation, three different styles are in use at GNU (because they don't use "Signed-off" lines): 1) unmodified copying of the ChangeLog entries: YYYY-MM-DD Someone Else <foo@xxxxxxx> Some change. * FileChanged.c: Whatever. YYYY-MM-DD Who Cares <who@xxxxxxxxx> Some other change. * OtherFile.c: Do it. 2) copying with lieutenant's email address, like Akim described it: YYYY-MM-DD Lieu Tenant <who@xxxxxxxxx> YYYY-MM-DD Someone Else <foo@xxxxxxx> Some change. * FileChanged.c: Whatever. YYYY-MM-DD Who Cares <who@xxxxxxxxx> Some other change. * OtherFile.c: Do it. 3) similar, but with indentation of the entire copied-in ChangeLog entries: YYYY-MM-DD Lieu Tenant <who@xxxxxxxxx> YYYY-MM-DD Someone Else <foo@xxxxxxx> Some change. * FileChanged.c: Whatever. YYYY-MM-DD Who Cares <who@xxxxxxxxx> Some other change. * OtherFile.c: Do it. First of all, your merge driver could try to guess whether we're in the first or second situation (maybe by testing whether the names in the ChangeLog entry match the [user]name from the git config). Then, for the second situation, there can be some flag in the driver or in the git config that describes which of the 3 styles to apply. Bruno - 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
