On 01-05-2013 17:53, Ramkumar Ramachandra wrote:
Vikrant Varma wrote:
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Interesting. Thanks for working on this.
You say advice, but you're not invoking advi
the code
you need to add to 'git merge' would encounter and could help
the user with. "git merge origin/mastre" and "orign/master"
may benefit from a typofix as well, and the mechanism to come
up with the suggestion is likely to hook to the same code
Ramkumar Ramachandra writes:
> You say advice, but you're not invoking advise() or guarding the
> advice with an advice.* -- the advice is undoubtedly helpful, but not
> everyone wants to see it.
Quite franckly, I don't see why anybody would need to disable it.
advice.* is very nice to disable m
Vikrant Varma wrote:
> Give better advice when trying to merge a branch that doesn't exist. If
> the branch exists in any remotes, display a list of suggestions.
Interesting. Thanks for working on this.
You say advice, but you're not invoking advise() or guarding the
advice with an advice.* -- t
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Example:
$ git merge foo
fatal: foo - not something we can merge
Did you mean this?
bar/foo
Signed-off-by: Vikrant Varma
-
Any update about this:
I created this simple bug test to reproduce my problem.
I tried on latest GIT, It fails.
It is really preventing me from using GitSvn.
Any help will be highly appreciated.
Let me know if you have any questions.
[GITSVN] $git --version
git version 1.8.2.GIT
[GITSVN] $git
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git
Hi,
I have been using git-svn successfully for last 1 year.
But yesterday somebody checked in something in SVN using svn client
and It caused inconsitency in GIT-svn repository.
In one of SVN Merge commit, Some symlink files were not made "svn
special" by mistake,
So there was another SVN commit
t; %s ", common_guides[i].name);
+ mput_char(' ', longest - strlen(common_guides[i].name));
+ puts(_(common_guides[i].help));
common_guides[] is used here, but without N_() not picked up by
xgettext when creating the pot file.
Yes. I mucked that up when I hacked the generate-cm
\n"));
> + for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
> + printf(" %s ", common_guides[i].name);
> + mput_char(' ', longest - strlen(common_guides[i].name));
> + puts(_(common_guides[i].help));
common_guides[] is used here, but
On Mon, Apr 08, 2013 at 07:13:11PM +0100, Adam Spiers wrote:
> 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.
Adam Spiers 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 proposing are no
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
On Tue, Apr 2, 2013 at 6:39 PM, Philip Oakley 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.
s/overides/overrides/
>
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
Philip Oakley 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
tation/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
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
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
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?
>
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 patc
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
"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/Doc
On Tuesday, March 26, 2013 at 18:07 EDT,
"J.V." 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 because you
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 a
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
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> Matthieu Moy writes:
>>
>>> See 'git help git' for general help about Git.
>>>
>>> to the output of "git help"?
>> ...
>> That sounds like
From: "Junio C Hamano"
Sent: Monday, March 11, 2013 7:02 PM
Matthieu Moy writes:
Kevin Bracey 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
Matthieu Moy writes:
> Kevin Bracey 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
>>techni
Kevin Bracey 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 &q
Kevin Bracey 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&quo
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 spec
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
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
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 t
Æ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 &quo
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
ntation/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] [COMMAND]
+'git help'
tation/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
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
-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] [COM
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
tation/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
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
the rule that was
applied when many "git" strings were changed to "Git".
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
_("g
n// on the string.
I think being able to find the version at runtime is something
that is typically used by packagers and folks that want to be
portable across git 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
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 '..'.
to "Git".
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'.") c
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
David Aguilar 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 parse thi
st char *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,
N_("'%s' appears to be a Git command, but we were not\n"
> "able to execute it. Maybe git-%s is broken?");
>
> const char *help_unknown_cmd(const char *cmd)
> @@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
>
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
git command, but we were not\n"
+ N_("'%s' appears to be a Git command, but we were not\n"
"able to execute it. Maybe git-%s is broken?");
const char *help_unknown_cmd(const char *cmd)
@@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
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
; 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
> for the user).
Ah, I thought you were proposing shell-disabled _instead_ of Jonathan's
patch, no
g or not a git-shell-commands
> directory), but you cannot individually select the script that runs for
> that user. But it's probably still flexible enough;...
Such a flexibility is not a goal of /etc/git/shell-disabled. The
sole goal is to make the life easier for those site owners t
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> +To disable interactive logins, displaying a greeting instead:
>>> ++
>>> +
>>> +$ chsh -s /usr/bin/git-shell
>>> +$ mkdir $HOME/git-shell-
e _not_ to have 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
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
> Jonathan Nieder 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 th
n 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 that
pres
Junio C Hamano wrote:
> Jonathan Nieder 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
let you set up
> multiple configurations by making multiple home directories.
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 &
etc/gitconfig or ~/.gitconfig, and B) 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 reiter
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 unsu
Ethan Reesor 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 &qu
Junio C Hamano wrote:
> Jonathan Nieder 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 h
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder 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 not go in thei
Jonathan Nieder 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 to begin
> wit
es git-shell access to, and copy the "help"
> script to all of them, only to get a customized message. It would
> help them quite a lot if you just called /etc/git/shell-disabled or
> some hook that generates a customized message; then there is no need
> to add any git-shell-comm
,
> 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 i
hink it is way
> suboptimal to force them to create git-shell-commands 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
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?
>>
>> The first step in that directi
>> 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 git-shell is
[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
Junio C Hamano wrote:
> Jonathan Nieder 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 direc
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 wrote:
> Ethan Reesor wrote:
>
>>That way, there's a default s
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:
I noticed a typo I made. I meant `git-config` rather than
`git-commit`. Sorry for my mistake.
On Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor wrote:
> On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:
>> Hmph, if that is the case, wouldn't it be a better direction to give
&g
t track, like GitHub does:
>
> Hi ! You've successfully authenticated, but
> GitHub does 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
shell-commands directory exists 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
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano 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?
&
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.
>
Jonathan Nieder 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
done = 0;
> + int done = 0, 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);
> +
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
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 pat
801 - 900 of 1049 matches
Mail list logo
