Hi all,
I was recently informed by the author of git-annex that my
implementation of git check-ignore has two minor deficiencies which
currently prevent him from adding .gitignore support to the git-annex
assistant (web UI):
1. When accepting a list of files to check via --stdin, no results
Adam Spiers g...@adamspiers.org writes:
I already have a rough fix for the second issue, but I wanted to
solicit feedback on the appropriate UI changes before proceeding much
further. Does something like the below patch seem reasonable, modulo
the lack of tests? In case the UI changes I am
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 philipoak...@iee.org
---
git.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index 39ba6b1
This is the re-roll of $gmane/217384. The series seeks to provide a help
option that will list the common git guides, and how to access them.
The series is rebased on top of V1.8.2
Since V2, the OPT_BOOL is now used instead of OPT_COUNTUP.
The git_more_info_string has been further updated
/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+ [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
Philip Oakley philipoak...@iee.org writes:
+To display the linkgit:git[1] man page, use 'git help git'.
Good to see that somebody remembers that we discussed this ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Philip Oakley philipoak...@iee.org 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 philipoak...@iee.org
---
This should come at the end after you taught the -g option
On Tue, Apr 2, 2013 at 6:39 PM, Philip Oakley philipoak...@iee.org wrote:
OPTIONS
---
-a::
--all::
Prints all the available commands on the standard output. This
- option supersedes any other option.
+ option overides any given command or guide name.
On 03/28/2013 06:59 AM, Junio C Hamano wrote:
Matthias Krüger matthias.krue...@famsik.de 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 matthias.krue...@famsik.de
Matthias Krüger matthias.krue...@famsik.de writes:
On 03/28/2013 06:59 AM, Junio C Hamano wrote:
Matthias Krüger matthias.krue...@famsik.de writes:
insn appears to be an in-code abbreviation and should not appear in
manual/help pages.
---
Thanks; sign-off?
Oops, sorry.
Signed-off
On Tuesday, March 26, 2013 at 18:07 EDT,
J.V. jvsr...@gmail.com wrote:
I have a branch for which I have made 0 (nada) changes. I did the
following:
$git pull --rebase --no-stat -v --progress origin mybranch
I get the following
U java/Profile.java
Pull is not possible
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.txt
Matthias Krüger matthias.krue...@famsik.de 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
I have a branch for which I have made 0 (nada) changes. I did the
following:
$git pull --rebase --no-stat -v --progress origin mybranch
I get the following
U java/Profile.java
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git
Kevin Bracey ke...@bracey.fi writes:
Two significant usability flaws here:
- If using man, man git to side-step git help is obvious. But if
trying to use help.format=web, how to get the root html page? My
technique was git help XXX and click the git(1) suite link at the
bottom. git
Matthieu Moy matthieu@grenoble-inp.fr writes:
Kevin Bracey ke...@bracey.fi writes:
Two significant usability flaws here:
- If using man, man git to side-step git help is obvious. But if
trying to use help.format=web, how to get the root html page? My
technique was git help XXX
From: Junio C Hamano gits...@pobox.com
Sent: Monday, March 11, 2013 7:02 PM
Matthieu Moy matthieu@grenoble-inp.fr writes:
Kevin Bracey ke...@bracey.fi writes:
Two significant usability flaws here:
- If using man, man git to side-step git help is obvious. But
if
trying to use
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Matthieu Moy matthieu@grenoble-inp.fr writes:
See 'git help git' for general help about Git.
to the output of git help?
...
That sounds like a good direction to go in.
My earlier attempt, and Junio's
On 11/03/2013 05:03, Junio C Hamano wrote:
Hmm, I feel more confused than convinced after reading the above
three times. Perhaps that is because I am too used to the way how
git potty itself behaves, especially the part that git help git
is the way to ask git (the first token on the command
Previously, the command help and the option -h behaved differently
depending on whether a command was specified or not. Old user interface:
Commands with no defaults show usage: git git CMD
To specifically request usage:git help git CMD -h
To get a manual page
On 10/03/13 17:48, Kevin Bracey wrote:
Previously, the command help and the option -h behaved differently
depending on whether a command was specified or not. Old user interface:
Commands with no defaults show usage: git git CMD
To specifically request usage:git help git
Kevin Bracey ke...@bracey.fi writes:
Previously, the command help and the option -h behaved differently
depending on whether a command was specified or not. Old user interface:
Commands with no defaults show usage: git git CMD
To specifically request usage:git help git
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 alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g
Michael J Gruber g...@drmicha.warpmail.net 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
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g. if you have checkout aliased to co you won't get:
$ git co --help
`git co' is aliased to `checkout'
But will instead get
Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g. if you have checkout aliased to co you won't get:
$ git co --help
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g. if you have checkout aliased to co you won't get:
$ git co --help
On Tue, Mar 5, 2013 at 5:16 PM, Junio C Hamano gits...@pobox.com wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g
--help, i.e. 'git co' is aliased to 'checkout', in the
first place. Also some users may find it inconsistent if a single
bareword jumps directly to the manpage and other input shows alias
expansion.
So,... I do not see a very big plus in the proposed (and then
amended by others in the thread) change
On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g. if you have checkout aliased to co you won't get
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
Differences relative to V1
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 guide to suggest.
Signed-off
/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+ [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
Philip Oakley philipoak...@iee.org 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 page. The 'tutorial
..498a94e 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+[-i|--info
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
Differences relative to V1
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 guide to suggest.
Signed-off
/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+ [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
a/Documentation/git-help.txt b/Documentation/git-help.txt
index e07b6dc..498a94e 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web
--help'.) can't be
referring to a 'git-cmd', obviously ;-)
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Are there? For what purpose?
Just found that Git Gui checks for the version number (line 936)
if {![regsub {^git
David Aguilar dav...@gmail.com writes:
This is referring to git the command, not git the system,
so it should not be changed according to the rule that was
applied when many git strings were changed to Git.
That sounds like a sensible objection.
There are scripts, etc. in the wild that
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 be signed or encrypted with GnuPG (http://www.gnupg.org).
For more
.
That sounds like a sensible objection.
I'd read the messages in the tone 'commands of the Git system', but I
can see that both views are equally plausible. Though the final _(git:
'%s' is not a Git command. See 'git --help'.) can't be referring to a
'git-cmd', obviously ;-)
There are scripts, etc
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 '..'.
Cheers,
Trevor
I should have used three as ellipsis
versions. For these, it would be helpful
to have a consistent and stable output that can be easily parsed.
By deciding to not mark these l10n ready and keeping the output
consistent we could help that use case.
[*] I'm not saying this is a good idea or something that scripts
should do, I'm just
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.
Patch 1
*help_unknown_cmd(const char *cmd)
@@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
return assumed;
}
- fprintf_ln(stderr, _(git: '%s' is not a git command. See 'git
--help'.), cmd);
+ fprintf_ln(stderr, _(git: '%s' is not a Git command. See 'git
--help
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 guide to suggest.
Signed-off
command. See 'git
--help'.), cmd);
+ fprintf_ln(stderr, _(git: '%s' is not a Git command. See 'git
--help'.), cmd);
if (SIMILAR_ENOUGH(best_similarity)) {
fprintf_ln(stderr,
@@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)
int cmd_version(int
: '%s' is not a git command. See 'git
--help'.), cmd);
+ fprintf_ln(stderr, _(git: '%s' is not a Git command. See 'git
--help'.), cmd);
if (SIMILAR_ENOUGH(best_similarity)) {
fprintf_ln(stderr,
@@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)
int
'git help command' for more information on a specific
command.);
+ N_(See 'git help command' for more information on a specific
command.\n
+ Or 'git help guide', such as 'tutorial' for an introduction
to Git.);
as a starter for the new users.
Yeah, that would be a good change to make to git
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
From: John Keeping j...@keeping.me.uk
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'
commands. Adding that directory and add a help that exits with
non-zero feels quite a roundabout and counter-intuitive way, no?
I think it comes down to the reason the site admin doesn't want to
allow interactive logins. That reason seems to be mostly that
presenting a
git
prompt at which you
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login
that directory which is a collection of allowed
commands. Adding that directory and add a help that exits with
non-zero feels quite a roundabout and counter-intuitive way, no?
I think it comes down to the reason the site admin doesn't want to
allow interactive logins. That reason seems to be mostly
/help \EOF
+#!/bin/sh
+printf '%s\n' Hi $USER! You've successfully authenticated, but I do not
Where in the sshd to git-shell exec chain is $USER variable set for
the user? Just being curious if this is the simplest but one of the
more robust ways to get the user's name.
That's a good
. The
sole goal is to make the life easier for those site owners that do
not want any interactive shell access to give more friendly and
customized error message.
Those who want further flexibility can exit with non-zero from the
help (which is still a misnomer for a hook to disable interactive
is not a goal of /etc/git/shell-disabled. The
sole goal is to make the life easier for those site owners that do
not want any interactive shell access to give more friendly and
customized error message.
Those who want further flexibility can exit with non-zero from the
help (which is still a misnomer
.
An appropriate greeting might even include more complex information,
like a list of repositories the user has access to. A
git-shell-commands directory with only a help script can get us most
of the way there, but it unfortunately it produces a git prompt
where the user can do nothing but ask for more help
actually could be the
last step)?
That is, showing something like this,
+printf '%s\n' Hi $USER! You've successfully authenticated, but I do not
+printf '%s\n' provide interactive shell access.
but rephrased with a reference to git help shell for people
preparing their own server when ~/git-shell
interactively (with no arguments), 'git-shell' will
+automatically run `~/git-shell-commands/help` on startup, provided it
+exists. If the 'help' command fails then the interactive shell is
+aborted.
Doesn't that mean that people who currently do allow interactive access
and have a ~/git-shell-commands
Jeff King wrote:
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
+When run interactively (with no arguments), 'git-shell' will
+automatically run `~/git-shell-commands/help` on startup, provided it
+exists. If the 'help' command fails then the interactive shell is
+aborted
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
How about this?
A patch on top could change the default git-shell-commands is not
present message if that seems worthwhile.
Hmph.
I wonder if rewording the message when git-shell-commmands directory
is not there may be a
Jeff King wrote:
On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
Only interactive connections. That's the existing behavior.
Ah, sorry. I misread the patch. I see now that we already run help, and
this is just making the exit value significant. In that case, yeah, I
think
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
How about this?
A patch on top could change the default git-shell-commands is not
present message if that seems worthwhile.
Hmph.
I wonder if rewording the message when
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
--
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
On Sun, Feb 10, 2013 at 08:26:09PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
Only interactive connections. That's the existing behavior.
Ah, sorry. I misread the patch. I see now that we already run help
On Sun, Feb 10, 2013 at 08:32:47PM -0800, Jonathan Nieder wrote:
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
As far as the default goes, I think the current one is OK, provided
there is an option to
, status;
static const char *help_argv[] = { HELP_COMMAND, NULL };
/* Print help if enabled */
- run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ if (!status)
+ ; /* success */
+ else
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help for majority of the case where
Jeff King wrote:
I think what threw me off was reading the documentation part of the
patch, which adds a note that we run help on startup, and then
elaborates on the exit value. I didn't realize that the first half was
documenting what already happened.
Tweaking the third paragraph
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano gits...@pobox.com wrote:
Hmph, if that is the case, wouldn't it be a better direction to give
a better help for majority of the case where git-shell is used as
the login shell to allow push and fetch but not for interactive
access at all
and contains a help script, we
already run it when the shell is run without any commands, giving the
server a chance to provide a custom message. Unfortunately, the
presence of the git-shell-commands directory means we also enter an
interactive mode, prompting and accepting commands (of which
not provide shell access.
An appropriate greeting might even include more complex information,
like a list of repositories the user has access to. If the
git-shell-commands directory exists and contains a help script, we
already run it when the shell is run without any commands, giving
direction to give
a better help for majority of the case where git-shell is used as
the login shell to allow push and fetch but not for interactive
access at all?
The first step in that direction may be to give a better canned
message, followed by a mechanism (perhaps a hook) that lets
Ethan Reesor wrote:
That way, there's a default setting, there can
be a system-wide message, there can be a user specific message, and
those messages can be set via `git-commit`.
That won't let me imitate gitolite's behavior without a lot of
config file churn:
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
On Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Ethan Reesor wrote:
That way,
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help
[administrivia: please don't top-post]
Ethan Reesor wrote:
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
What was Junio's complaint?
Jonathan
--
To unsubscribe from this list:
it be a better direction to give
a better help for majority of the case where git-shell is used as
the login shell to allow push and fetch but not for interactive
access at all?
The first step in that direction may be to give a better canned
message, followed by a mechanism (perhaps a hook) that lets
directory for
47 users his host gives git-shell access to, and copy the help
script to all of them, only to get a customized message.
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell
,
delete, or
rename repositories, or change repository descriptions and
permissions.
+If the `help` command exists and exits with nonzero status, the
+interactive shell is aborted.
+
+EXAMPLE
+---
+
+To disable interactive logins, displaying a greeting instead
Jonathan Nieder jrnie...@gmail.com writes:
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login shell, then the
git-shell-commands should not go in their home directory
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Isn't that a criticism of the git-shell-commands facility in general?
If it is common to have a lot of users with distinct home directories
but all with git-shell as their login shell, then the
git-shell-commands should
Ethan Reesor firelizz...@gmail.com writes:
For those who _do_ want to give customized commands to their users,
they can already have help script to give a friendly message. It
just felt silly to force sites to create the directory only to
refuse an access to the custom commands feature
) have Jonathan's patch
whereby ~/git-shell-commands/help returning non-zero closes the
connection?
Isn't that what I have essentially been saying?
That is what you've been saying. I reiterated because I like the idea
of having it managed via git config.
--
To unsubscribe from this list: send
.
Even if the site configures its 47 git-shell users to share the same
home directory /home/gituser, I still think it is a bad design to
force the administrator to create a directory in it, only to add a
script called help.
The purpose of the directory is to keep custom commands that are
allowed
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+To disable interactive logins, displaying a greeting instead:
++
+
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat $HOME/git-shell-commands/help \EOF
+#!/bin/sh
+printf '%s\n' Hi
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 its
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 clue on how to finding
Philip Oakley philipoak...@iee.org 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) for that exact reason.
I am
From: Junio C Hamano gits...@pobox.com
Sent: Friday, February 08, 2013 8:53 PM
Philip Oakley philipoak...@iee.org 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
Philip Oakley philipoak...@iee.org writes:
My initial https://github.com/PhilipOakley/git/commit/e6217d simply
updates
- N_(See 'git help command' for more information on a specific
command.);
+ N_(See 'git help command' for more information on a specific
command.\n
+ Or 'git help
From: Junio C Hamano gits...@pobox.com
Sent: Friday, February 08, 2013 10:54 PM
Philip Oakley philipoak...@iee.org writes:
My initial https://github.com/PhilipOakley/git/commit/e6217d simply
updates
- N_(See 'git help command' for more information on a specific
command.);
+ N_(See 'git help
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index b44a2c8..e338be5 100644
--- a/git-mergetool--lib.sh
+++
git-config to the '--tool-help' output.
[1] http://article.gmane.org/gmane.comp.version-control.git/214964
John Keeping (3):
fixup! mergetool--lib: add functions for finding available tools
fixup! doc: generate a list of valid merge tools
mergetool--lib: list user configured tools in '--tool
'git mergetool --tool-help' only lists builtin tools, not those that the
user has configured via a 'mergetool.tool.cmd' config value. Fix this
by inspecting the tools configured in this way and adding them to the
available and unavailable lists before displaying them.
Signed-off-by: John Keeping
John Keeping j...@keeping.me.uk writes:
I think I'd want to do this with a suffix if at all, so the output would
be like this:
'git mergetool --tool=tool' may be set to one of the following:
araxis
gvimdiff
gvimdiff2
mytool
to post here,
the end result being something that's plugged into Documentation/.
I think what I did may also help add this functionality, and
could be useful to build upon.
I'll send my patches shortly so you can take a look.
Basically, I added a simple way to loop over the tools
and filter them
701 - 800 of 959 matches
Mail list logo
