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 wondered if this was a bug or user
error. ("gi
Philip Oakley writes:
> Prepare for the addition of the -g --guides option to git help
> and show that help is available for both concept guides, and commands.
>
> Signed-off-by: Philip Oakley
> ---
This should come at the end after you taught the "-g" option, I
think
Prepare for the addition of the -g --guides option to git help
and show that help is available for both concept guides, and commands.
Signed-off-by: Philip Oakley
---
git.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index 39ba6b1..2f8aa41 100644
--- a
n, as they overide any
remaining arguments.
The list of guides is spaced out in the same manner as the common
command list.
Philip Oakley (5):
Show help: -a and -g option, and 'git help ' usage.
Help.c use OPT_BOOL and refactor logic
Help.c add --guide option
Help.c: add list_common_gu
Matthias Krüger writes:
> On 03/28/2013 06:59 AM, Junio C Hamano wrote:
>> Matthias Krüger writes:
>>
>>> "insn" appears to be an in-code abbreviation and should not appear in
>>> manual/help pages.
>>> ---
>> Thanks; sign-off?
> Oops, sorry.
>
> Signed-off-by: Matthias Krüger
>
> (Is this suf
On 03/28/2013 06:59 AM, Junio C Hamano wrote:
Matthias Krüger writes:
"insn" appears to be an in-code abbreviation and should not appear in
manual/help pages.
---
Thanks; sign-off?
Oops, sorry.
Signed-off-by: Matthias Krüger
(Is this sufficient or do I have to re-send the patch with the
Matthias Krüger writes:
> "insn" appears to be an in-code abbreviation and should not appear in
> manual/help pages.
> ---
Thanks; sign-off?
--
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://vge
"insn" appears to be an in-code abbreviation and should not appear in
manual/help pages.
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c1f435f..f79184c 100644
--- a/Documentation/config.tx
Michael J Gruber writes:
> Well, even in the simple case one has to wonder: Why does the user
> invoke help for "co"? There are two very likely cases:
>
> A) User does not remember what "co" is aliased to.
> B) User wants to see the man page.
>
> If A is not the case then it's easy for the user t
Jeff King venit, vidit, dixit 05.03.2013 18:38:
> On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the semantics of "git --help" to show the help for the
>> command is aliased to, instead of just saying:
>>
>> `
On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have &q
"H.Merijn Brand" writes:
> A single word that is (already) known to git as being a valid command
> to do --help with. I which case I fully agree.
Just to insist on "that is known to git as being a valid command".
Compare:
$ git foo --help
`git foo' is aliased to `bar'
with
$ git foo --help
N
Ævar Arnfjörð Bjarmason writes:
> No objection to the patch in principle though? I.e. not showing you
> what the alias points to.
I am not interested enough to even strongly object to such a change,
because it is not reasonable to react with a "I know!" to the output
of "git co --help", i.e. "'g
On Tue, Mar 5, 2013 at 5:16 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change the semantics of "git --help" to show the help for the
>> command is aliased to, instead of just saying:
>>
>> `git ' is aliased to `'
>
Ævar Arnfjörð Bjarmason writes:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased to "co" you won
On Tue, 05 Mar 2013 16:42:52 +0100, Johannes Sixt
wrote:
> Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> > Change the semantics of "git --help" to show the help for the
> > command is aliased to, instead of just saying:
> >
> > `git '
Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased
Change the semantics of "git --help" to show the help for the
command is aliased to, instead of just saying:
`git ' is aliased to `'
E.g. if you have "checkout" aliased to "co" you won't get:
$ git co --help
`git co' is aliased t
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another
documentation page. The 'tutorial' is an obvious gu
This is the much truncated (was 0/13] and updated series for
noting that 'git help' can display the existing guides that are
formatted as man pages, and providing a 'git help' option to list
a few of the most useful guides.
The series is rebased on top of V1.8.2-rc1
Differ
Philip Oakley writes:
> The git(1) man page must be accessed via 'git help git' on Git for Windows
> as it has no 'man' command. And it prompts users to read the git(1) page,
> rather than hoping they follow a subsidiary link within another
> documentation pa
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another
documentation page. The 'tutorial' is an obvious gu
This is the much truncated (was 0/13] and updated series for
noting that 'git help' can display the existing guides that are
formatted as man pages, and providing a 'git help' option to list
a few of the most useful guides.
The series is rebased on top of V1.8.2-rc1
Differ
On 24/02/13 14:39, W. Trevor King wrote:
On Sat, Feb 23, 2013 at 11:05:50PM +, Philip Oakley wrote:
+ "Examples: 'git help git', 'git help branch', 'git help
tutorial'..");
This sentence should end in '.', not '..'.
On Sat, Feb 23, 2013 at 11:05:50PM +, Philip Oakley wrote:
> +"Examples: 'git help git', 'git help branch', 'git help
> tutorial'..");
This sentence should end in '.', not '..'.
Cheers,
Trevor
--
This email may
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another documentation
page. The 'tutorial' is an obvious gu
The git help system will list common commands, and all commands
if asked. However it is difficult for newer users to discover the
guides that are available. This series seeks to add such an option
to 'git help', and allow the user-manual and [git]everyday to be
accessed in the same way
From: "John Keeping"
Sent: Tuesday, February 12, 2013 11:37 AM
On Tue, Feb 12, 2013 at 11:11:17AM -, Philip Oakley wrote:
Obviously (?) this is generated from the command-list.txt file,
though I
don't see a shell script that would generate the
'cmds-mainporcelain.txt' (etc.) files
(//githu
On Tue, Feb 12, 2013 at 11:11:17AM -, Philip Oakley wrote:
> Obviously (?) this is generated from the command-list.txt file, though I
> don't see a shell script that would generate the
> 'cmds-mainporcelain.txt' (etc.) files
> (//github.com/gitster/git-htmldocs). They are also part of the ms
From: "Philip Oakley"
Sent: Friday, February 08, 2013 11:16 PM
From: "Junio C Hamano"
Sent: Friday, February 08, 2013 10:54 PM
"Philip Oakley" writes:
My initial https://github.com/PhilipOakley/git/commit/e6217d simply
updates
- N_("See 'git h
Hi,
the man page (git version 1.7.10.4) is a bit non-symmetric
since git bisect has the start param, but when searching for "stop"
(nothing more obvious than that, right?),
one comes up empty --> usability issue.
The appropriate action complementary to start appears to be
git bisect reset, thus i
From: "Junio C Hamano"
Sent: Friday, February 08, 2013 10:54 PM
"Philip Oakley" writes:
My initial https://github.com/PhilipOakley/git/commit/e6217d simply
updates
- N_("See 'git help ' for more information on a specific
command.");
+ N_("See &
"Philip Oakley" writes:
> My initial https://github.com/PhilipOakley/git/commit/e6217d simply
> updates
> - N_("See 'git help ' for more information on a specific
> command.");
> + N_("See 'git help ' for more information on a speci
From: "Junio C Hamano"
Sent: Friday, February 08, 2013 8:53 PM
"Philip Oakley" writes:
I'm looking at extending the 'git help' to include some information
for the basic user who isn't ready for the extensive man page
documentation for the various comma
"Philip Oakley" writes:
> I'm looking at extending the 'git help' to include some information
> for the basic user who isn't ready for the extensive man page
> documentation for the various commands.
We have pointers at the beginning of "git(1)
I'm looking at extending the 'git help' to include some information for
the basic user who isn't ready for the extensive man page documentation
for the various commands.
If the user doesn't yet know which is the relevant command then they
should also be offered a c
The check-docs target special-cases git-help to avoid
mentioning it as "documented but removed". This dates back
to the early implementation of git-help, when its code was
simply included inside git.c.
These days it is a full-fledged builtin (in builtin/help.c)
and does not need spec
We've decided to go for the individual scripts directly. :-)
Just to clarify - individual scripts or $0 name handling?
I kinda like one big script - also means we don't need to 'install' it
to get access to Cogito.pm...
Unfortunately, you didn't send the attachments inline, so I can't
comment on
Dear diary, on Tue, Apr 19, 2005 at 09:04:16PM CEST, I got a letter
where David Greaves <[EMAIL PROTECTED]> told me that...
> I don't love the 'require gitadd.pl' but it's a gradual start...
I hate it, for one. ;-)
> Cogito.pm seems to be a good place for the library stuff.
Sounds sensible.
> g
Steven Cole wrote:
Speaking of "I think", the name "cogito" was suggested for the
SCM layer, but IIRC Linus suggested staying with just plain git. Petr
suggested tig, perhaps because it looks at git from another point of view.
I haven't read _all_ the mails - I thought cogito was kinda selected and
David Greaves wrote:
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
I've been working on git.pl and getting help working nicely
things to try:
git.pl help
git.pl add
git.pl add --help
git.pl add --man
git.
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
I've been working on git.pl and getting help working nicely
things to try:
git.pl help
git.pl add
git.pl add --help
git.pl add --man
git.pl help add
The main
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> Example:
..snip a perfect-looking example..
> -
> Speaking of 'git diff', I ran that before applying the following patch,
> and got a diff starting thusly:
>
> --- /
s the right thing for git help ci.
Example:
[EMAIL PROTECTED] git-pasky-testing]$ ./git help diff
Make a diff between two GIT trees.
By default compares the current working tree to the state at the
last commit. You can specify -r rev1:rev2 or -r rev1 -r rev2 to
tell it to make a diff between the specif
Dear diary, on Tue, Apr 19, 2005 at 04:41:34PM CEST, I got a letter
where David Greaves <[EMAIL PROTECTED]> told me that...
> If Petr wants the top comment to be extracted by help then maybe a
> bottom comment block could contain the more complete text?
> I *really* think that the user docs should
David Greaves wrote:
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the s
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the style of a man page.
Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> Here is perhaps a better way to provide detailed help for each
> git command. A command.help file for each command can be
> written in the style of a man page.
I don't like
opyright notices.
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the style of a man page.
The modfication to the main git script will be trivial.
Here are the two commands I've done so far.
What do folks t
atch myself... ;-) Also, you don't want to print
the first newline and the Copyright notices.
Fixed extra vertical whitespace, Copyright notice problems, and issue
with git help ci.
Here's a better version. Didn't fix the more interesting bugs, as I'm
pressed for time (aren't we al
Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> There's a patch at the bottom of this, so please look at that first before
> my reading my whining immediately below.
>
> I'm having some troubles with git pull, so this is j
he above.
Here is a patch which provides the comment lines in the associated
script files when the git help command is invoked with an argument
thusly:
[EMAIL PROTECTED] git-pasky-new]$ ./git help merge
Merge a branch to the current tree.
Copyright (c) Petr Baudis, 2005
Takes a parameter ident
101 - 152 of 152 matches
Mail list logo