Junio C Hamano <gitster@xxxxxxxxx> 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.
--
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