Hello,
I've attached a screenshot for running `git help -a' that ends in a
hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
attached):
https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.gitconfig
So it's hangs on the alias `remote-origi
longest - strlen(cmds[i].name));
+ mput_char(' ', longest > len ? longest - len : 1);
puts(_(cmds[i].help));
}
}
@@ -526,6 +527,13 @@ void list_all_cmds_help(void)
git_config(get_alias, &alias_list);
s
The code added in 26c7d0678324 (help -a: improve and make --verbose default,
2018-09-29) that intends to print out aliases in addition to commands failed
to adjust for the length of the aliases. As a consequence, if there was any
alias whose name is longer than 18 characters, git help -a tried to
On Sun, Dec 09, 2018 at 11:56:21PM +0100, SZEDER Gábor wrote:
> This patch series tries to make reproducing rare failures in flaky
> tests easier: it adds the '--stress' option to our test library to run
> the test script repeatedly in multiple parallel jobs, in the hope that
> the increased load
许铖 writes:
> Since git 2.20.0, invoking `git help -a` will cause git using page (e.g. less)
> to display help message.
> ...
> I would suggest `git help -a` only invokes page when stdout is a tty.
It already does so for me. "GIT_PAGER=uc git help -a | cat" where
"u
To whom may concern,
Since git 2.20.0, invoking `git help -a` will cause git using page (e.g. less)
to display help message. However, such behaviour is not desirable when
`git help -a` is run inside a pipe or invoked by another program.
Step to reproduce the bug:
git help -a | cat # this
This patch series tries to make reproducing rare failures in flaky
tests easier: it adds the '--stress' option to our test library to run
the test script repeatedly in multiple parallel jobs, in the hope that
the increased load creates enough variance in the timing of the test's
commands that suc
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
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
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 Th
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 Th
/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 in the
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
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 for
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
ch
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 qu
nt 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
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
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
ch
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 for
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 mo
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 is an alias for and do nothing else.
>
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 for
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 +++
ough 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
ortunate 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..." informa
robably unknown (because the user is asking
> 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 pro
message 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 defi
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 w
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
d 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 runni
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
&g
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
oach, which I don't 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 c
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 is
t; +split_cmdline_strerror(count));
>> +
>> +if (follow_alias > 0) {
>> +fprintf_ln(stderr,
>> + _("Continuing to help for %s in %0.1f
>> seconds.&q
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 r
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 agre
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
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=cher
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
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
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 les
AT_INFO),
> > - OPT__VERBOSE(&verbose, N_("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
> themse
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
>
&
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
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
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 tha
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
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 -a
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 descripti
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&#
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 b
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 b/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
---
builtin/checko
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: r
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 non-op
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 a
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 a
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 w
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 unre
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 kno
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 the
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 abou
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 sub
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, th
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 maybe
--
po/bg.po:msgid ""
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_("refspec")
Ramsay Jones writes:
>> OPT_BOOL( 0 , "ignore-missing", &ignore_missing, N_("check if - even
>> missing - files are ignored in dry run")),
>> -OPT_STRING( 0 , "chmod", &chmod_arg, N_("(+/-)x"), N_("override the
>> executable bit of the listed files")),
>> +{ OPTION_STRING, 0, "chmo
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", &chmod_arg, N_("(+/-)x"), N_("override the
>> executable b
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", &chmod_arg, N_("(+/-)x"), N_("override the
> executable bit of the listed files")),
> +
;
> 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 Scharf
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
Æ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 6-pat
101 - 200 of 1049 matches
Mail list logo
