All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, Christian Couder <christian.couder@gmail.com>
Subject: Re: [RFC/PATCH 0/2] place cherry pick line below commit title
Date: Thu, 29 Sep 2016 14:56:34 -0700	[thread overview]
Message-ID: <xmqqtwcycqul.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <cover.1475176070.git.jonathantanmy@google.com> (Jonathan Tan's message of "Thu, 29 Sep 2016 12:21:36 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> This is somewhat of a follow-up to my previous e-mail with subject
> "[PATCH] sequencer: support folding in rfc2822 footer" [1], in which I
> proposed relaxing the definition of a commit message footer to allow
> multiple-line field bodies (as described in RFC2822), but its strictness
> was deemed deliberate.

It does not necessarily mean we can never change it when we did
something deliberately, though.  With a good enough justification,
and with a transitition plan if the backward incompatibility is
severe enough to warrant one, we can change things.

I vaguely recall that there were some discussion on the definition
of "what's a trailer line" with folks from the kernel land, perhaps
while discussing the interpret-trailers topic.  IIRC, when somebody
passes an improved version along, the resulting message's trailer
block may look like this:

    Signed-off-by: Original Author <original@author.xz>
    [fixed typo in the variable names]
    Signed-off-by: Somebhody Else <somebody@else.xz>

and an obvious "wish" of theirs was to treat not just RFC2822-like
"a line that begins with token followed by a colon" but also these
short comments as part of the trailer block.  Your original wish in
[*1*] is to also treat "a line that begin with a whitespace that
follows a line that begins with token followed by a colon" as part
of the trailer block and I personally think that is a reasonable
thing to wish for, too.

I recall that I was somewhat surprised and dissapointed to see no
change to interpret-trailers when you tried [*1*], which was really
about improving the definition of what the trailer block is, by the
way.

In any case, if we want to improve what the trailer block is, we
would certainly need to make sure what is inserted by "cherry-pick -x"
is also considered as part of the trailer block, so it may be necessary
to change it to "Cherry-picked-from: ..." while doing so.  I dunno.

> Below is a patch set that allows placing the "cherry picked from" line
> without taking into account the definition of a commit message footer.
> For example, "git cherry-pick -x" (with the appropriate configuration
> variable or argument) would, to this commit message:
>
>   commit title
>
>   This is an explanatory paragraph.
>
>   Footer: foo
>
> place the "(cherry picked from ...)" line below "commit title".
>
> Would this be better?

It is not immediately obvious what such a change buys us.  Wouldn't
the current code place that line below "Footer: foo"?  I cannot
think of any reason why anybody would want to place "cherry-picked
from" immediately below the title and before the first line of the
body.


[Footnotes]

*1* http://public-inbox.org/git/1472846322-5592-1-git-send-email-jonathantanmy@google.com/

  parent reply	other threads:[~2016-09-29 21:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29 19:21 [RFC/PATCH 0/2] place cherry pick line below commit title Jonathan Tan
2016-09-29 19:21 ` [RFC/PATCH 1/2] sequencer: refactor message and origin appending Jonathan Tan
2016-09-29 19:21 ` [RFC/PATCH 2/2] sequencer: allow origin line below commit title Jonathan Tan
2016-09-29 21:56 ` Junio C Hamano [this message]
2016-09-30 18:22   ` [RFC/PATCH 0/2] place cherry pick " Jonathan Tan
2016-09-30 19:34     ` Junio C Hamano
2016-09-30 20:23       ` Jonathan Tan
2016-10-03 15:23         ` Junio C Hamano
2016-09-30 20:49       ` Junio C Hamano
2016-10-03 17:44         ` Jonathan Tan
2016-10-03 19:17           ` Junio C Hamano
2016-10-03 21:28             ` Jonathan Tan
2016-10-03 22:13               ` Junio C Hamano
2016-10-04  0:08                 ` Jonathan Tan
2016-10-04 17:25                   ` Junio C Hamano
2016-10-04 18:28                     ` Junio C Hamano
2016-10-05 19:44                       ` Jonathan Tan
2016-10-06 19:24                         ` Junio C Hamano
2016-10-05 19:38                     ` Jonathan Tan
2016-10-05 20:33                       ` Junio C Hamano

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=xmqqtwcycqul.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.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.