On Wed, Jan 02, 2019 at 11:43:55PM -0800, William Chargin wrote:
> > IMHO this is a bug in --parse. It was always meant to give sane,
> > normalized output
>
> Okay; this is good to hear. In that case, what would you think about
> changing `interpret-trailers` as a whole to always emit colons? (N
> That's what "%(trailers:only)" does (even if the original separator was
> something else). It also trims any extra whitespace.
Ooh, this is good to know: thanks. (I had found `print_tok_val` in
`trailer.c` and assumed that this was the only place with the output
logic, but I now see that `format
On Sun, Dec 23, 2018 at 02:41:20PM -0800, William Chargin wrote:
> I'm interested in parsing the output of `git-interpret-trailers` in a
> script. I had hoped that the `--parse` option would make this easy, but
> it seems that the `trailer.separators` configuration option is used to
> specify both
> Yeah, but you can perhaps check that the input doesn't contain '|'
> before doing the above. If it does contain '|' then you can probably
> find another char that it doesn't contain and use that char instead of
> '|'.
This sounds true in the usual case, though of course there are
pathological ca
Hi William,
On Mon, Dec 24, 2018 at 7:52 PM William Chargin wrote:
>
> Hi Christian: thanks for your reply.
>
> > Changing the default separator as shown above, should make it easier
> > to parse the result.
>
> But this actually also changes which lines are considered trailers,
> right?
Yes.
>
Hi Christian: thanks for your reply.
> Changing the default separator as shown above, should make it easier
> to parse the result.
But this actually also changes which lines are considered trailers,
right? If the commit message ends with
Signed-off-by: one
Signed-off-by| two
and the use
On Sun, Dec 23, 2018 at 11:44 PM William Chargin wrote:
>
> I'm interested in parsing the output of `git-interpret-trailers` in a
> script. I had hoped that the `--parse` option would make this easy, but
> it seems that the `trailer.separators` configuration option is used to
> specify both the in
I'm interested in parsing the output of `git-interpret-trailers` in a
script. I had hoped that the `--parse` option would make this easy, but
it seems that the `trailer.separators` configuration option is used to
specify both the input format (which separators may indicate a trailer)
and the output
The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).
But to find the existing trailers, it calls into
has_conform
When the sequencer code appends a signoff or cherry-pick
origin, it uses the default trailer-parsing options, which
treat "---" as the end of the commit message. As a result,
it may be fooled by a commit message that contains that
string and fail to find the existing trailer block. Even
more confus
10 matches
Mail list logo
