Re: storing cover letter of a patch series?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 10, 2015, 18:39 UTC
Message-ID: <xmqqzj0u2k5m.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <18979417.pyyHNUINeQ@mfick1-lnx>

Martin Fick <mfick@codeaurora.org> writes:

Show 8 quoted lines

> As a Gerrit developer and user, I would like a way to 
> see/review cover letters in Gerrit.  We have had many 
> internal proposals, most based on git notes, but we have 
> also used the empty commit trick.  It would be nice if there 
> were some standard git way to do this so that Gerrit and 
> other tools could benefit from this standard.  I am not 
> suggesting that git need to be modified to do this, but 
> rather that at least some convention be established.

Some of what you would write in the cover letter is not meant for anywhere in the permanent history (e.g. description of what changed since the previous reroll), but some other would be a concise summary of what the entire series is about, and it would be nice if it can be made part of the permanent record.

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.

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.