Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > The basic issue is how to sanely keep track of a cover letter when you > have a branch that you haven't sent out yet, but will ask somebody to > pull. It may still be seeing more testing and development before that > pull happens, though. > > This very much smells of what the "branch description" is all about, but > > (a) I suspect "git branch --edit-description" is not very well known True. > (b) it works well with "git request-pull", but not so much some other > things (like copying it into a signed tag) I think that is just a matter of programming ;-) > (c) it makes an unholy mess of your config file if you actually use > it for extensive explanations (branch descriptions _work_ for > multi-line messages, but it really was designed as a one-liner thing). Not, really. The "-m" option similar to "commit/tag" is deliberately omitted and use of editor is forced, to encourage better than one-liner information. cf. b7200e83 (branch: teach --edit-description option, 2011-09-20). The unholy mess is true if you are in the habit of editing .git/config in your editor, but that is to be expected if you are storing multi paragraph description as a value of a configuration variable. > (d) it doesn't work across repositories (ie multiple developers or > even just a single developer on multiple machines). This is the biggest issue. > IOW, the "branch description" is _kind_ of the right thing, but not really. Having said all that, quite honestly, as the inventor of the "--edit-description", I did it as sort of a joke, and not a serious "feature". > An empty commit would do it as well, but an empty commit very easily > gets lost (git rebase etc). The fake merge does have similar issues. These days, I think rebase distinguishes between "an empty commit that is deliberately empty from the beginning" and "a commit that was not empty, but because we are applying on a new base, it has become unnecessary and empty", and we can tell the command to drop the latter while keeping the former. So if I were to design a recommended workflow (and add any missing workflow elements), it would be: - You develop your N-patch series on a branch; - You conclude with an empty commit that records your cover letter material. - "git commit" may want to learn a new option that automatically prepares summary of the last N patches in the commit log editor, and the option should imply the "--allow-empty" option. That would help when editing such an empty commit that will become the cover letter. - You repeatedly "rebase -i", "cherry-pick", etc. to whip your branch into shape. - You can push and fetch such a branch among your machines and your group. - "git format-patch" may want to recognize that the topmost commit is an empty commit, and use that as the seed material for the cover letter. - If your project's pull request requires a signed tag with cover letter material, "git tag -s" may want to learn a new option to be fed such a branch with N-patch plus the topmost empty commit, and tag the last real commit in the topic (i.e. the parent of the topmost empty commit) with material taken from the topmost empty commit. > Both a fake merge, and an empty commit have the advantage that they > are easy to see and work with (ie "git log" and all the other git > workflows work very naturally). > > Comments from git people? > > Linus I can see how the above outline would work. I do not know if it would work well for your project, or there are other workflows for which the above outline would be insufficient.
