Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > I'd like to be able to get format-patch to produce a [PATCH 0/N] message, > with a message that's actually in my repository, plus various goodies > generated either from diffing the ends of the series or by running through > the log an extra time to pick up summary information. So far, so good. > As far as implementing this... would it be sane to make struct > rev_info.commit_format a callback, so that the code to generate an email > message can be somewhere that's easy to use to generate an email that > isn't for a commit in the log? I don't *think* git's quite fast enough for > the indirect jump to a callback instead of an if tree for an enum will > actually hurt us. I suspect that temptation to touch rev_info.commit_format arises purely because you are thinking about making 0/N a (perhaps fake) commit. I do not see a point in that. What is the workflow? $ work work work, commit commit commit, reorder and perfect $ git tag end-of-series ... in $EDITOR, edit the [0/N] message $ git format-patch origin..end-of-series ... which notices end-of-series, and perhaps internally runs ... $ git-shortlog origin..end-of-series ... $ git diff --stat --summary origin..end-of-series ... $ git cat-file tag end-of-series ... to create 0/N which it did not do so far in ... 0000-cover-letter.txt $ git-send-email 0*.txt Would it be so much better than this workflow which would probably not need to touch much of the 'commit formatting" code that is used for [1/N]..[N/N] messages? $ work work work, commit commit commit, reorder and perfect $ git format-patch --with-cover origin..HEAD ... which notices --with-cover, and perhaps does ... $ git-shortlog origin..HEAD ... $ git diff --stat --summary origin..HEAD ... $ echo "*** BLURB HERE ***" ... to create 0/N which it did not do so far in ... 0000-cover-letter.txt $ $EDITOR 0000-cover-letter.txt $ git-send-email 0*.txt - 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
