Sorry if this is not the place for this.
I'm looking for any reference to potential problems when updating a git client
(say from 1.7.N to 1.8.N) with old workspaces.
The scenario is this:
Lots of developers use a single machine for work
They have lots of workspaces created using
Coverity reported a memory leak in this function. However, it can only
be called once, as setup_git_directory() changes global state and hence
is not reentrant.
Mark the variable as static to indicate that this is a singleton.
Signed-off-by: Johannes Schindelin
---
setup.c | 2 +-
1 file change
Hi Junio,
On Mon, 1 May 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Coverity reported a memory leak in this function. However, it can only
> > be called once, as setup_git_directory() changes global state and hence
> > is not reentrant.
> >
> > Mark the variable as static to
Johannes Schindelin writes:
> Coverity reported a memory leak in this function. However, it can only
> be called once, as setup_git_directory() changes global state and hence
> is not reentrant.
>
> Mark the variable as static to indicate that this is a singleton.
>
> Signed-off-by: Johannes Schi
Coverity reported a memory leak in this function. However, it can only
be called once, as setup_git_directory() changes global state and hence
is not reentrant.
Mark the variable as static to indicate that this is a singleton.
Signed-off-by: Johannes Schindelin
---
setup.c | 9 +++--
1 file
Coverity reported a memory leak in this function. However, it can only
be called once, as setup_git_directory() changes global state and hence
is not reentrant.
Mark the variable as static to indicate that this is a singleton.
Signed-off-by: Johannes Schindelin
---
setup.c | 2 +-
1 file change
patch does
for help), and you'd get:
@@ -1 +1 @@
-old
+new
Stage this hunk [y,n,q,a,d,/,e,?]? j
No next hunk
Stage this hunk [y,n,q,a,d,/,e,?]?
at which point you could "r" to redisplay it if you wanted to.
This seems good too. But, I guess, the help menu would pr
On Fri, Apr 28, 2017 at 10:44:22AM +0530, Kaartic Sivaraam wrote:
> I guess it would be better to display the help menu in a separate flow, like
> when the user click the `?` option in the `patch` flow then the whole screen
> is cleared and the help menu is displayed in some appropriate
arate commits. So, you would
like to split the hunk into smaller parts but you forgot the correct
option for it and you use `?` option. In most cases you wouldn't see the
help menu completely. Moreover, if the hunk's size is reasonable enough
to take up the whole screen of the termin
We have been trying to keep the terminology consistent on the
user-facing front. Let's keep sticking to "working tree".
While at there, change 'other' to 'another'. The latter is probably more
correct.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertio
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the
Hello,
I have a personal Project in which i need your assistance I would like to
be sure of your willingness and commitment to execute this
transaction with me. I seek your partnership in receiving this fund
worth (Twenty five million United States Dollars). If interested, reply
immediately for det
Change mentions of to in the help output of
for-each-ref as appropriate.
Both --[no-]merged and --contains only take commits, but --points-at
can take any object, such as a tag pointing to a tree or blob.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/for-each-ref.c | 4 ++--
1 file
Change mentions of to in the help output of
for-each-ref as appropriate.
Both --[no-]merged and --contains only take commits, but --points-at
can take any object, such as a tag pointing to a tree or blob.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/for-each-ref.c | 4 ++--
1 file
Ævar Arnfjörð Bjarmason writes:
> On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano wrote:
>
>> Do these strictly require commit, or does any commit-ish also do?
>
> commit-ish, but that's a good point, and could be the subject of a
> future follow-up patch. Right now most of the things that say
On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change mentions of to in the help output of
>> for-each-ref as appropriate.
>>
>> Both --[no-]merged and --contains only take commits, but --points-at
>> can tak
Ævar Arnfjörð Bjarmason writes:
> Change mentions of to in the help output of
> for-each-ref as appropriate.
>
> Both --[no-]merged and --contains only take commits, but --points-at
> can take any object, such as a tag pointing to a tree or blob.
>
> Signed-off-by: Æv
Change mentions of to in the help output of
for-each-ref as appropriate.
Both --[no-]merged and --contains only take commits, but --points-at
can take any object, such as a tag pointing to a tree or blob.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/for-each-ref.c | 4 ++--
1 file
Signed-off-by: Brandon Williams
---
builtin/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 9304c33e7..4694e68f3 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -979,7 +979,7 @@ int cmd_grep(int argc, const char **argv, const ch
Hello Dear,
My names are Aisha Gaddafi, 39, I need a very honest and reliable
person that can assist me for investment project for a profitable
business/ company to invest into in your country than if you are
interested let me know. I will details you more when I hear from you.
Aisha
On 03/14, Stefan Beller wrote:
> On Tue, Mar 14, 2017 at 3:10 PM, Brandon Williams wrote:
>
> Missing SoB here, too.
I guess I'm having an off day...Will fix.
>
> > ---
> > builtin/grep.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/builtin/grep.c b/builtin/g
On Tue, Mar 14, 2017 at 3:10 PM, Brandon Williams wrote:
Missing SoB here, too.
> ---
> builtin/grep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 9304c33e7..4694e68f3 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@
---
builtin/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 9304c33e7..4694e68f3 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -979,7 +979,7 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
OPT_
t's better to do things like the following:
>>
>> - add `git version -h`
>> - add proper documentation for `git version` so that `git help version` works
>> - in `git help version` talk about the REPORTING BUGS section in `git help
>> git`
>> - add `git version -
-h`
> - add proper documentation for `git version` so that `git help version` works
> - in `git help version` talk about the REPORTING BUGS section in `git help
> git`
> - add `git version --full` or other such options to also print other
> stuff like the current OS, processor arc
>
> It's tempting to put the custom information in --build-options --- e.g.
>
> $ git version
> git version 2.12.0.190.g6e60aba09d.dirty
> hint: use "git version --build-options" for more detail
> hint: and bug reporting instructions
> $
> $ git versio
version 2.12.0.190.g6e60aba09d.dirty
hint: use "git version --build-options" for more detail
hint: and bug reporting instructions
$
$ git version --build-options
git version 2.12.0.190.g6e60aba09d.dirty
sizeof-long: 8
reporting-bugs: see REPORTING BUGS section in "git help git"
Git is distributed in various ways by various organizations. The Git
community prefers to have bugs reported on the mailing list, whereas
other organizations may rather want to have filed a bug in a bug tracker
or such. The point of contact is different by organization as well.
When reporting bug
Ralf Thielow writes:
> Within the help message of 'git add -i', the 'diff' command uses one
> tab character and blanks to create the space between the name and the
> description while the others use blanks only. So if the tab size is
> not at 4 characters, this
Within the help message of 'git add -i', the 'diff' command uses one
tab character and blanks to create the space between the name and the
description while the others use blanks only. So if the tab size is
not at 4 characters, this description will not be in range.
Replace th
Tom Kunze writes:
> If an alias is a single git command show the man page of the
> aliased git command with --help.
>
> Signed-off-by: Tom Kunze
> ...
> diff --git a/builtin/help.c b/builtin/help.c
> index 49f7a07..655ed49 100644
> --- a/builtin/help.c
> +++ b/builtin
If an alias is a single git command show the man page of the
aliased git command with --help.
Signed-off-by: Tom Kunze
---
Hi,
I noticed that when I pass --help to an alias which is only a git
command it tells me a information about the alias. But it would be
nice if it instead opens the
On Mon, Feb 6, 2017 at 6:38 AM, Edmundo Carmona Antoranz
wrote:
> I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
> (066fb0494e6398eb). Specifically file abspath.c.
I just noticed that I'm standing on a private branch. Replace HEAD for
"4e59582ff" when doing your analysis. You should ge
Hi!
While doing some research developing difflame I found some output from
git blame --reverse that I can't quite understand. Perhaps another set
of eyeballs could help me.
I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
(066fb0494e6398eb). Specifically file abspat
via the specified script interpreter.
>
> To figure out whether files in the `PATH` are executable, `git help` has
> code that imitates this behavior. With one exception: it *always* opens
> the files and looks for a she-bang line *or* an `MZ` tell-tale
> (nevermind that files wit
Hi Junio,
On Fri, 27 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > From: Heiko Voigt
> >
> > The previous implementation said that the filesystem information on
> > Windows is not reliable to determine whether a file is executable. To
> > gather this information it was pe
files in the `PATH` are executable, `git help` has
code that imitates this behavior. With one exception: it *always* opens
the files and looks for a she-bang line *or* an `MZ` tell-tale
(nevermind that files with the magic `MZ` but without file extension
`.exe` would still not be executable
Johannes Schindelin writes:
> From: Heiko Voigt
>
> The previous implementation said that the filesystem information on
> Windows is not reliable to determine whether a file is executable. To
> gather this information it was peeking into the first two bytes of a
> file to see whether it looks ex
open (git-blame.exe): 0.000718
after open (git-blame.exe): 0.000724
...
With this patch I get:
$ time git help git
Launching default browser to display HTML ...
real0m8.723s
user0m0.000s
sys 0m0.000s
and without
$ time git help git
Launching default browser to display HTML ...
real
HELP ME PLEASE
Dear Friend
I am Mr. Abdoul Issouf ,I work for BOA bank Ouagadougou Burkina Faso.
I have a business proposal which concerns the transfer of $13.5
Million USD, into a foreign account. Everything about this
transaction shall be legally done without any problem. If you are
This part was missing in f6f85861 (submodule: add absorb-git-dir function,
2016-12-12).
Noticed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
git-submodule.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 554bd1c494..b43af
When auto-correct is enabled, an invalid git command prints a warning and
a continuation message, which differs depending on whether or not
help.autoCorrect is positive or negative.
With help.autoCorrect = 15:
WARNING: You called a Git command named 'lgo', which does not exist.
Continuing u
Marc Branchaud writes:
> Signed-off-by: Marc Branchaud
> ---
>
> On 2016-12-18 07:48 PM, Chris Packham wrote:
>>
>> This feature already exists (although it's not interactive). See
>> help.autoCorrect in the git-config man page. "git config
>> help.autoCorrect -1" should to the trick.
>
> Awesom
Signed-off-by: Marc Branchaud
---
On 2016-12-18 07:48 PM, Chris Packham wrote:
>
> This feature already exists (although it's not interactive). See
> help.autoCorrect in the git-config man page. "git config
> help.autoCorrect -1" should to the trick.
Awesome, I was unaware of this feature. Than
information
DDEN
> "--ff". I thought we had done that in other cases, but I can't seem to find
> any. But it would make "--no-ff" the primary form, which makes sense, as
> "--ff" is already the default.
>
> Another option would be to teach parse-options to som
find any. But it would make "--no-ff" the primary form, which
makes sense, as "--ff" is already the default.
Another option would be to teach parse-options to somehow treat the
negated form as primary in the help text. That's a bit more code, but
might be usable in other places.
-Peff
I think that was a deliberate design decision to avoid cluttering
the short help text with mention of both --option and --no-option.
People interested may want to try the attached single-liner patch to
see how the output from _ALL_ commands that use parse-options API
looks when given "-
n there ('--no-ff') to disable the option. Maybe
> it would make sense to word the output to include both.
I think that was a deliberate design decision to avoid cluttering
the short help text with mention of both --option and --no-option.
People interested may want to try the atta
-Original Message-
From: Mike Rappazzo [mailto:rappa...@gmail.com]
Sent: Wednesday, November 16, 2016 7:58 AM
To: Vanderhoof, Tzadik
Cc: git@vger.kernel.org
Subject: Re: merge --no-ff is NOT mentioned in help
>(Please reply inline)
>
>On Wed, Nov 16, 2016 at 10:48 AM, Vanderhoo
ents (like '--ff'), there is an automatic counter
argument with "no-" in there ('--no-ff') to disable the option. Maybe
it would make sense to word the output to include both.
>
> -Original Message-
> From: Mike Rappazzo [mailto:rappa...@gmail.com]
>
ik
Cc: git@vger.kernel.org
Subject: Re: merge --no-ff is NOT mentioned in help
On Wed, Nov 16, 2016 at 10:16 AM, Vanderhoof, Tzadik
wrote:
> When I do: "git merge -h" to get help, the option "--no-ff" is left out of
> the list of options.
I am running git version 2.10.0, and run
On Wed, Nov 16, 2016 at 10:16 AM, Vanderhoof, Tzadik
wrote:
> When I do: "git merge -h" to get help, the option "--no-ff" is left out of
> the list of options.
I am running git version 2.10.0, and running git merge --help contains
these lines:
--ff
When I do: "git merge -h" to get help, the option "--no-ff" is left out of the
list of options.
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader o
Hey Mayank,
On Tue, Nov 15, 2016 at 6:00 PM, Mayank Gupta
wrote:
> Hi All,
>
> I'm new to open source and have recently joined this mailing list.
> Since I'm new at this, I think I can initially contribute to the
> community by fixing some small bugs or errors but as the documentation
> is too la
Hi All,
I'm new to open source and have recently joined this mailing list.
Since I'm new at this, I think I can initially contribute to the
community by fixing some small bugs or errors but as the documentation
is too large, I don't know where to start.
So if anybody could guide me on how to go ab
Hi Peff,
On Thu, 3 Nov 2016, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet
On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your
On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
> This is missing a Content-Transfer-Encoding. I think the default is the
> traditional 7-bit ascii encoding, but your body has characters with the
> high-bit set (your UTF-8 bullet).
>
> Try adding:
>
> Content-Transfer-Encoding: 8bit
On Thu, Nov 03, 2016 at 04:15:05PM +0100, Johannes Schindelin wrote:
> When it finally sent out the mail, and I thought everything was alright,
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote ser
Johannes Schindelin writes:
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote server for TEXT command, host: vger.kernel.org
> (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong M
ngs to make
the release engineering of Git for Windows more painless and boring, but
this thing, this unhelpful vger error message is blocking me from doing so
right now.
Help, anyone?
Thanks,
Dscho
Footnote *1*: The release notes are actually written using Markdown:
https://github.com/git-for-windows/
2016-08-26 22:20 GMT+02:00 Junio C Hamano :
>
> Because the whole thing is inside a double-quote pair, $() and $name
> are all interpolated even before test_expect_success is called.
> So the above becomes equivalent to
>
>>> test_expect_success "two commits do not have the same ID" '
>>> g
Ralf Thielow writes:
> 2016-08-26 21:42 GMT+02:00 Junio C Hamano :
>> Junio C Hamano writes:
>>
>>
>> Taking all of these together, I'll queue this as a proposed fix-up
>> directly on top of yours.
>>
>
> Thanks!
Thank you for starting this topic. I forgot to add comment on that
test://html pa
his is OK; with s|As we pass a URL|As we pass a string with
>> :// in it|, the first sentence can be a in-code comment in the test
>> that does this and will help readers of the code in the future.
>
> Hmm. The "://" is really a URL thing.
Perhaps you thought so, b
2016-08-26 21:42 GMT+02:00 Junio C Hamano :
> Junio C Hamano writes:
>
>
> Taking all of these together, I'll queue this as a proposed fix-up
> directly on top of yours.
>
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
2016-08-26 21:06 GMT+02:00 Junio C Hamano :
> Ralf Thielow writes:
>
>> Introduce option --exclude-guides to the help command. With this option
>> being passed, "git help" will open man pages only for actual commands.
>
> Let's hide this option from comman
Junio C Hamano writes:
> Let's hide this option from command help of "git help" itself, drop
> the short-and-sweet "-e", not command-line complete it, and leave it
> not-mentioned here.
> ...
> Unless there is a good reason you MUST do so, avoid quoting t
Ralf Thielow writes:
> Introduce option --exclude-guides to the help command. With this option
> being passed, "git help" will open man pages only for actual commands.
Let's hide this option from command help of "git help" itself, drop
the short-and-sweet &qu
Changes in v2 are:
- add a patch from Dscho to make config variable 'help.browser' work on Windows
again
- rename option "--command-only" to "--exclude-guides" which is less ambiguous
in 'help' context
- improve test script
- refactor usage of argv_array i
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it for both commands
and concepts. Make sure it is an actual command.
This makes "git --help" not working anymore, while
"git help " still works.
Signed-
Introduce option --exclude-guides to the help command. With this option
being passed, "git help" will open man pages only for actual commands.
Since we know it is a command, we can use function help_unknown_command
to give the user advice on typos.
Helped-by: Johannes Schindelin
Sig
t upstream yet) which
> > reverts that change whereby web--browse was sidestepped. That sidestepping
> > was well-intentioned but turned out to cause more harm than good.
> >
>
> So I'll pickup the patch you sent [1] to my series and prepare the test cases
> the
ed out to cause more harm than good.
>
So I'll pickup the patch you sent [1] to my series and prepare the test cases
the way you described to verify that the 'help' command works.
Thanks!
[1]
http://public-inbox.org/git/03ae6a9d47cb95a54960bfdc90c5392f890ff1e3.1471595956.git
2016-08-19 10:39 GMT+02:00 Remi Galan Alfonso
:
> Hi Ralf,
>
> Ralf Thielow writes:
>> [...]
>> +test_expect_success "works for commands and guides by default" "
>> + git help status &&
>> +git help revisions
>> +&q
Sorry for being late in responding. It's been busy days.
2016-08-18 21:51 GMT+02:00 Junio C Hamano :
> Ralf Thielow writes:
>
> The same comment applies to 1/2, too, in that the word "command"
> will be interpreted differently by different people. For example,
> &q
Johannes Schindelin writes:
> - configure help.format = html (for "man", the current code would always
> add $(prefix)/share/man to the MANPATH when testing, not what we want,
> and hacking this code *just* for testing is both ugly and unnecessary).
A very constructive suggestion to show a g
Hi Ralf,
On Thu, 18 Aug 2016, Ralf Thielow wrote:
> diff --git a/t/t0012-help.sh b/t/t0012-help.sh
> new file mode 100755
> index 000..e20f907
> --- /dev/null
> +++ b/t/t0012-help.sh
> @@ -0,0 +1,21 @@
> +#!/bin/sh
> +
> +test_description=&#
Hi Ralf,
Ralf Thielow writes:
> [...]
> +test_expect_success "works for commands and guides by default" "
> +git help status &&
> +git help revisions
> +"
> +
> +test_expect_success "--command-only does not work f
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know. Make sure it is a Git command.
This breaks "git --help" while "git help " still works.
Signed-off-by: Ralf Thielow
From: "Ralf Thielow"
Introduce option --command-only to the help command. With this option
being passed, "git help" will open man pages only for commands.
Since we know it is a command, we can use function help_unknown_command
to give the user advice on typos.
Signed-
In this version, one patch has been turned into two. The first introduces the
option "command-only" to make 'help' only working for commands and additionally
give some nice help on typos. The second makes option --help only work for
actual
Git commands.
Ralf Thielow (2
Introduce option --command-only to the help command. With this option
being passed, "git help" will open man pages only for commands.
Since we know it is a command, we can use function help_unknown_command
to give the user advice on typos.
Signed-off-by: Ralf Thielow
---
I am not
Ralf Thielow writes:
> If option --help is passed to a Git command, we try to open
> the man page of that command. However, we do it even for commands
> we don't know. Make sure it is a Git command.
What the patch does is correct, I think, but the explanation may
invite a false
Ralf Thielow writes:
> 2016-08-16 19:27 GMT+02:00 Junio C Hamano :
>> Ralf Thielow writes:
>>> +
>>> + if (swapped)
>>> + return help_unknown_cmd(cmd);
>>
>> I am guilty of suggesting "swapped"; even if we are going to mark
>> this as OPT_HIDDEN, I think we should be able to thin
2016-08-16 19:27 GMT+02:00 Junio C Hamano :
> Ralf Thielow writes:
>> +
>> + if (swapped)
>> + return help_unknown_cmd(cmd);
>
> I am guilty of suggesting "swapped"; even if we are going to mark
> this as OPT_HIDDEN, I think we should be able to think of a better
> name. I think t
tatic int swapped = 0;
This is not the first offender (show_guides above does so, too), but
please do not initialize static explicitly to 0 or NULL.
> static struct option builtin_help_options[] = {
> + OPT_BOOL('s', "swapped", &swapped, "mark as being called
2016-08-16 18:33 GMT+02:00 John Keeping :
> On Tue, Aug 16, 2016 at 06:20:30PM +0200, Ralf Thielow wrote:
>> static struct option builtin_help_options[] = {
>> + OPT_BOOL('s', "swapped", &swapped, "mark as being called by
>> --help")
On Tue, Aug 16, 2016 at 06:20:30PM +0200, Ralf Thielow wrote:
> If option --help is passed to a Git command, we try to open
> the man page of that command. However, we do it even for commands
> we don't know. Make sure it is a Git command by using "help_unknown_cmd"
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know. Make sure it is a Git command by using "help_unknown_cmd"
which is even able to assume a command if the user made a typo.
This breaks &quo
(builtin/help.c: add --guide
> >> option, 2013-04-02)) was that we had no easy way of determining what
> >> guides were available, especially given the *nix/Windows split where
> >> the help defaults are different (--man/--html).
> >>
> >> At the time[1] w
"Philip Oakley" writes:
> The other option is to simply build a guide-list in exactly the same
> format as the command list (which if it works can be merged
> later). Re-use the existing code, etc.
Yeah, that sounds like a good way to go forward. To implement typo
corre
ailable, especially given the *nix/Windows split where
the help defaults are different (--man/--html).
At the time[1] we (I) punted on trying to determine which guides were
actually installed, and just created a short list of the important
guides, which I believe you now check. However the less comm
ally given the *nix/Windows split where
> the help defaults are different (--man/--html).
>
> At the time[1] we (I) punted on trying to determine which guides were
> actually installed, and just created a short list of the important
> guides, which I believe you now check. However the le
From: "Ralf Thielow"
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know. Make sure the command is known to Git before try
to open the man page. If we don't know the command, give the
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know. Make sure the command is known to Git before try
to open the man page. If we don't know the command, give the
usual advice.
Signed-off-by: Ra
"Philip Oakley" writes:
> But does it cope with the Guides? Should it cope if spelt that way?
>
> git help revisions
> git revisions --help
Hmph. Ralf's patch is not just "I wonder if we could do a bit
better" but is also a regression. I do not particul
From: "Junio C Hamano"
To: "Ralf Thielow"
Cc: ; ;
Sent: Friday, August 12, 2016 11:53 PM
Subject: Re: [PATCH] help: make option --help open man pages only for Git
commands
Junio C Hamano writes:
I love it when I say "This shouldn't be too hard; somebody
g said that, I wonder if we could do a bit better.
$ git -c help.autocorrect=1 whatchange --help
WARNING: You called a Git command named 'whatchange', which does not exist.
Continuing under the assumption that you meant 'whatchanged'
in 0.1 seconds automatical
Ralf Thielow writes:
> If option --help is passed to a Git command, we try to open
> the man page of that command. However, we do it even for commands
> we don't know. Make sure the command is known to Git before try
> to open the man page. If we don't know the command, g
401 - 500 of 1049 matches
Mail list logo
