git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Martin Fick <mfick@codeaurora.org>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Git List <git@vger.kernel.org>,
	repo-discuss@googlegroups.com
Subject: Re: storing cover letter of a patch series?
Date: Thu, 10 Sep 2015 11:39:49 -0700	[thread overview]
Message-ID: <xmqqzj0u2k5m.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <18979417.pyyHNUINeQ@mfick1-lnx> (Martin Fick's message of "Thu, 10 Sep 2015 12:02:02 -0600")

Martin Fick <mfick@codeaurora.org> writes:

> 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.

  parent reply	other threads:[~2015-09-10 18:40 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 16:28 storing cover letter of a patch series? Jacob Keller
2015-09-10 17:41 ` Junio C Hamano
2015-09-10 18:02   ` Martin Fick
2015-09-10 18:38     ` Jacob Keller
2015-09-10 18:39     ` Junio C Hamano [this message]
2015-09-11 22:24       ` Junio C Hamano
2016-08-04 23:49       ` Michael S. Tsirkin
2016-08-05 15:39         ` Junio C Hamano
2016-08-05 21:20           ` Martin Fick
2016-08-05 21:23             ` Junio C Hamano
2016-08-06 16:51               ` Junio C Hamano
2016-08-07  5:12           ` Michael S. Tsirkin
2016-08-07  9:52             ` John Keeping
2016-08-07 10:42             ` Duy Nguyen
2016-08-08 17:42               ` Junio C Hamano
2016-08-09  7:12                 ` Michael J Gruber
2015-09-10 18:32   ` Jacob Keller
2015-09-10 18:44     ` Junio C Hamano
2015-09-10 18:46       ` Jacob Keller
2015-09-10 20:09         ` Philip Oakley
2015-09-10 21:03           ` Jacob Keller
2016-08-04 23:43             ` Michael S. Tsirkin
2015-09-10 18:58 ` Johannes Schindelin
2015-09-10 21:00   ` Jacob Keller
2015-09-10 21:21     ` Johannes Schindelin
2015-09-10 22:20       ` Philip Oakley
2015-09-12 22:51   ` [PATCH] doc: show usage of branch description Philip Oakley
2015-09-12 23:44     ` Jacob Keller
2015-09-14 12:01       ` Philip Oakley
2015-09-14 13:24         ` Philip Oakley
2015-09-14 17:00         ` Junio C Hamano
2015-09-15 16:06           ` Philip Oakley
2015-09-15 19:10           ` Philip Oakley
2015-09-14 14:10     ` [PATCH v2] " Philip Oakley
2015-09-11  8:30 ` storing cover letter of a patch series? Chris Packham
2015-09-18  4:03   ` Simon Glass
2016-08-08 17:27 ` Stefan Beller
2016-08-08 20:09   ` Junio C Hamano
2016-08-13  8:49   ` Duy Nguyen
2016-08-14  7:15     ` Jacob Keller
2016-08-15  6:28       ` Stefan Beller
2016-08-15  6:38         ` Jacob Keller
2016-08-15  6:49           ` Stefan Beller
2016-08-15  6:52             ` Jacob Keller
2016-08-15  9:40         ` Duy Nguyen
2016-08-15 12:37           ` Philip Oakley
2016-08-15 13:30             ` Duy Nguyen
2016-08-15 13:47               ` John Keeping
2016-08-15 20:09             ` Jacob Keller
2016-08-15 20:38               ` Junio C Hamano
2016-08-15 23:01                 ` Jacob Keller
2016-08-15 20:46               ` Philip Oakley
2016-08-16  3:45                 ` Duy Nguyen
2016-08-16  5:26                   ` Jacob Keller
2016-08-16  6:45                     ` Duy Nguyen
2016-08-16 15:52                       ` Jacob Keller
2016-08-16 21:29                       ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqzj0u2k5m.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=mfick@codeaurora.org \
    --cc=repo-discuss@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).