Re: storing cover letter of a patch series?

On Sun, Aug 7, 2016 at 7:12 AM, Michael S. Tsirkin [off-list ref] wrote:

On Fri, Aug 05, 2016 at 08:39:58AM -0700, Junio C Hamano wrote:

quoted

"Michael S. Tsirkin" [off-list ref] writes:

quoted

On Thu, Sep 10, 2015 at 11:39:49AM -0700, Junio C Hamano wrote:

quoted

The problem with "empty commit trick" is that it is a commit whose
sole purpose is to describe the series, and its presence makes it
clear where the series ends, but the topology does not tell where
the series begins, so it is an unsatisifactory half-measure.

Actually, when using topic branches the series always ends at head, so
it's better to keep the empty commit where series begins.

But that would mean that you would need to destroy and recreate more
commits than you would need to.  If you have a five-commit series
(with the bottom "description" one, you would have six commits) and
you are already happy with the bottom two but want to update the
third one, you wuld have to "rebase -i" all six of them, reword the
bottom "description" to adjust it to describe the new version of the
third one _before_ you even do the actual update of the third one.

That somehow feels backwards, and that backward-ness comes from the
fact that you abused a single-parent commit for the purpose it is
not meant to be used (i.e. they are to describe individual changes),
because you did not find a better existing mechanism (and I suspect
there isn't any, in which case the solution is to invent one, not
abusing an existing mechanism that is not suited for it).

A flag that marks a commit "beginning of series" then?

git-notes was mentioned in this thread back in 2015, but I think it's
discarded because of the argument that's part of the cover letter was
not meant to be kept permanently. But I think we can still use it as a
local/temporary place for cover letter instead of the empty commit at
the topic's tip. It is a mark of the beginning of commit, it does not
require rewriting history when you update the cover letter, and
git-merge can be taught to pick it up when you're ready to set it in
stone.
-- 
Duy