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: Fri, 11 Sep 2015 15:24:20 -0700 [thread overview]
Message-ID: <xmqq37ykzjaj.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqzj0u2k5m.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Thu, 10 Sep 2015 11:39:49 -0700")
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.
next prev parent reply other threads:[~2015-09-11 22:24 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
2015-09-11 22:24 ` Junio C Hamano [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq37ykzjaj.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.