René Scharfe writes:
> Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>>> patch of mine and replace it with something René came up with (I have
>>> not yet read his 1-6 patches
René Scharfe writes:
> Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
>>
>> Straying sideways into a tangent, but do we know if any locale wants
>> to use something other than "<>" as an enclosing braket around a
>> placeholder?
>
> Bulgarian seems to use capitals instead; here are some
Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason writes:
>
>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>> patch of mine and replace it with something René came up with (I have
>> not yet read his 1-6 patches submitted on this topic, so
Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 02.08.2018 um 18:54 schrieb Jeff King:
>>> PS I actually would have made the rule simply "does it begin with a
>>> '<'", which seems simpler still. If people accidentally write ">> forgetting to close their
Ævar Arnfjörð Bjarmason writes:
> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
> patch of mine and replace it with something René came up with (I have
> not yet read his 1-6 patches submitted on this topic, so maybe they're
> not mutually exclusive).
I think the
On Thu, Aug 02 2018, Junio C Hamano wrote:
> René Scharfe writes:
>
>> Am 02.08.2018 um 17:44 schrieb Junio C Hamano:
>>> Subject: [PATCH] push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced
>>> brackets
>>> From: Ævar Arnfjörð Bjarmason
>>> Date: Thu, 02 Aug 2018 00:31:33 +0200
>>>
René Scharfe writes:
> Am 02.08.2018 um 18:54 schrieb Jeff King:
>> PS I actually would have made the rule simply "does it begin with a
>> '<'", which seems simpler still. If people accidentally write "> forgetting to close their brackets, that is a bug under both the
>> old and new
Am 02.08.2018 um 18:54 schrieb Jeff King:
> PS I actually would have made the rule simply "does it begin with a
> '<'", which seems simpler still. If people accidentally write " forgetting to close their brackets, that is a bug under both the
> old and new behavior (just with slightly
On Thu, Aug 02, 2018 at 08:31:57AM -0700, Junio C Hamano wrote:
> > diff --git a/parse-options.c b/parse-options.c
> > index 7db84227ab..fadfc6a833 100644
> > --- a/parse-options.c
> > +++ b/parse-options.c
> > @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const
> > char
Am 02.08.2018 um 17:31 schrieb Junio C Hamano:
> René Scharfe writes:
>> diff --git a/parse-options.c b/parse-options.c
>> index 7db84227ab..fadfc6a833 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const
>> char
René Scharfe writes:
> Am 02.08.2018 um 17:44 schrieb Junio C Hamano:
>> Subject: [PATCH] push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced
>> brackets
>> From: Ævar Arnfjörð Bjarmason
>> Date: Thu, 02 Aug 2018 00:31:33 +0200
>> ...
>> official escape hatch instead.
>>
>> Helped-by:
Am 02.08.2018 um 17:44 schrieb Junio C Hamano:
> Subject: [PATCH] push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced
> brackets
> From: Ævar Arnfjörð Bjarmason
> Date: Thu, 02 Aug 2018 00:31:33 +0200
>
> The option help text for the force-with-lease option to "git push"
> reads like
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>>> + /* N_() will get "<>" around, resulting in
>>> ":" */
>>
>> ...but this comment isn't accurate at all, N_() doesn't wrap the string
>> with <>'s, as can be seen by applying this patch:
>
> I know. It is a short-hand
René Scharfe writes:
> We could check if argh comes with its own angle brackets already and
> not add a second pair in that case, making PARSE_OPT_LITERAL_ARGHELP
> redundant in most cases, including the one above. Any downsides?
> Too magical?
Hmph.
> -- >8 --
> Subject: [PATCH]
Ævar Arnfjörð Bjarmason writes:
> On Thu, Aug 02 2018, René Scharfe wrote:
>
>> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
>>> But looking at this again it looks like this whole thing should just be
>>> replaced by:
>>>
>>> diff --git a/builtin/push.c b/builtin/push.c
>>>
Am 02.08.2018 um 17:06 schrieb René Scharfe:
> According to its manpage the option should rather be shown like this:
>
> --force-with-lease[=[:]]
>
> ... to indicate that all three forms are valid:
>
> --force-with-lease
> --force-with-lease=some_ref
>
Am 02.08.2018 um 16:21 schrieb Ævar Arnfjörð Bjarmason:
>
> On Thu, Aug 02 2018, René Scharfe wrote:
>
>> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
>>> But looking at this again it looks like this whole thing should just be
>>> replaced by:
>>>
>>> diff --git a/builtin/push.c
On Thu, Aug 02 2018, René Scharfe wrote:
> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
>> But looking at this again it looks like this whole thing should just be
>> replaced by:
>>
>> diff --git a/builtin/push.c b/builtin/push.c
>> index 9cd8e8cd56..b8fa15c101 100644
>>
Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
> But looking at this again it looks like this whole thing should just be
> replaced by:
>
> diff --git a/builtin/push.c b/builtin/push.c
> index 9cd8e8cd56..b8fa15c101 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
Hi,
Junio C Hamano wrote:
> Add a comment to save future readers from wasting time just like I
> did ;-)
Thanks. I think we should go further, and start the comment with
TRANSLATORS so it shows up for the audience most affected by this as
well. See the note on TRANSLATORS in po/README for
On Wed, Aug 01 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> + /* N_() will get "<>" around, resulting in
>>> ":" */
>>
>> ...but this comment isn't accurate at all, N_() doesn't wrap the string
>> with <>'s, as can be seen by applying this patch:
>
> I know.
Ævar Arnfjörð Bjarmason writes:
>> + /* N_() will get "<>" around, resulting in
>> ":" */
>
> ...but this comment isn't accurate at all, N_() doesn't wrap the string
> with <>'s, as can be seen by applying this patch:
I know. It is a short-hand for "what's inside N_() we see
On Wed, Aug 01 2018, Junio C Hamano wrote:
> The option help text for the force-with-lease option to "git push"
> reads like this:
>
> $ git push -h 2>&1 | grep -e force-with-lease
>--force-with-lease[=:]
>
> which come from this
>
> 0, CAS_OPT_NAME, , N_("refname>:
The option help text for the force-with-lease option to "git push"
reads like this:
$ git push -h 2>&1 | grep -e force-with-lease
--force-with-lease[=:]
which come from this
0, CAS_OPT_NAME, , N_("refname>:" at both
ends.
It turns out that parse-options machinery
24 matches
Mail list logo
