Christian Couder writes:
> From: Michael Haggerty
> ...
> An option like --input-separator might be enough to support this.
>
>> For me this means:
>>
>> * Enumerating a list of allowed separators (e.g., [:=#])
>
> Junio suggested in a message that users might use different separators
> like '%
On Tue, May 27, 2014 at 10:21 AM, Michael Haggerty wrote:
> tl;dr: This patch series wants to introduce a permanent new Git data
> format. The current version can write trailers in formats that it is
> incapable of reading, which I consider broken. I advocate a stricter
> specification of the fo
tl;dr: This patch series wants to introduce a permanent new Git data
format. The current version can write trailers in formats that it is
incapable of reading, which I consider broken. I advocate a stricter
specification of the format of trailers, at least until we get feedback
from users that th
From: Michael Haggerty
> On 04/25/2014 11:07 PM, Christian Couder wrote:
>>
>> I don't think there is a lot of complexity.
>> But maybe I need to explain how it works better.
>> Feel free to suggest me sentences I could add.
>
> I am really excited about having better support for trailers in Gi
From: Jeremy Morton
> On 29/04/2014 12:47, Christian Couder wrote:
>>> Also, if there were no current branch name because you're committing
>>> in a
>>> detached head state, it would be nice if you could have some logic to
>>> determine that, and instead write the trailer as:
>>> Made-on
On 29/04/2014 12:47, Christian Couder wrote:
Also, if there were no current branch name because you're committing in a
detached head state, it would be nice if you could have some logic to
determine that, and instead write the trailer as:
Made-on-branch: (detached HEAD: AB12CD34)
You m
On 29/04/2014 12:47, Christian Couder wrote:
Also, if there were no current branch name because you're committing in a
detached head state, it would be nice if you could have some logic to
determine that, and instead write the trailer as:
Made-on-branch: (detached HEAD: AB12CD34)
You m
On Tue, Apr 29, 2014 at 1:05 PM, Jeremy Morton wrote:
> On 28/04/2014 17:37, Junio C Hamano wrote:
>>
>> Christian Couder writes:
>>
>>> From: Junio C Hamano
Christian Couder writes:
...
>>>
>>>
> + trailer. After some alphanumeric characters, it can contain
> +
On 28/04/2014 17:37, Junio C Hamano wrote:
Christian Couder writes:
From: Junio C Hamano
Christian Couder writes:
...
+ trailer. After some alphanumeric characters, it can contain
+ some non alphanumeric characters like ':', '=' or '#' that will
+ be used instead of ':'
Christian Couder writes:
> From: Junio C Hamano
>>
>> Christian Couder writes:
>> ...
>
>>> + trailer. After some alphanumeric characters, it can contain
>>> + some non alphanumeric characters like ':', '=' or '#' that will
>>> + be used instead of ':' to separate the token from the value
On 04/25/2014 11:07 PM, Christian Couder wrote:
> From: Michael Haggerty
> +OPTIONS
> +---
> +--trim-empty::
> + If the 'value' part of any trailer contains only whitespace,
> + the whole trailer will be removed from the resulting message.
Does this apply
From: Michael Haggerty
>
> On 04/08/2014 01:35 PM, Christian Couder wrote:
>>
>> The trailers are recognized in the input commit message using the
>> following rules:
>> - only lines that contains a ':' are considered trailers,
>> - the trailer lines must all be next to each other,
>> - after
From: Junio C Hamano
>
> Christian Couder writes:
>
>> +Help add RFC 822-like headers, called 'trailers', at the end of the
>> +otherwise free-form part of a commit message.
>
> I think it is somewhat misleading to use the word "headers" like
> that. 'trailers' look similar to RFC-822-headers
Christian Couder writes:
> +Help add RFC 822-like headers, called 'trailers', at the end of the
> +otherwise free-form part of a commit message.
I think it is somewhat misleading to use the word "headers" like
that. 'trailers' look similar to RFC-822-headers but they come at
the end. The sente
Michael Haggerty writes:
> Sorry for reappearing in this thread after such a long absence. I
> wanted to see what is coming up (I think this interpret-trailers command
> will be handy!) so I read this documentation patch carefully, and added
> some questions and suggestions below.
Thanks for re
On 04/08/2014 01:35 PM, Christian Couder wrote:
> On Tue, Apr 8, 2014 at 9:30 AM, Michael Haggerty wrote:
>> How are existing trailers recognized in the input commit message? Do
>> trailers have to be configured to be recognized? Or are all lines
>> matching a specific pattern considered trailer
On Tue, Apr 8, 2014 at 9:30 AM, Michael Haggerty wrote:
>
>> +This command is a filter. It reads the standard input for a commit
>> +message and applies the `token` arguments, if any, to this
>> +message. The resulting message is emited on the standard output.
>
> s/emited/emitted/
Ok.
>> +Some
Sorry for reappearing in this thread after such a long absence. I
wanted to see what is coming up (I think this interpret-trailers command
will be handy!) so I read this documentation patch carefully, and added
some questions and suggestions below.
On 04/06/2014 07:02 PM, Christian Couder wrote:
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
Documentation/git-interpret-trailers.txt | 123 +++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/git-interpret-trailers.txt
diff --git a/Documentation/git-interpret-trailers.txt
19 matches
Mail list logo
