Re: storing cover letter of a patch series?

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Ideally, I would think that you want that information when the
> series is fully cooked and gets merged to a more permanent place in
> the log message of the merge commit.  At that point, where the
> series started may become more clear from the topology (i.e. the set
> difference X^..X for the resulting merge is what got merged).  One
> possible "hacky" convention could be
>
>  - Developers keep rerolling with the "empty commit with cover
>    letter material at the tip".  topic@{upstream}..topic~1 are the
>    real changes, topic~0 is an empty "cover letter material".
>
>  - When the series is fully cooked, a new "git merge" option notices
>    that the topic is structured in a "strange" way, uncaps its tip
>    commit and merges the remainder of the series and adds the cover
>    letter material when presenting the editor to record the merge
>    commit.  That is
>
> 	$ git merge --cover-at-tip topic
>
>    would work roughly by doing the following:
>
>     - verify that "git rev-parse topic^^{tree} topic^{tree}" shows that
>       they record the same tree; otherwise it will error out, saying
>       the tip is not a pure cover.
>
>     - verify that "git rev-list ..topic^" shows that there is
>       something to merge after the tip is removed; otherwise it will
>       error out, saying that there is nothing to merge.
>
>     - run "git merge --no-ff --edit topic^1" but with the log
>       message of topic^{commit} in the editor's template.

To complement the above, if we want to pursue this approach, the
following would also help.

 - (obvious) "git pull" would learn the same "--cover-at-tip" option
   and would pass it to "git merge".

 - "git am --cover-at-tip" would make the incoming cover-letter
   material into a non-tree-changing commit at the tip of the
   resulting topic.

 - "git format-patch" would notice a topic branch in such a shape
   and would use the log message of the non-tree-changing commit at
   the tip as part of the cover letter.

Then the overall workflow would become:

 * A developer works on a topic and concludes it by writing a
   summary that should appear in the final merge to the trunk as a
   log message of a non-tree-changing commit at the tip.

 * In "request-to-pull" workflow, the developer requests the topic
   to be pulled.  The integrator uses "git pull --cover-at-tip" and
   the resulting merge commit will carry the summary written by the
   original developer.

 * In e-mail workflow, the developer runs "git format-patch"; the
   cover-letter is populated with the summary the developer wrote.

 * The integrator uses "git am --cover-at-tip" on a new branch,
   which recreates the topic branch the developer created at the
   first step above.

 * The integrator merges the topic with "git merge --cover-at-tip"
   to the trunk, and the resulting merge commit will carry the
   summary written by the original developer.