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: Wed, 05 Oct 2016 13:33:14 -0700	[thread overview]
Message-ID: <xmqqint6o7sl.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <a7304731-fa05-92c2-6139-ecd1e6adcefd@google.com> (Jonathan Tan's message of "Wed, 5 Oct 2016 12:38:46 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> Sounds reasonable to me. Would the "[" be a bit of overspecification,
> though, since Git doesn't produce it? Also, identifying it as a
> garbage line probably wouldn't change any behavior - in the Linux
> kernel examples, it is used to show what happened in between
> sign-offs, so there will always be one "Signed-off-by:" at the top.

Good thinking.  As "interpret trailers" cannot locate such a line to
manipulate (as it lacks <token>), we can simply treat it as a
garbage line.

>>     struct {
>> 	const char *whole;
>> 	const char *end_of_message_proper;
>> 	struct {
>> 		const char *token;
>> 		const char *contents;
>> 	} *trailer;
>> 	int alloc_trailers, nr_trailers;
>>     };
>>
>> where
>>
>>  - whole points at the first byte of the input, i.e. the beginning
>>    of the commit message buffer.
>>
>>  - end-of-message-proper points at the first byte of the trailer
>>    block into the buffer at "whole".
>>
>>  - token is a canonical header name for easy comparison for
>>    interpret-trailers (you can use NULL for garbage lines, and made
>>    up token like "[bracket]" and "(cherrypick)" that would not clash
>>    with real tokens like "Signed-off-by").
>>
>>  - contents is the bytes on the logical line, including the header
>>    part
>>
>> E.g. an element in trailer[] array may say
>>
>>     {
>> 	.token = "Signed-off-by",
>>         .contents = "Signed-Off-By: Some Body <some@body.xz>\n",
>>     }
>
> I get the impression from the rest of your e-mail that no strings are
> meant to be copied - is that true? (That sounds like a good idea to
> me.)

I was envisioning that "whole", "end-of-message" can point into the
input buffer, while trailer[].contents may have to be copied, if
only to make it to a NUL-terminated string.  But I am fine with
<ptr,len> or <begin,end> pair to avoid copying .contents if that is
desired.  You'd need to worry about differentiating .contents that
need to be freed after "interpret trailers" inserted a new entry or
replaced the contents, though.

      reply	other threads:[~2016-10-05 20:33 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 ` [RFC/PATCH 0/2] place cherry pick " Junio C Hamano
2016-09-30 18:22   ` 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 [this message]

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