Le 14/11/2017 à 14:05, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxx> writes: > >> The triple dash is so that the diffstat/shortlog as not seen as >> part of the cover letter. As said in the cover letter for this >> series, it kinda breaks legacy behaviour right now. It should >> either be printed only for cover-at-tip, or a new separator should >> be added. > This reminds me of a couple of random thoughts I had, so before I > disconnect from my terminal and forget about them... > > [1] format-patch and am must round-trip. > > I mentioned four uses cases around the "cover letter at the > tip" in my earlier message > > https://public-inbox.org/git/xmqqbmk68o9d.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > Specifically, (2) we should be able to run "format-patch" and record > the log message of the empty commit at the tip to the cover letter, > and (4) we should be able to accept such output with "am" and end up > with the same sequence of commits as the original (modulo committer > identity and timestamps). So from the output we produce with this > step, "am" should be able to split the material that came from the > original empty commit from the surrounding cruft like shortlog and > diffstat. The output format of this step needs to be designed with > that in mind. This should be the case with the current RFC (apart from the branch description which is kept at the moment). Things like git am --signoff will break this of course. > > [2] reusing cover letter material in merge may not be ideal. > > When people write a cover letter, they write different things in it. > What they wanted to achieve, why they chose the approach they took, > how the series is organized, which part of the series they find iffy > and/orneeds special attention from the reviewers, where to find the > previous iteration, what changed since the previous iterations, etc. > > All of them are to help the reviewers, many of who have already > looked at the previous rounds, to understand and judge this round of > the submission. > > The message in a merge commit as a part of the final history, > however, cannot refer to anything from "previous rounds", as the > previous attempts are not part of the final history readers of "git > log" can refer to whey they are trying to understand the merge. > What exactly goes in a merge commit and how the messages are phrased > may be different from project to project, but for this project, I've > been trying to write them in an end-user facing terms, i.e. they are > designed in such a way that "git log --first-parent --merges" can be > read as if they were entries in the release notes, summarizing fixes > and features by describing their user-visible effects. This is only > one part of what people write in their cover letters (i.e. "what > they wanted to achive"). > > So there probably needs a convention meant to be followed by human > users when writing cover letters, so a mechanical process can tell > which part of the text is to be made into the merge commit without > understanding human languages. In the long term, I agree this would be nice. As a first step, could we force the --edit option when using --cover-at-tip ? The basic merge message would come from the cover letter but can/should be edited to clear the extra stuff out. Auto-stripping those extra infos, may also conflicts with the point (3) from your previous mail. If git merge is to keep only the relevant infos, git format-patch from this merge will not be able to access those. The advantage of a manual edit is that it's the commiter's choice. Keep the info if the branch is to be resubmitted. Drop them once it's merged for good. Nicolas
