Inspired by Peff's 'stress' script mentioned in:
https://public-inbox.org/git/20181122161722.gc28...@sigill.intra.peff.net/
the last patch in this series brings that functionality to our test
library to help to reproduce failures in flaky tests. So
./t1234-foo --stress
will run
On Sun, May 20 2018, Nguyễn Thái Ngọc Duy wrote:
> The help command currently hard codes the list of guides and their
> summary in C. Let's move this list to command-list.txt. This lets us
> extract summary lines from Documentation/git*.txt. This also
> potentially lets us
On Tue, Nov 6, 2018 at 4:41 AM Junio C Hamano wrote:
> > static int fsck_error_func(struct fsck_options *o,
> > struct object *obj, int type, const char *message)
> > {
> > - objreport(obj, (type == FSCK_WARN) ? "warning" : "error", message);
> > - return (type == FSCK_WARN) ? 0 :
These messages will be marked for translation later. Reduce word legos
and give translators almost full phrases. describe_object() is updated
so that it can be called from printf() twice.
While at there, remove \n from the strings to reduce a bit of work
from translators.
Signed-off-by: Nguyễn
Nguyễn Thái Ngọc Duy writes:
> static const char *describe_object(struct object *obj)
> {
> - static struct strbuf buf = STRBUF_INIT;
> - char *name = name_objects ?
> - lookup_decoration(fsck_walk_options.object_names, obj) : NULL;
> + static struct strbuf bufs[4] = {
These messages will be marked for translation later. Reduce word legos
and give translators almost full phrases. describe_object() is updated
so that it can be called from printf() twice.
While at there, remove \n from the strings to reduce a bit of work
from translators.
Signed-off-by: Nguyễn
/config.txt b/Documentation/config.txt
index dda5812a8a..ba3b775fb0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -347,29 +347,7 @@ include::config/gui.txt[]
include::config/guitool.txt[]
-help.browser::
- Specify the browser that will be used to display help
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 24 +---
Documentation/help-config.txt | 23 +++
2 files changed, 24 insertions(+), 23 deletions(-)
create mode 100644 Documentation/help-config.txt
diff --git a/Documentation
Rasmus Villemoes writes:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help cmd".
>
> v3: Add some addit
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4 +++
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(1) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(2) If foo is an alias f
v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
config option, no delay) redirect to the aliased command's help,
preserve pre-existing behaviour of the spelling "git help cmd".
v3: Add some additional comments in patch 1 and avoid triggering leak
checker
Rasmus Villemoes writes:
>> It also is strange to count from (0); if the patchset is rerolled
>> again, I'd prefer to see these start counting from (1), in which
>> case this item will become (3).
>
> If you prefer, I can send a v4.
Sure, if you prefer, you can send a v4 for me to look at and
resent immediately above the prompt when the user
>> quits the pager/returns to the terminal. That serves as an explanation
>> for why one was redirected to "man git-cherry-pick" from "git cp
>> --help", and if cp is actually 'cherry-pick -n', it reminds the user
>&
Rasmus Villemoes writes:
> As discussed in the thread for v1 of this patch [1] [2], this changes the
> rules for "git foo --help" when foo is an alias.
>
> (0) When invoked as "git help foo", we continue to print the "foo is
> aliased to bar" message
On Wed, Oct 03, 2018 at 01:42:39PM +0200, Rasmus Villemoes wrote:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help
v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
config option, no delay) redirect to the aliased command's help,
preserve pre-existing behaviour of the spelling "git help cmd".
v3: Add some additional comments in patch 1 and avoid triggering leak
checker
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(0) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(1) If foo is an alias f
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4 +++
On Wed, Oct 03, 2018 at 08:24:14AM +0200, Rasmus Villemoes wrote:
> > The comment probably needs to spell out that exclude_guides
> > is the same as your "we were invoked as...".
>
> Will do. That will also make the string --exclude-guides (i.e., with a
> dash) appear in the comment, making it
On 2018-10-03 04:18, Jeff King wrote:
> On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote:
>
>>
>> +If an alias is given, git prints a note explaining what it is an alias
>> +for on standard output. To get the manual page for the aliased
>> +co
On 2018-10-03 04:13, Jeff King wrote:
>> +/*
>> + * If we were invoked as "git help cmd", or cmd is an
>> + * alias for a shell command, we inform the user what
>> + * cmd i
On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote:
> This documents the existing behaviour of "git help cmd" when cmd is an
> alias, as well as providing a hint to use the "git cmd --help" form to
> be taken directly to the man page for the aliased
On Mon, Oct 01, 2018 at 01:21:05PM +0200, Rasmus Villemoes wrote:
> As discussed in the thread for v1 of this patch [1] [2], this changes the
> rules for "git foo --help" when foo is an alias.
>
> (0) When invoked as "git help foo", we continue to print the &
On Sat, Sep 29, 2018 at 08:08:14AM +0200, Nguyễn Thái Ngọc Duy wrote:
> When you type "git help" (or just "git") you are greeted with a list
> with commonly used commands and their short description and are
> suggested to use "git help -a" or "git
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(0) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(1) If foo is an alias f
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4 +++
a shell pipeline or
> > into a file).
> >
> > Choice (2) seems like a regression to me. Choice (1) is unfortunate in
> > some cases, but is no worse than today's behavior.
>
> I think the output of "git foo -h" changing (i.e. has "aliased
> to..
ate in
> some cases, but is no worse than today's behavior.
I think the output of "git foo -h" changing (i.e. has "aliased
to..." message in front) is about the same degree of regression as
"git foo --help" no longer giving "aliased to..." informatio
ing
> what "git foo" is in the first place), so perhaps I am worried too
> much. When the user does not know if the usage text comes to the
> standard output or to the standard error, and if the usage text is
> very long or not, they probably would learn quickly that th
to stderr, followed by who-knows-what. But as long as it's to
> stderr (and not stdout), I think it's not likely to _break_ anything.
>
>> > - "git cp --help" opens the manpage for cherry-pick. We don't bother
>> > with the alias definition, as it's available thro
seems to be the direction the
> discussion is taking). There are lots of commands that don't respond
> with a help message to -h, or that only recognize -h as the first word,
> or... There are really too many ways this could cause headaches.
>
> But, now that I test it, it seems that we already
When you type "git help" (or just "git") you are greeted with a list
with commonly used commands and their short description and are
suggested to use "git help -a" or "git help -g" for more details.
"git help -av" would be more friendly and inline
ases
> >> > sections. I feel that external commands section is definitely good to
> >> > have even if we don't replace "help -a". Aliases are more
> >> > subjective...
> >>
> >> I didn't apply this (so I didn't try running it), but a quick
Rasmus Villemoes writes:
>>> + if (follow_alias > 0) {
>>> + fprintf_ln(stderr,
>>> + _("Continuing to help for %s in %0.1f
>>> seconds."),
>>&g
Taylor Blau writes:
> On Wed, Sep 26, 2018 at 10:28:31AM -0700, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > Here's the patch that adds that external commands and aliases
>> > sections. I feel that external commands section is definitely good to
>>
On 2018-09-26 20:49, Jeff King wrote:
> On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
>
>>
>> If we expect users to use "git cp --help" a lot more often than "git
>> help cp" (or the other way around), one way to give a nicer experien
think is so bad for callers, given the tradeoff.
>
> Another way to go is 'git config alias.co', which should provide the
> same answer. I think that either would be fine.
The latter seems much more robust, since that will also tell you
precisely whether co is an alias at all, and you don't
On 2018-09-26 17:19, Duy Nguyen wrote:
> On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:
>>> +
>>> + /*
>>> + * We use split_cmdline() to get the first word of the
>>> + * alias, to ensure that we use the same rules as when
>>> + * the alias
split_cmdline_strerror(count));
>> +
>> +if (follow_alias > 0) {
>> +fprintf_ln(stderr,
>> + _("Continuing to help for %s in %0.1f
>> seconds."
On Wed, Sep 26, 2018 at 10:28:31AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Here's the patch that adds that external commands and aliases
> > sections. I feel that external commands section is definitely good to
> > have even if we don't replace &qu
Jeff King writes:
>> When you have "[alias] cp = cherry-pick -n", "git cp --help" should
>> not do "git help cherry-pick". Only a single word that exactly
>> matches a git command should get this treatment.
>
> I'm not sure I agree
of
> > misspelled commands.
>
> While I do agree with you that it would sometimes be very handy if
> "git cp --help" behaved identically to "git cherry-pick --help" just
> like "git cp -h" behaves identically to "git cherry-pick -h"
Taylor Blau writes:
> This pause (though I'm a little surprised by it when reviewing the
> code), I think strikes a good balance between the two, i.e., that you
> can get help for whatever it is aliased to, and see what that alias is.
And I need to react to it within subsecond with
On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
> Rasmus Villemoes writes:
>
> > I often use 'git --help' as a quick way to get the documentation
> > for a command. However, I've also trained my muscle memory to use my
> > aliases (cp=cherry-pick, co=che
On Wed, Sep 26, 2018 at 08:30:32AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> >> +help.followAlias::
> >> + When requesting help for an alias, git prints a line of the
> >> + form "'' is aliased to ''". If this option is
> >>
Duy Nguyen writes:
> Here's the patch that adds that external commands and aliases
> sections. I feel that external commands section is definitely good to
> have even if we don't replace "help -a". Aliases are more
> subjective...
I didn't apply this (so I didn't try ru
Duy Nguyen writes:
> -v was recently added just for the new "help -a" in May 2018. I think
> it's ok to get rid of it. Memory muscles probably take a couple more
> months to kick in.
If it is not hurting, keeping it lets people say "--no-verbose" to
get a less ver
print command description")),
> > OPT_END(),
> > };
>
> Would we want to continue respecting "-v" as a noop? I admit I did not
> even know it existed until this thread, but if people have trained
> themselves to run "git help -av", we should
Taylor Blau writes:
>> +help.followAlias::
>> +When requesting help for an alias, git prints a line of the
>> +form "'' is aliased to ''". If this option is
>> +set to a positive integer, git proceeds to show the help for
>
> With regard to &
On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:
> > +
> > + /*
> > + * We use split_cmdline() to get the first word of the
> > + * alias, to ensure that we use the same rules as when
> > + * the alias is actually used. split_cmdline()
> > +
On Wed, Sep 26, 2018 at 12:29 PM Rasmus Villemoes
wrote:
>
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doi
Rasmus Villemoes writes:
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doing
>
> git cp --help
>
>
On Wed, Sep 26, 2018 at 12:26:36PM +0200, Rasmus Villemoes wrote:
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
&
I often use 'git --help' as a quick way to get the documentation
for a command. However, I've also trained my muscle memory to use my
aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
up doing
git cp --help
to which git correctly informs me that cp is an alias
On Tue, Sep 25, 2018 at 07:44:51PM +0200, Duy Nguyen wrote:
> > I think adding another section about external commands in "help -av"
> > would address the "clang-format" stuff. With that, it's probably good
> > enough to completely replace "help -
On Tue, Sep 25, 2018 at 05:15:38PM +0200, Duy Nguyen wrote:
> On Mon, Sep 24, 2018 at 10:58 PM Junio C Hamano wrote:
> > I personally find "help -av" a bit too loud to my taste than plain
> > "-a", and more importantly, I look at "help -a" primarily
On Mon, Sep 24, 2018 at 10:58 PM Junio C Hamano wrote:
> I personally find "help -av" a bit too loud to my taste than plain
> "-a", and more importantly, I look at "help -a" primarily to check
> the last section "avaialble from elsewhere on your $PATH&
Jeff King writes:
> I agree that "help -av" is likely to be more friendly. I kind of wonder
> if it should just be the default for "-a". Do we have any obligation not
> to change the format of that output?
I know that at least older versions of git-completion.bash
On Mon, Sep 24, 2018 at 03:20:00PM -0500, Taylor Blau wrote:
> On Mon, Sep 24, 2018 at 02:19:28PM -0400, Jeff King wrote:
> > On Sat, Sep 22, 2018 at 07:47:07PM +0200, Nguyễn Thái Ngọc Duy wrote:
> >
> > > When you type "git help" (or just "git") you
On Mon, Sep 24, 2018 at 02:19:28PM -0400, Jeff King wrote:
> On Sat, Sep 22, 2018 at 07:47:07PM +0200, Nguyễn Thái Ngọc Duy wrote:
>
> > When you type "git help" (or just "git") you are greeted with a list
> > with commonly used commands and their short de
On Sat, Sep 22, 2018 at 07:47:07PM +0200, Nguyễn Thái Ngọc Duy wrote:
> When you type "git help" (or just "git") you are greeted with a list
> with commonly used commands and their short description and are
> suggested to use "git help -a" or "git h
On Sat, Sep 22, 2018 at 9:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sat, Sep 22 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When you type "git help" (or just "git") you are greeted with a list
> > with commonly used commands and their short descri
On Sat, Sep 22 2018, Nguyễn Thái Ngọc Duy wrote:
> When you type "git help" (or just "git") you are greeted with a list
> with commonly used commands and their short description and are
> suggested to use "git help -a" or "git help -g" for more d
When you type "git help" (or just "git") you are greeted with a list
with commonly used commands and their short description and are
suggested to use "git help -a" or "git help -g" for more details.
"git help -av" would be more friendly and inline
On Tue, Sep 11, 2018 at 2:55 PM Jean-Noël Avila wrote:
>
> Hi,
>
>
> When invoking the autocompletion help with after a double
> hyphen under zsh, the help list is not localized. I guess the help list
> comes from some usage output of the on-going git command, but I wasn't
Hi,
When invoking the autocompletion help with after a double
hyphen under zsh, the help list is not localized. I guess the help list
comes from some usage output of the on-going git command, but I wasn't
able to find where and how this happens (completion scripts are quite
hairy).
Thanks
Group the possible values using a pair of parentheses and don't mark
them for translation, as they are literal strings that have to be used
as-is in any locale.
Signed-off-by: Rene Scharfe
---
builtin/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c
This formally clarifies that the "--option=" part is the same for all
alternatives.
Signed-off-by: Rene Scharfe
---
builtin/pull.c | 2 +-
builtin/push.c | 4 ++--
builtin/send-pack.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/pull.c
Spell out all alternatives and avoid using a numerical range operator,
as it is not mentioned in CodingGuidelines and the resulting string is
still concise. Wrap them in parentheses to document clearly that the
"--stage=" part is common among them.
Signed-off-by: Rene Scharfe
---
On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote:
> > I do still have these warnings and no amount of git gc/git fsck/etc.
> > has reduced them in any way:
> >
> > $ git gc
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning:
On Sat, Aug 11, 2018 at 04:38:00PM +0200, Duy Nguyen wrote:
> On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote:
> > Responding myself and adding Duy to the cc to increase visibility among
> > worktree experts. :)
>
> I do silently watch this thread (and yes I still have to fix that fsck
> thing,
On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote:
> Responding myself and adding Duy to the cc to increase visibility among
> worktree experts. :)
I do silently watch this thread (and yes I still have to fix that fsck
thing, hit a roadblock with ref names but I should really restart it
soon). Now
On Sat, Aug 11, 2018 at 10:23:41AM -0400, Jeff King wrote:
> > I do still have these warnings and no amount of git gc/git fsck/etc.
> > has reduced them in any way:
> >
> > $ git gc
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
>
On Sat, Aug 11, 2018 at 08:13:17AM -0400, Paul Smith wrote:
> I rebuilt Git 2.18.0 without optimization to try to get more debug
> information. Unfortunately I didn't think to create a backup of my
> problematic .git directory.
>
> When I ran the above command under the debugger using the
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> If so, can you try running it under gdb and getting a stack trace?
> Something like:
>
> gdb git
> [and then inside gdb...]
> set args pack-objects --all --reflog --indexed-objects foobreak die
> run
> bt
>
> That might give us
On Wed, Aug 08, 2018 at 10:45:49PM -0400, Paul Smith wrote:
> On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> > If so, can you try running it under gdb and getting a stack trace?
> > Something like:
> >
> > gdb git
> > [and then inside gdb...]
> > set args pack-objects --all --reflog
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> If so, can you try running it under gdb and getting a stack trace?
> Something like:
>
> gdb git
> [and then inside gdb...]
> set args pack-objects --all --reflog --indexed-objects foobreak die
> run
> bt
>
> That might give us
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> Let's narrow it down first and make sure we're dying where I expect.
> Can
> you try:
>
> GIT_TRACE=1 git gc
>
> and confirm the program running when the fatal error is produced?
>
> From what you've shown it's going to be git-repack, but
On Wed, Aug 08, 2018 at 01:35:30PM -0400, Paul Smith wrote:
> Thanks for the note! Unhappily for me none of these operations seem to
> find any actionable problems...
> [...]
Drat.
One other option is that it _could_ be related to the "old unreachable
objects that are reachable from recent
On Wed, 2018-08-08 at 12:06 -0400, Jeff King wrote:
> I'd have expected fsck to find it, too. However, looking at the code,
> I'm not convinced that fsck is actually considering detached worktree
> heads properly, either. Try:
>
> git rev-list --all --reflog --objects >/dev/null
>
> which I
On Wed, Aug 08, 2018 at 10:30:11AM -0400, Paul Smith wrote:
> I recently upgraded from Git 2.9.2 to 2.18.0 (note, I have no
> particular reason to believe this is related just passing info). I'm
> running on Linux (64bit Ubuntu 18.04.1 but I've compiled Git myself
> from source, I'm not using
I recently upgraded from Git 2.9.2 to 2.18.0 (note, I have no
particular reason to believe this is related just passing info). I'm
running on Linux (64bit Ubuntu 18.04.1 but I've compiled Git myself
from source, I'm not using the distro version).
I have a local repository I've been using for
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
rian seems to use capitals instead; here are some examples found
> with git grep -A1 'msgid "<' po/:
>
> po/bg.po:msgid ""
> po/bg.po-msgstr "ОТДАЛЕЧЕНО_ХРАНИЛИЩЕ"
> ...
>>
>> Perhaps we should do _("<%s>") here? That way, the resul
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
quot;"
po/bg.po-msgstr "КЛОН"
--
po/bg.po:msgid "/"
po/bg.po-msgstr "ПОДДИРЕКТОРИЯ/"
--
po/bg.po:msgid "[,]"
po/bg.po-msgstr "БРОЙ[,БАЗА]"
> This arg-help text, for example,
>
> N_("ref
Ramsay Jones writes:
>> OPT_BOOL( 0 , "ignore-missing", _missing, N_("check if - even
>> missing - files are ignored in dry run")),
>> -OPT_STRING( 0 , "chmod", _arg, N_("(+/-)x"), N_("override the
>> executable bit of the listed files")),
>> +{ OPTION_STRING, 0, "chmod", _arg,
Andrei Rybak writes:
> On 2018-08-02 21:17, René Scharfe wrote:
>> Don't translate the argument specification for --chmod; "+x" and "-x"
>> are the literal strings that the commands accept.
>> > [...]
>>
>> -OPT_STRING( 0 , "chmod", _arg, N_("(+/-)x"), N_("override the
>> executable bit of
On 2018-08-02 21:17, René Scharfe wrote:
> Don't translate the argument specification for --chmod; "+x" and "-x"
> are the literal strings that the commands accept.
> > [...]
>
> - OPT_STRING( 0 , "chmod", _arg, N_("(+/-)x"), N_("override the
> executable bit of the listed files")),
> +
t; Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding a
> pair of angular brackets around the argument help string, as that would
> wrongly indicate that users need to replace the literal strings with
> some kind of value.
>
> Signed-off-by: Rene Scharfe
&g
t; Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding a
> pair of angular brackets around the argument help string, as that would
> wrongly indicate that users need to replace the literal strings with
> some kind of value.
Good change.
Let's mention in the
Æ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
>>>
ug under both the
>> old and new behavior (just with slightly different outcomes).
>
> Good point.
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? This arg-help text, f
Wrap the placeholders in the option help string for -w in pairs of
angular brackets to document that users need to replace them with actual
numbers. Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt
from adding another pair.
Signed-off-by: Rene Scharfe
---
builtin/shortlog.c | 6
Wrap each part of the argument help string in angular brackets to show
that users need to replace them with actual values. Do that explicitly
to balance the pairs nicely in the code and avoid confusing casual
readers. Add the flag PARSE_OPT_LITERAL_ARGHELP to keep parseopt from
adding another
Wrap both placeholders in the argument help string in angular brackets
to signal that users needs replace them with some actual value. Use the
flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding another
pair.
Signed-off-by: Rene Scharfe
---
builtin/pack-objects.c | 4 ++--
1 file
uot;),
N_("use the specified diff tool")),
OPT_BOOL(0, "tool-help", _help,
N_("print a list of diff tools that may be used with "
@@ -711,7 +711,7 @@ int cmd_difftool(int argc, const c
ng a
pair of angular brackets around the argument help string, as that would
wrongly indicate that users need to replace the literal strings with
some kind of value.
Signed-off-by: Rene Scharfe
---
builtin/add.c | 4 +++-
builtin/update-index.c | 2 +-
2 files changed, 4 insertions(+), 2 dele
1 - 100 of 959 matches
Mail list logo
