All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	git <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2 2/2] trailer: support multiline title
Date: Wed, 26 Aug 2015 09:05:39 -0700	[thread overview]
Message-ID: <xmqqk2siujak.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAP8UFD2x8i5wC9JP8d1zAH=d-2BMYWAvpaFmWnu09N5QSG==TA@mail.gmail.com> (Christian Couder's message of "Wed, 26 Aug 2015 16:53:55 +0200")

Christian Couder <christian.couder@gmail.com> writes:

> There is already code to detect a patch in interpret-trailers, but it
> relies on the patch starting with a line with only three dashes.

Hmm, then it can be taught to notice "everything below..." as
another marker, right?

> Maybe. I don't know if there is a reason why the commit-msg is called
> before removing the patch.

Is that "removing", or are you talking about changing the order from

 - prepare log template in-core
 - add comments and patch to that in-core copy
 - write in-core copy out
 - run hook
 - read the hook's result in-core
 - use the message

to

 - prepare log template in-core
 - write in-core copy out
 - run hook
 - read the hook's result in-core
 - add comments and patch to that in-core copy
 - use the message

While the reordering would certainly stop showing the comments and
patch, I am not sure if that is a move in the right direction.  It
will rob from the hooks information that they have traditionally
been given---it will break some hooks.

But if interpret-trailers is almost there to reliably know where the
log message ends, teaching it the one last step would be the right
thing to do anyway.  After all, interpret-trailers was invented
exactly because we did not want individual hooks to roll their own
ways to detect the end of the message proper, so the command should
know where the message ends.

  reply	other threads:[~2015-08-26 16:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-26  2:51 [PATCH v2 1/2] trailer: ignore first line of message Christian Couder
2015-08-26  2:51 ` [PATCH v2 2/2] trailer: support multiline title Christian Couder
2015-08-26  6:07   ` Matthieu Moy
2015-08-26  6:28     ` Jacob Keller
2015-08-26 14:53       ` Christian Couder
2015-08-26 16:05         ` Junio C Hamano [this message]
2015-08-26 16:15           ` Matthieu Moy
2015-08-26 19:48   ` Junio C Hamano
2015-08-29  4:00     ` Christian Couder

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=xmqqk2siujak.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.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.