Hi Junio,
On 13/05/2019 23:44, Junio C Hamano wrote:
Philip Oakley writes:
On GfW I commonly use the `git --help` when things go wrong, so
making the response to that give the right advice would be good.
There are three levels of details ;-) "git --help" is meant as a
shorter a
Philip Oakley writes:
> On GfW I commonly use the `git --help` when things go wrong, so
> making the response to that give the right advice would be good.
There are three levels of details ;-) "git --help" is meant as a
shorter and sweeter version of "git help git"
Hi Peff
On 13/05/2019 21:53, Jeff King wrote:
On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote:
Is there a cli way, especially on Git for Windows bash, to get the html man
page of git(1)? I have it on my system, so can go via another page but..
All the `git --help` appear to
On Mon, May 13, 2019 at 09:47:27PM +0100, Philip Oakley wrote:
> Is there a cli way, especially on Git for Windows bash, to get the html man
> page of git(1)? I have it on my system, so can go via another page but..
>
> All the `git --help` appear to work, but I can't dete
Is there a cli way, especially on Git for Windows bash, to get the html
man page of git(1)? I have it on my system, so can go via another page but..
All the `git --help` appear to work, but I can't determine the
correct invocation for bringing up the stupid content tracker's pa
On Tue, Dec 11, 2018 at 06:30:26PM +0100, Sebastian Gniazdowski wrote:
> 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.githubuserconte
On Tue, Dec 11, 2018 at 6:42 PM Sebastian Gniazdowski
wrote:
>
> 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.c
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
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
许铖 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 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 +++
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 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
>> +command, use `git COMMAND --help`.
>
>
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
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 Fri, Sep 28, 2018 at 09:30:51AM -0700, Junio C Hamano wrote:
> 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 comma
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
>> > have even if we don't replace "help -a
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 "help -a". Aliases are more
> > subje
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 running it), but a quick
eye
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 verbose output to help those who do
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
o page"),
> HELP_FORMAT_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
themselves to run "git help -av", we should probably continue to give
them this output.
-Peff
}
@@ -494,9 +458,48 @@ void list_config_help(int for_human)
string_list_clear(&keys, 0);
}
+static int get_alias(const char *var, const char *value, void *data)
+{
+ struct string_list *list = data;
+
+ if (skip_prefix(var, "alias.", &var))
+ string_list_a
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" to find
> things like "clang-format", which I
(I think
it was up to 2.17.x series, but do not quote me on that) have parsed
"git help -a" output to obtain the list of commands. So such a
change would impact those minority users who keep stale completion
script in their $HOME/.bashrc without ever update it, thinking it is
good enough.
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
Awesome, thanks!
On Thu, 26 Jul 2018, 2:00 p.m. Eric Sunshine,
wrote:
> On Thu, Jul 26, 2018 at 1:01 AM Vishwas Kamath
> wrote:
> > I am unable to use Git (version 2.18 latest). Since i couldnt find any
> help/support/contact email on https://git-scm.com and i couldnt find the
> solution using
On Thu, Jul 26, 2018 at 1:01 AM Vishwas Kamath wrote:
> I am unable to use Git (version 2.18 latest). Since i couldnt find any
> help/support/contact email on https://git-scm.com and i couldnt find the
> solution using Google as well i am directly contacting you as i need to get
> git working.
Hi,
I am unable to use Git (version 2.18 latest). Since i couldnt find any
help/support/contact email on https://git-scm.com and i couldnt find the
solution using Google as well i am directly contacting you as i need to get
git working. Hope you can help me.
please find attached an image file reg
Am 07.03.2018 um 23:45 schrieb Junio C Hamano:
> kalle writes:
>
>> Am 06.03.2018 um 02:36 schrieb Junio C Hamano:
>>> kalle writes:
>>>
-In the explanation of the option --reference: shouldn't there be
written '' instead of 'reference repository'?
>>>
>>> "Shouldn't X be Y?" is not
kalle writes:
> Am 06.03.2018 um 02:36 schrieb Junio C Hamano:
>> kalle writes:
>>
>>> -In the explanation of the option --reference: shouldn't there be
>>> written '' instead of 'reference repository'?
>>
>> "Shouldn't X be Y?" is not an effective way to communicate; it
>> solicits a "no, th
I wrote this, because when it is written about 'reference repository', I
consider it not totally clear, which repository is meant, as the option
'--reference ' only names one as .
For reasons of clearness, I now propose writing "reference repository
".
kalle
Am 06.03.2018 um 02:36 schrieb Junio C
kalle writes:
> -In the explanation of the option --reference: shouldn't there be
> written '' instead of 'reference repository'?
"Shouldn't X be Y?" is not an effective way to communicate; it
solicits a "no, the current one is fine." without any explanation.
If you think X should be Y for som
-In the explanation of the option --reference: shouldn't there be
written '' instead of 'reference repository'?
greetings,
kalle
while writing up a cheat sheet with a visual layout of .git for my
students, i compared "git help repository-layout" to my git clone of
the kernel source tree, and noted the following things are not
mentioned in the repo layout help page -- i have no idea how complete
that page is s
in a week hopefully with a patch.
thank you,
-Alfred
On 6/7/16 1:08 PM, Eric Wong wrote:
+Cc Alfred, David
Joseph Pecoraro wrote:
`git help svn` does not mention `propset` but it does mention `proplist` and
`propget`. This seems like an oversight.
$ git help svn
.
+Cc Alfred, David
Joseph Pecoraro wrote:
> `git help svn` does not mention `propset` but it does mention `proplist` and
> `propget`. This seems like an oversight.
>
>
> $ git help svn
> ...
> proplist
> Lists the properties stored in the Sub
`git help svn` does not mention `propset` but it does mention `proplist` and
`propget`. This seems like an oversight.
$ git help svn
...
proplist
Lists the properties stored in the Subversion repository about a
given file or directory.
Use -r/--revision
"Philip Oakley" writes:
>> The first step may be to teach a new subcommand to "git help"
>> to show a list of these words, and then _git_help can use it to
>> lazily compute the list just like __git_commands does.
>
> 'git help -a' (or --al
Wouldn't it make more
sense to go in the direction of _removing_ this list of hardcoded
words here?
The first step may be to teach a new subcommand to "git help"
to show a list of these words, and then _git_help can use it to
lazily compute the list just like __git_commands does.
t make more
sense to go in the direction of _removing_ this list of hardcoded
words here?
The first step may be to teach a new subcommand to "git help"
to show a list of these words, and then _git_help can use it to
lazily compute the list just like __git_commands does.
But this change
Ralf Thielow writes:
> Signed-off-by: Ralf Thielow
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Sounds sensible. Thanks.
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index e3918
Signed-off-by: Ralf Thielow
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 70f4171..ffe6004 100644
--- a/contrib/completion/git-completion.bas
The bash completion is missing the option '--guides' for 'git-help'
and some params you see there. Add them both.
Ralf Thielow (2):
completion: add option '--guides' to 'git help'
completion: add 'revisions' and 'everyday' to '
Signed-off-by: Ralf Thielow
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index e3918c8..70f4171 100644
--- a/contrib/completion/git-completion.bash
++
Eric Sunshine writes:
>> rebased on 'next' (a2776d4)
>
> Something to keep in mind for the future: It's usually easier to
> manage preparatory cleanup patches by incorporating them into the
> series which needs/wants them rather than posting them as separate
> topics. That way, your patch series
On Tue, Oct 21, 2014 at 12:31:55PM +, ravikirangoud_palpano...@vfc.com
wrote:
> Hi Brian,
> My Open SSL vendor is IBM. In fact I am using AIX OS from IBM. When we
> (Myself and Frank. Frank is cc'ed in this email) discussed with IBM
> team, they asked some details on what flag settings need t
arlson'
Cc: git@vger.kernel.org
Subject: RE: Git Help needed
Hi Brian,
Thank you.
Understood OpeSSL and vendor from your original message now.
Thanks,
Ravi.
-Original Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net]
Sent: Friday, August 01, 2014 5:00 PM
To:
From: "Junio C Hamano"
Thanks.
Looked alright from a cursory read; I tweaked s/10/-10/ where you
gave examples of limiting output from "git log" before queuing.
That was my mis-reading. I'd even noticed that it looked 'different'
but just didn't see the leading '-' when checking the man page.
Thanks.
Looked alright from a cursory read; I tweaked s/10/-10/ where you
gave examples of limiting output from "git log" before queuing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
ate a summary of changes
>> +for your upstream to pull.
>> +
>
> This new item looks somewhat out of place, doesn't it? It is
> because this is a participant item, not an integrator item.
The bullet item moved to Participant, and the text there updated.
>
The "Everyday GIT With 20 Commands Or So" is not accessible via the
Git help system. Move everyday.txt to giteveryday.txt so that "git
help everyday" works, and create a new placeholder file everyday.html
to refer people who follow existing URLs to the updated location.
The "Everyday GIT With 20 Commands Or So" is not accessible via the
Git help system. Move everyday.txt to giteveryday.txt so that "git
help everyday" works, and create a new placeholder file everyday.html
to refer people who follow existing URLs to the updated location.
Here's version three of my patches to make 'git help everyday' work.
It's taken awhile. Previous patches at [1] and [2].
Junio has provided guidance on modernisation of the text, which has
been integrated into patch 1.
Patch 2 regularises the OBSOLETE_HTML method in the mak
Hi Brian,
Thank you.
Understood OpeSSL and vendor from your original message now.
Thanks,
Ravi.
-Original Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net]
Sent: Friday, August 01, 2014 5:00 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git
On Fri, Aug 01, 2014 at 08:27:24PM +, ravikirangoud_palpano...@vfc.com
wrote:
> Hi brian,
> Thanks for your quick reply.
>
> I downloaded git 1.9.0 from the site
> https://code.google.com/p/git-core/downloads/list.
That URL is obsolete. Try https://www.kernel.org/pub/software/scm/git/
Googl
, August 01, 2014 4:05 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git Help needed
On Fri, Aug 01, 2014 at 07:30:11PM +, ravikirangoud_palpano...@vfc.com
wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place
> to ask please i
Subject: Re: Git Help needed
This looks more like a packaging/build issue than a git issue.
It looks like whomever built your version of git built it against a specific
version of the OpenSSL library.
You should probably contact the folks that built your binary and ask them to
update and build
On Fri, Aug 01, 2014 at 07:30:11PM +, ravikirangoud_palpano...@vfc.com
wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place
> to ask please ignore and suggest me what to do to get the help on
> these questions.
>
> 1) What version of SSL is supported by GIT 1.8.
ompatibility issue.
>
> The error is
> OpenSSL version mismatch. Built agains 1000105f, you have 10bf
> fatal: Could not read from remote repository
>
> In order to get rid of this, I upgraded git to 1.9.0 GIT. But still it didn't
> work. The issue is still coming.
>
>
library compatibility issue.
The error is
OpenSSL version mismatch. Built agains 1000105f, you have 10bf
fatal: Could not read from remote repository
In order to get rid of this, I upgraded git to 1.9.0 GIT. But still it didn't
work. The issue is still coming.
git help, version works.
Joel Nothman writes:
> Git help --all had listed all git commands, but no configured aliases.
> This includes aliases as a separate listing, after commands in the main
> git directory and other $PATH directories.
>
> Signed-off-by: Joel Nothman gmail.com>
> ---
Thanks.
&g
From: "Joel Nothman"
On 26 February 2014 06:15, Junio C Hamano wrote:
Joel Nothman writes:
Git help --all had listed all git commands, but no configured
aliases.
This includes aliases as a separate listing, after commands in the
main
git directory and other $PATH directories.
On 26 February 2014 08:51, Junio C Hamano wrote:
> Joel Nothman writes:
>
>> arguments to git help. They are also like commands in that it is
>> possible to forget their name, or whether they are defined on a
>> particular workstation, and to hence want a listing.
&g
Joel Nothman writes:
> arguments to git help. They are also like commands in that it is
> possible to forget their name, or whether they are defined on a
> particular workstation, and to hence want a listing.
I did envision that it would be useful for the last case, but then
the users
On 26 February 2014 06:15, Junio C Hamano wrote:
> Joel Nothman writes:
>
>> Git help --all had listed all git commands, but no configured aliases.
>> This includes aliases as a separate listing, after commands in the main
>> git directory and other $PATH directories.
&
Joel Nothman writes:
> Git help --all had listed all git commands, but no configured aliases.
> This includes aliases as a separate listing, after commands in the main
> git directory and other $PATH directories.
... and why is this a good thing?
>
> Signed-off-by: Joel Not
Git help --all had listed all git commands, but no configured aliases.
This includes aliases as a separate listing, after commands in the main
git directory and other $PATH directories.
Signed-off-by: Joel Nothman gmail.com>
---
Documentation/git-help.txt | 4 +--
builtin/hel
==
+
+NAME
+
+gituser-manual - a link to the user-manual docbook
+
+
+SYNOPSIS
+
+[verse]
+'git help user-manual'
+
+link:user-manual.html[Git User's Manual]
Is it just me, or is typing
$ git help user-manual
and not seeing the manual itself, but only a link you hav
===
> +
> +NAME
> +
> +gituser-manual - a link to the user-manual docbook
> +
> +
> +SYNOPSIS
> +
> +[verse]
> +'git help user-manual'
> +
> +link:user-manual.html[Git User's Manual]
Is it just me, or is typing
$ git help us
)
+=
+
+NAME
+
+gituser-manual - a link to the user-manual docbook
+
+
+SYNOPSIS
+
+[verse]
+'git help user-manual'
+
+link:user-manual.html[Git User's Manual]
+
+DESCRIPTION
+---
+Git is a fast, scalable, distributed revision control system with an
+unusual
luded both within the
git(1) section it came from, and a new release-notes(7) man page.
With that set up the Documentation/Makefile would generate the man
pages, with their appropriate links, which can be accessed via the 'git
help' command.
The big 'however' was that thi
"Philip Oakley" writes:
> I already have a local patch that creates a stalenote.txt file, and
> includes that in a "release-notes(7)" man page, but it still leaves
> the actual release notes in a separate plain text file, linked from
> the man page, rather than being right at hand, which is what
From: "Junio C Hamano"
"Philip Oakley" writes:
Determining which is the current release note is possibly more
problematic, which should be when making the documentation.
Hmmm Why?
You are already aware of the stale-notes section, no? Isn't the top
one the lat
"Philip Oakley" writes:
> Determining which is the current release note is possibly more
> problematic, which should be when making the documentation.
Hmmm Why?
You are already aware of the stale-notes section, no? Isn't the top
one the latest?
--
To unsubscribe from this list: send the l
From: "Stefan Näwe"
Am 16.01.2014 22:14, schrieb Philip Oakley:
From: "Stefan Näwe"
[...]
I'd really like to see 'git help relnotes' working as well...
Stefan
Stefan,
Were you thinking that all the release notes would be quoted verbatim
in
the one lo
Am 16.01.2014 22:14, schrieb Philip Oakley:
> From: "Stefan Näwe"
> [...]
>>
>> I'd really like to see 'git help relnotes' working as well...
>>
>> Stefan
>
> Stefan,
>
> Were you thinking that all the release notes would be qu
From: "Stefan Näwe"
[...]
I'd really like to see 'git help relnotes' working as well...
Stefan
Stefan,
Were you thinking that all the release notes would be quoted verbatim in
the one long man page?
Or that it would be a set of links to each of the individual t
)
+=
+
+NAME
+
+gituser-manual - a link to the user-manual docbook
+
+
+SYNOPSIS
+
+[verse]
+'git help user-manual'
+
+link:user-manual.html[Git User's Manual]
+
+DESCRIPTION
+---
+Git is a fast, scalable, distributed revision control system with an
+unusual
The "Everyday GIT With 20 Commands Or So" is not accessible via the
Git help system. Fix that.
Move everyday.txt to giteveryday.txt.
Update giteveryday.txt to fit man page formatting.
Add standard man page section titles.
Also adjust anchor text markup for man page format.
Add gitevery
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring tha
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring tha
Hi,
Philip Oakley wrote:
> The "Everyday GIT With 20 Commands Or So" guide is not accessible
> via the git help system. Fix that.
Neat. :)
Junio covered everything I'd want to say about patch 1/6.
After fixing that, I'd suggest squashing all 6 patches into a single
"Philip Oakley" writes:
> From: "Junio C Hamano"
>>I think we already use a nicer way to set up a page alias to keep
>> old links working than making a copy in Documentation/; please mimic
>> that if possible.
>
> This was mainly about ensuring t
ommands,
> as things have vastly changed over the past 8 years. Perhaps we
> should do that after reorganizing with something like this series.
I'd really like to see 'git help relnotes' working as well...
Stefan
--
-
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring that the 'git help' command could access
these extra extra guid
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
It may be overdue to refresh the suggested set of "top 20" commands,
as things have vastly changed over the past 8 years. Perhaps we
should do t
The "Everyday GIT With 20 Commands Or So" guide is not accessible via the git
help system. Fix that.
The git everyday file does not use the appropriate filenaming convention for
help files, and is not suitably formatted for display as a man page.
First copy everyday.txt to gitev
; I don't mean a setenv() kind of thing: how would we unset it after
>> that? Perhaps something like execvpe(), passing in the environment as
>> an argument?
Running "man" is the last thing we do before exitting "git help" and
exec_man_man() does seem to do ex
;s because they want a specific pager
when reading man pages - invoking man through "git help" shouldn't cause
it to behave differently in this case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Matthieu Moy wrote:
> I find it a bit weird that Git sets the configuration for external
> commands, but it may make sense. No strong opinion here.
I don't mean a setenv() kind of thing: how would we unset it after
that? Perhaps something like execvpe(), passing in the environment as
an argument?
a small problem with it
> though: why is there no option for Emacs man corresponding to Emacs
> woman?
I guess because no one implemented it ;-).
>> I personally run M-x git-foo RET, and never run "git help".
>
> M-x man git-foo RET, you mean?
Yes, sorry.
--
Mat
Matthieu Moy wrote:
> Michael Campbell writes:
>> I have my global git config pager set to 'cat', but when I do a "git
>> help ", it still uses a pager. This is especially irksome in
>> emacs shell buffers, where I am most of the time. I know I can do a
Michael Campbell writes:
> I have my global git config pager set to 'cat', but when I do a "git
> help ", it still uses a pager. This is especially irksome in
> emacs shell buffers, where I am most of the time. I know I can do a
> M-x man -> git-, but wondere
1 - 100 of 152 matches
Mail list logo
