[PATCH v4 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

[Rasmus Villemoes]

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 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 83d25d825a..86a6b42345 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default 
for this
 purpose, but this can be overridden by other options or configuration
 variables.
 
+If an alias is given, git shows the definition of the alias on
+standard output. To get the manual page for the aliased command, use
+`git COMMAND --help`.
+
 Note that `git --help ...` is identical to `git help ...` because the
 former is internally converted into the latter.
 
-- 
2.19.1.4.g721af0fda3

[PATCH v3 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

[Rasmus Villemoes]

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 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 83d25d825a..86a6b42345 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default 
for this
 purpose, but this can be overridden by other options or configuration
 variables.
 
+If an alias is given, git shows the definition of the alias on
+standard output. To get the manual page for the aliased command, use
+`git COMMAND --help`.
+
 Note that `git --help ...` is identical to `git help ...` because the
 former is internally converted into the latter.
 
-- 
2.19.0

Re: [PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

[Rasmus Villemoes]

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`.
> 
> Funny English: "what it is an...". Maybe:
> 
>   If an alias is given, git shows the definition of the alias on
>   standard output. To get the manual page...

Much better, thanks.

Rasmus

Re: [PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

[Jeff King]

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 command.

Good idea.

> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
> index 83d25d825a..37e85868fd 100644
> --- a/Documentation/git-help.txt
> +++ b/Documentation/git-help.txt
> @@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default 
> for this
>  purpose, but this can be overridden by other options or configuration
>  variables.
>  
> +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`.

Funny English: "what it is an...". Maybe:

  If an alias is given, git shows the definition of the alias on
  standard output. To get the manual page...


-Peff

[PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

[Rasmus Villemoes]

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 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 83d25d825a..37e85868fd 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default 
for this
 purpose, but this can be overridden by other options or configuration
 variables.
 
+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`.
+
 Note that `git --help ...` is identical to `git help ...` because the
 former is internally converted into the latter.
 
-- 
2.19.0

Re: [PATCH] git help: promote 'git help -av'

[Taylor Blau]

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 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
> >> eyeballing tells me that the listing of external commands in -av
> >> output done in this patch seems reasonable.
> >>
> >> I do not think removing "-v" and making the current "help -a" output
> >> unavailable is a wise idea, though.
> >
> > I think that your point about having to react in a split-second in order
> > to ^C before we open the manual page for a command is a good one. So, I
> > agree with this.
>
> Responding to a wrong thread?

Ah, I certainly am. Thanks for catching my mistake :-).

> I thought "now I need ^C within a handful of deciseconds if I want
> only alias?" was not about the change to make "-v" default when
> "help -a" is asked, but about what to do with "git foo --help" that
> only gives "foo is aliased to ...".

Thanks,
Taylor

Re: [PATCH] git help: promote 'git help -av'

[Junio C Hamano]

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". Aliases are more
>> > subjective...
>>
>> I didn't apply this (so I didn't try running it), but a quick
>> eyeballing tells me that the listing of external commands in -av
>> output done in this patch seems reasonable.
>>
>> I do not think removing "-v" and making the current "help -a" output
>> unavailable is a wise idea, though.
>
> I think that your point about having to react in a split-second in order
> to ^C before we open the manual page for a command is a good one. So, I
> agree with this.

Responding to a wrong thread?  

I thought "now I need ^C within a handful of deciseconds if I want
only alias?" was not about the change to make "-v" default when
"help -a" is asked, but about what to do with "git foo --help" that
only gives "foo is aliased to ...".

Re: [PATCH] git help: promote 'git help -av'

[Taylor Blau]

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
> > subjective...
>
> I didn't apply this (so I didn't try running it), but a quick
> eyeballing tells me that the listing of external commands in -av
> output done in this patch seems reasonable.
>
> I do not think removing "-v" and making the current "help -a" output
> unavailable is a wise idea, though.

I think that your point about having to react in a split-second in order
to ^C before we open the manual page for a command is a good one. So, I
agree with this.

Thanks,
Taylor

Re: [PATCH] git help: promote 'git help -av'

[Junio C Hamano]

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
eyeballing tells me that the listing of external commands in -av
output done in this patch seems reasonable.

I do not think removing "-v" and making the current "help -a" output
unavailable is a wise idea, though.

Re: [PATCH] git help: promote 'git help -av'

[Junio C Hamano]

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 not like the new
default.

Unless you are removing code to show the current "help -a" output,
that is.

Re: [PATCH] git help: promote 'git help -av'

[Duy Nguyen]

On Tue, Sep 25, 2018 at 10:54 PM Jeff King  wrote:
> Mentioning aliases seems reasonable to me. The definitions of some of
> mine are pretty nasty bits of shell, but I guess that people either
> don't have any ugly aliases, or are comfortable enough with them that
> they won't be scared away. :)

I have one with a very long pretty format for git-log. Well, you wrote
your aliases you learn to live with them :) We could certainly cut too
long aliased commands to keep the listing pretty, but I don't think we
should do that until somebody asks for it.

> > -- 8< --
> > @@ -53,7 +52,6 @@ static struct option builtin_help_options[] = {
> >   HELP_FORMAT_WEB),
> >   OPT_SET_INT('i', "info", _format, N_("show info page"),
> >   HELP_FORMAT_INFO),
> > - OPT__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.

-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.
-- 
Duy

Re: [PATCH] git help: promote 'git help -av'

[Jeff King]

On Tue, Sep 25, 2018 at 07:44:51PM +0200, Duy Nguyen wrote:

> > I think adding another section about external commands in "help -av"
> > would address the "clang-format" stuff. With that, it's probably good
> > enough to completely replace "help -a". It may also be good to list
> > aliases there too in a separate section so you have "all you can type"
> > in one (big) list.
> 
> 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...

Just eyeballing the output, it looks pretty reasonable to me. The lack
of explanation for external commands really stands out, but there's not
much we can do.

That part of the output is not very compact, and we _could_ put it in
columns, but that might be confusing since the rest of the output is
one-per-line.

Mentioning aliases seems reasonable to me. The definitions of some of
mine are pretty nasty bits of shell, but I guess that people either
don't have any ugly aliases, or are comfortable enough with them that
they won't be scared away. :)

> -- 8< --
> @@ -53,7 +52,6 @@ static struct option builtin_help_options[] = {
>   HELP_FORMAT_WEB),
>   OPT_SET_INT('i', "info", _format, N_("show info page"),
>   HELP_FORMAT_INFO),
> - OPT__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

Re: [PATCH] git help: promote 'git help -av'

[Duy Nguyen]

  const char *exec_path = git_exec_path();
-   printf_ln(_("available git commands in '%s'"), exec_path);
-   putchar('\n');
-   pretty_print_cmdnames(main_cmds, colopts);
-   putchar('\n');
-   }
-
-   if (other_cmds->cnt) {
-   printf_ln(_("git commands available from elsewhere on your 
$PATH"));
-   putchar('\n');
-   pretty_print_cmdnames(other_cmds, colopts);
-   putchar('\n');
-   }
-}
-
 void list_common_cmds_help(void)
 {
puts(_("These are common Git commands used in various situations:"));
-   print_cmd_by_category(common_categories);
+   print_cmd_by_category(common_categories, NULL);
 }
 
 void list_all_main_cmds(struct string_list *list)
@@ -405,7 +369,7 @@ void list_common_guides_help(void)
{ CAT_guide, N_("The common Git guides are:") },
{ 0, NULL }
};
-   print_cmd_by_category(catdesc);
+   print_cmd_by_category(catdesc, NULL);
putchar('\n');
 }
 
@@ -494,9 +458,48 @@ void list_config_help(int for_human)
string_list_clear(, 0);
 }
 
+static int get_alias(const char *var, const char *value, void *data)
+{
+   struct string_list *list = data;
+
+   if (skip_prefix(var, "alias.", ))
+       string_list_append(list, var)->util = xstrdup(value);
+
+   return 0;
+}
+
 void list_all_cmds_help(void)
 {
-   print_cmd_by_category(main_categories);
+   struct string_list others = STRING_LIST_INIT_DUP;
+   struct string_list alias_list = STRING_LIST_INIT_DUP;
+   struct cmdname_help *aliases;
+   int i, longest;
+
+   printf_ln(_("See 'git help ' to read about a specific 
subcommand"));
+   print_cmd_by_category(main_categories, );
+
+   list_all_other_cmds();
+   if (others.nr)
+   printf("\n%s\n", _("External commands"));
+   for (i = 0; i < others.nr; i++)
+   printf("   %s\n", others.items[i].string);
+   string_list_clear(, 0);
+
+   git_config(get_alias, _list);
+   string_list_sort(_list);
+   if (alias_list.nr) {
+   printf("\n%s\n", _("Command aliases"));
+   ALLOC_ARRAY(aliases, alias_list.nr + 1);
+   for (i = 0; i < alias_list.nr; i++) {
+   aliases[i].name = alias_list.items[i].string;
+   aliases[i].help = alias_list.items[i].util;
+   aliases[i].category = 1;
+   }
+   aliases[alias_list.nr].name = NULL;
+   print_command_list(aliases, 1, longest);
+   free(aliases);
+   }
+   string_list_clear(_list, 1);
 }
 
 int is_in_cmdlist(struct cmdnames *c, const char *s)
diff --git a/help.h b/help.h
index 9eab6a3f89..105de6195a 100644
--- a/help.h
+++ b/help.h
@@ -37,7 +37,6 @@ extern void add_cmdname(struct cmdnames *cmds, const char 
*name, int len);
 /* Here we require that excludes is a sorted list. */
 extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes);
 extern int is_in_cmdlist(struct cmdnames *cmds, const char *name);
-extern void list_commands(unsigned int colopts, struct cmdnames *main_cmds, 
struct cmdnames *other_cmds);
 
 /*
  * call this to die(), when it is suspected that the user mistyped a
diff --git a/t/t0012-help.sh b/t/t0012-help.sh
index bc27df7f38..964615de2f 100755
--- a/t/t0012-help.sh
+++ b/t/t0012-help.sh
@@ -30,8 +30,7 @@ test_expect_success "setup" '
 test_expect_success 'basic help commands' '
git help >/dev/null &&
git help -a >/dev/null &&
-   git help -g >/dev/null &&
-   git help -av >/dev/null
+   git help -g >/dev/null
 '
 
 test_expect_success "works for commands and guides by default" '
-- 8< --

--
Duy

Re: [PATCH] git help: promote 'git help -av'

[Duy Nguyen]

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 do not think is available
> anywhere in "help -av", so I do not think "-av" can be promoted as
> an upward-compatible replacement in its current form.

Yep. I also thought "help -a" was denser but wasn't sure if it
actually helps or not. Whenever I look at that block of commands, I
end up searching anyway. For my use case, "help -a" could be better
served with something like "git apropos".

I think adding another section about external commands in "help -av"
would address the "clang-format" stuff. With that, it's probably good
enough to completely replace "help -a". It may also be good to list
aliases there too in a separate section so you have "all you can type"
in one (big) list.
--
Duy

Re: [PATCH] git help: promote 'git help -av'

[Junio C Hamano]

Jeff King  writes:

> I agree that "help -av" is likely to be more friendly. I kind of wonder
> if it should just be the default for "-a". Do we have any obligation not
> to change the format of that output?

I know that at least older versions of git-completion.bash (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.

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 do not think is available
anywhere in "help -av", so I do not think "-av" can be promoted as
an upward-compatible replacement in its current form.

I probably am not a part of the target audience, though.

Re: [PATCH] git help: promote 'git help -av'

[Jeff King]

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 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 with what is shown
> > > with "git help" since it shows list of commands with description as
> > > well, and commands are properly grouped.
> >
> > I agree that "help -av" is likely to be more friendly. I kind of wonder
> > if it should just be the default for "-a". Do we have any obligation not
> > to change the format of that output?
> 
> I agree, though I'd like to clarify what you said before doing so
> wholeheartedly.
> 
> Did you mean that all existing uses of 'git help -a' should instead mean
> 'git help -av' (i.e., that '-a' after your proposed patch means the same
> as '-av' in revisions prior to this one?)

Yes, exactly. I think the vast majority of uses would prefer the
categorized list.

The obvious exceptions are:

 - you can't remember the name of the command so an alphabetized list is
   easier for sifting through (without having to re-sift for each
   category).

 - you need a machine-readable version of the list (e.g., for
   programmable completion). We have "git --list-cmds", but we may need
   to advertise it better and mark it non-experimental.

I dunno. Maybe it is not worth the effort. Duy's existing patch is an
easy one liner. ;)

-Peff

Re: [PATCH] git help: promote 'git help -av'

[Taylor Blau]

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 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 with what is shown
> > with "git help" since it shows list of commands with description as
> > well, and commands are properly grouped.
>
> I agree that "help -av" is likely to be more friendly. I kind of wonder
> if it should just be the default for "-a". Do we have any obligation not
> to change the format of that output?

I agree, though I'd like to clarify what you said before doing so
wholeheartedly.

Did you mean that all existing uses of 'git help -a' should instead mean
'git help -av' (i.e., that '-a' after your proposed patch means the same
as '-av' in revisions prior to this one?)

If so, I agree. I can't imagine a case where I'd like to provide '-a'
and _not_ '-v', so certainly the later should come as a two-for-one
deal. Less, more well-intentioned knobs seems a positive trend to me, so
I am for this idea.

Thanks,
Taylor

Re: [PATCH] git help: promote 'git help -av'

[Jeff King]

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 help -g" for more details.
> 
> "git help -av" would be more friendly and inline with what is shown
> with "git help" since it shows list of commands with description as
> well, and commands are properly grouped.

I agree that "help -av" is likely to be more friendly. I kind of wonder
if it should just be the default for "-a". Do we have any obligation not
to change the format of that output?

Assuming we want to keep "-a" and "-av" as-is, your patch seems quite
sensible to me.

-Peff

Re: [PATCH] git help: promote 'git help -av'

[Duy Nguyen]

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 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 with what is shown
> > with "git help" since it shows list of commands with description as
> > well, and commands are properly grouped.
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy 
> > ---
> >  git.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/git.c b/git.c
> > index a6f4b44af5..69c21f378b 100644
> > --- a/git.c
> > +++ b/git.c
> > @@ -31,7 +31,7 @@ const char git_usage_string[] =
> >  "[]");
> >
> >  const char git_more_info_string[] =
> > - N_("'git help -a' and 'git help -g' list available subcommands and 
> > some\n"
> > + N_("'git help -av' and 'git help -g' list available subcommands and 
> > some\n"
> >  "concept guides. See 'git help ' or 'git help 
> > '\n"
> >  "to read about a specific subcommand or concept.");
>
> A side-effect of this not noted in your commit message is that we'll now
> invoke the pager, perhaps we should just do:
>
> diff --git a/builtin/help.c b/builtin/help.c
> index 8d4f6dd301..1a3b174aaf 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -436,9 +436,9 @@ int cmd_help(int argc, const char **argv, const char 
> *prefix)
> parsed_help_format = help_format;
>
> if (show_all) {
> +   setup_pager();
> git_config(git_help_config, NULL);
> if (verbose) {
> -   setup_pager();
> list_all_cmds_help();
> return 0;
> }
> @@ -460,8 +460,10 @@ int cmd_help(int argc, const char **argv, const char 
> *prefix)
> return 0;
> }
>
> -   if (show_guides)
> +   if (show_guides) {
> +   setup_pager();
> list_common_guides_help();
> +   }
>
> if (show_all || show_guides) {
> printf("%s\n", _(git_more_info_string));
>
> Or is there a good reason we shouldn't invoke the pager for e.g. -g when
> the terminal is too small (per our default less config)?

Different pagers may behave differently (and so far "help -a" still
fits in my screen). So I don't think we should invoke pager more than
necessary.
-- 
Duy

Re: [PATCH] git help: promote 'git help -av'

[Ævar Arnfjörð Bjarmason]

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 details.
>
> "git help -av" would be more friendly and inline with what is shown
> with "git help" since it shows list of commands with description as
> well, and commands are properly grouped.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  git.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git.c b/git.c
> index a6f4b44af5..69c21f378b 100644
> --- a/git.c
> +++ b/git.c
> @@ -31,7 +31,7 @@ const char git_usage_string[] =
>  "[]");
>
>  const char git_more_info_string[] =
> - N_("'git help -a' and 'git help -g' list available subcommands and 
> some\n"
> + N_("'git help -av' and 'git help -g' list available subcommands and 
> some\n"
>  "concept guides. See 'git help ' or 'git help '\n"
>  "to read about a specific subcommand or concept.");

A side-effect of this not noted in your commit message is that we'll now
invoke the pager, perhaps we should just do:

diff --git a/builtin/help.c b/builtin/help.c
index 8d4f6dd301..1a3b174aaf 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -436,9 +436,9 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
parsed_help_format = help_format;

if (show_all) {
+   setup_pager();
git_config(git_help_config, NULL);
if (verbose) {
-   setup_pager();
list_all_cmds_help();
return 0;
}
@@ -460,8 +460,10 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
return 0;
}

-   if (show_guides)
+   if (show_guides) {
+   setup_pager();
list_common_guides_help();
+   }

if (show_all || show_guides) {
printf("%s\n", _(git_more_info_string));

Or is there a good reason we shouldn't invoke the pager for e.g. -g when
the terminal is too small (per our default less config)?

Another thing I noticed: We don't list -v in the git-help manpage, but
since we use OPT_VERBOSE it's supported.

[PATCH] git help: promote 'git help -av'

[Nguyễn Thái Ngọc Duy]

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 with what is shown
with "git help" since it shows list of commands with description as
well, and commands are properly grouped.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 git.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git.c b/git.c
index a6f4b44af5..69c21f378b 100644
--- a/git.c
+++ b/git.c
@@ -31,7 +31,7 @@ const char git_usage_string[] =
   "        []");
 
 const char git_more_info_string[] =
-   N_("'git help -a' and 'git help -g' list available subcommands and 
some\n"
+   N_("'git help -av' and 'git help -g' list available subcommands and 
some\n"
   "concept guides. See 'git help ' or 'git help '\n"
   "to read about a specific subcommand or concept.");
 
-- 
2.19.0.647.gb9a6049235

Re: Git Help !!!

[Vishwas Kamath]

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 Google as well i am directly contacting you as i need to get
> git working. Hope you can help me.
>
> It looks like you're experiencing a problem specific to Windows or the
> to Windows version of Git which is maintained as a separate
> project[1]. You may be able to get help for this specific problem on
> the project's mailing list[2] or by submitting a bug report[3].
>
> [1]: https://gitforwindows.org
> [2]: https://groups.google.com/forum/#!forum/git-for-windows
> [3]: https://github.com/git-for-windows/git/issues
>

Re: Git Help !!!

[Eric Sunshine]

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. Hope you can help me.

It looks like you're experiencing a problem specific to Windows or the
to Windows version of Git which is maintained as a separate
project[1]. You may be able to get help for this specific problem on
the project's mailing list[2] or by submitting a bug report[3].

[1]: https://gitforwindows.org
[2]: https://groups.google.com/forum/#!forum/git-for-windows
[3]: https://github.com/git-for-windows/git/issues

Fwd: Git Help !!!

[Vishwas Kamath]

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 regarding my problem

kind regards

vishwas

Re: git help clone: questions

[kalle]

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 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 some reason, please say "I think X
>>> should be Y BECAUSE Z" instead.  Without stating why you think
>>> differently from what those who wrote the current text, it is hard
>>> for people to respond either with "Yeah, you're right---I agree
>>> with Z" or with "No, Z does not hold because..."
>>>
>> 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
>> ".
> 
> I do not have particularly a strong opinion, but I think it is very
> sensible to call the value given to the option "--reference" with a
> phrase that is not just "repository".
i agree and didn't state this. i proposed to add .
 could also be named .
> 
> As the command line of "clone" must name one repository (i.e. the
> one which we clone from), and its "--reference" option must name
> another repository as its value (i.e. the one that we borrow from in
> order to reduce the object transfer), calling both 
> makes it easier to confuse readers

you made my point

 unless the writer carefully makes
> sure that  in the desription is unambiguous and it is
> clear which one of these two repositories is being discussed by the
> context.>
> I just re-read the existing Documentation/git-clone.txt and looked
> for "reference".  All uses of "reference repository" in the prose
> made sense and I found it would not be an improvement if any of them
> is replaced with just "repository". 

This was never my proposal, though.

 It may be helpful to add
> something like:
> 
>--reference[-if-able] ::
>   +   Define a repository (reference repository) to borrow
>   +   objects from.  
>   If the reference repository is on the local machine,
>   ...
> 
> to define which repository we mean by that term, though.
> 

in all, it was just meant as a quite small proposal for me. i also don't
have any strong opinion about it.
greetings,
kalle

Re: git help clone: questions

[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 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 some reason, please say "I think X
>> should be Y BECAUSE Z" instead.  Without stating why you think
>> differently from what those who wrote the current text, it is hard
>> for people to respond either with "Yeah, you're right---I agree
>> with Z" or with "No, Z does not hold because..."
>> 
> 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
> ".

I do not have particularly a strong opinion, but I think it is very
sensible to call the value given to the option "--reference" with a
phrase that is not just "repository".

As the command line of "clone" must name one repository (i.e. the
one which we clone from), and its "--reference" option must name
another repository as its value (i.e. the one that we borrow from in
order to reduce the object transfer), calling both 
makes it easier to confuse readers unless the writer carefully makes
sure that  in the desription is unambiguous and it is
clear which one of these two repositories is being discussed by the
context.

I just re-read the existing Documentation/git-clone.txt and looked
for "reference".  All uses of "reference repository" in the prose
made sense and I found it would not be an improvement if any of them
is replaced with just "repository".  It may be helpful to add
something like:

 --reference[-if-able] ::
+   Define a repository (reference repository) to borrow
+   objects from.  
If the reference repository is on the local machine,
...

to define which repository we mean by that term, though.

Re: git help clone: questions

[kalle]

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 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, the current one is fine." without any explanation.
> 
> If you think X should be Y for some reason, please say "I think X
> should be Y BECAUSE Z" instead.  Without stating why you think
> differently from what those who wrote the current text, it is hard
> for people to respond either with "Yeah, you're right---I agree
> with Z" or with "No, Z does not hold because..."
> 

Re: git help clone: questions

[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, the current one is fine." without any explanation.

If you think X should be Y for some reason, please say "I think X
should be Y BECAUSE Z" instead.  Without stating why you think
differently from what those who wrote the current text, it is hard
for people to respond either with "Yeah, you're right---I agree
with Z" or with "No, Z does not hold because..."

git help clone: questions

[kalle]

-In the explanation of the option --reference: shouldn't there be
written '' instead of  'reference repository'?

greetings,
kalle

missing entries in "git help repository-layout"

[Robert P. J. Day]

  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 supposed to be so it's entirely possible that these
omissions are deliberate:

  - ORIG_HEAD
  - FETCH_HEAD
  - description
  - gitk.cache
  - refs/
bisect
stash
  - logs/
HEAD
refs/
stash
remotes
  - worktrees//
commondir
HEAD
index
logs
ORIG_HEAD

  as i said, i have no idea whether the entries above are deliberately
omitted from the layout page, i just made a list of them.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: `git help svn` missing description of `propset`

[Alfred Perlstein]

Eric,

Would love to contribute more to git!  I'm in the middle of a major 
product launch, so I can do this next week.  Of course no hard feelings 
will be had if someone else wants to do it.  I'm making myself a 
calendar invite to remind myself right now.


I'll ping y'all 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 <pecor...@apple.com> 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 Subversion repository about a 
given file or directory.
 Use -r/--revision to refer to a specific Subversion revision.
 
 propget

 Gets the Subversion property given as the first argument, for a 
file. A specific revision
 can be specified with -r/--revision.
 ...


Interestingly, the generic `git svn` help does mention `propset`.


 $ git svn
 ...
   propget  Print the value of a property on a file or directory
  --revision, -r 
   proplist List all properties of a file or directory
  --revision, -r 
   propset  Set the value of a property on a file or directory - 
will be set on commit
 ...
   
It seems Documentation/git-svn.txt is missing text for `propset`.

Thanks Joseph, indeed it is missing from the manpage.

Alfred / David: either of you have a few cycles to spare to write
a manpage entry for this feature you worked on?

If not, let us know, too, so others can work on it.  Thanks.



--
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

Re: `git help svn` missing description of `propset`

[Eric Wong]

+Cc Alfred, David

Joseph Pecoraro <pecor...@apple.com> 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 Subversion repository about a 
> given file or directory.
> Use -r/--revision to refer to a specific Subversion revision.
> 
> propget
> Gets the Subversion property given as the first argument, for a 
> file. A specific revision
> can be specified with -r/--revision.
> ...
> 
> 
> Interestingly, the generic `git svn` help does mention `propset`.
> 
> 
> $ git svn
> ...
>   propget  Print the value of a property on a file or directory
>  --revision, -r 
>   proplist List all properties of a file or directory
>  --revision, -r 
>   propset  Set the value of a property on a file or directory - 
> will be set on commit
> ...
>   
> It seems Documentation/git-svn.txt is missing text for `propset`.

Thanks Joseph, indeed it is missing from the manpage.

Alfred / David: either of you have a few cycles to spare to write
a manpage entry for this feature you worked on?

If not, let us know, too, so others can work on it.  Thanks.
--
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

`git help svn` missing description of `propset`

[Joseph Pecoraro]

`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 to refer to a specific Subversion revision.

propget
Gets the Subversion property given as the first argument, for a 
file. A specific revision
can be specified with -r/--revision.
...


Interestingly, the generic `git svn` help does mention `propset`.


$ git svn
...
  propget  Print the value of a property on a file or directory
 --revision, -r 
  proplist List all properties of a file or directory
 --revision, -r 
  propset  Set the value of a property on a file or directory - 
will be set on commit
...
  
It seems Documentation/git-svn.txt is missing text for `propset`.

- Joe--
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

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

[Junio C Hamano]

"Philip Oakley" <philipoak...@iee.org> 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 --all) already determines the list of commands
> available, but then formats it prettily for user consumption. Maybe an
> alternate --list option?

Yes, that is exactly what I meant.
--
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

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

[Philip Oakley]

From: "Junio C Hamano" <gits...@pobox.com>

Ralf Thielow <ralf.thie...@gmail.com> writes:


Signed-off-by: Ralf Thielow <ralf.thie...@gmail.com>
---
 contrib/completion/git-completion.bash | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


It is somewhat silly that we have to maintain this list to be in
sync with the set of documents we offer.  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.


'git help -a' (or --all) already determines the list of commands available, 
but then formats it prettily for user consumption. Maybe an alternate --list 
option?




But this change itself is not wrong per-se; will queue to see where
follow-up discussion will lead us to.

Thanks.


diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash

index 70f4171..ffe6004 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1346,8 +1346,8 @@ _git_help ()
 __git_compute_all_commands
 __gitcomp "$__git_all_commands $(__git_aliases)
 attributes cli core-tutorial cvs-migration
- diffcore gitk glossary hooks ignore modules
- namespaces repository-layout tutorial tutorial-2
+ diffcore everyday gitk glossary hooks ignore modules
+ namespaces repository-layout revisions tutorial tutorial-2
 workflows
 "
 }

--
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



--
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

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

[Junio C Hamano]

Ralf Thielow <ralf.thie...@gmail.com> writes:

> Signed-off-by: Ralf Thielow <ralf.thie...@gmail.com>
> ---
>  contrib/completion/git-completion.bash | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

It is somewhat silly that we have to maintain this list to be in
sync with the set of documents we offer.  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.

But this change itself is not wrong per-se; will queue to see where
follow-up discussion will lead us to.

Thanks.


> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index 70f4171..ffe6004 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1346,8 +1346,8 @@ _git_help ()
>   __git_compute_all_commands
>   __gitcomp "$__git_all_commands $(__git_aliases)
>   attributes cli core-tutorial cvs-migration
> - diffcore gitk glossary hooks ignore modules
> - namespaces repository-layout tutorial tutorial-2
> + diffcore everyday gitk glossary hooks ignore modules
> + namespaces repository-layout revisions tutorial tutorial-2
>   workflows
>   "
>  }
--
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

Re: [PATCH 1/2] completion: add option '--guides' to 'git help'

[Junio C Hamano]

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 e3918c8..70f4171 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1339,7 +1339,7 @@ _git_help ()
>  {
>   case "$cur" in
>   --*)
> - __gitcomp "--all --info --man --web"
> + __gitcomp "--all --guides --info --man --web"
>   return
>   ;;
>   esac
--
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

[PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

[Ralf Thielow]

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.bash
+++ b/contrib/completion/git-completion.bash
@@ -1346,8 +1346,8 @@ _git_help ()
__git_compute_all_commands
__gitcomp "$__git_all_commands $(__git_aliases)
attributes cli core-tutorial cvs-migration
-   diffcore gitk glossary hooks ignore modules
-   namespaces repository-layout tutorial tutorial-2
+   diffcore everyday gitk glossary hooks ignore modules
+   namespaces repository-layout revisions tutorial tutorial-2
workflows
"
 }
-- 
2.8.0.rc4.7.g35d7ca9.dirty

--
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

[PATCH 0/2] completion: git-help: add missing option and params

[Ralf Thielow]

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 'git help'

 contrib/completion/git-completion.bash | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.8.0.rc4.7.g35d7ca9.dirty

--
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

[PATCH 1/2] completion: add option '--guides' to 'git help'

[Ralf Thielow]

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
+++ b/contrib/completion/git-completion.bash
@@ -1339,7 +1339,7 @@ _git_help ()
 {
case "$cur" in
--*)
-   __gitcomp "--all --info --man --web"
+   __gitcomp "--all --guides --info --man --web"
return
;;
esac
-- 
2.8.0.rc4.7.g35d7ca9.dirty

--
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

Re: [PATCH v7 0/5] git help: group common commands by theme

[Junio C Hamano]

Eric Sunshine sunsh...@sunshineco.com 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 isn't held hostage by those
 separate topics.

Not a big deal in this case, as I was very well aware that there was
a preparatory change sent, so no harm done to me personally; I even
asked Sébastien to rebuild on top of that patch.

For people who are helping to review the series but haven't paid
attention to everything that was said on the list (read: almost all
the people), it would have been better if it said depends on
bf990a2, instead of saying that it depends on the 'next' as a whole
(which it doesn't).

Thanks.



--
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

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

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 to be used to recompile, what parameter 
settings they need to do, etc.  IBM team told it is easy to recompile if they 
have provided with the details.

Could you please help us to provide additional details for compilation. Thanks 
in advance.

Regards,
Ravi.

-Original Message-
From: Ravi Kiran Goud Palpanoori 
Sent: Friday, August 01, 2014 5:03 PM
To: 'brian m. carlson'
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: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git Help needed

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/
Google Code no longer allows anyone to upload tarballs.

 Does it mean the package available at above location has built with 
 specific version of OpenSSL. How can I find out which OpenSSL version 
 is used in the packages available at the above location.

If you're downloading the source tarball and building it yourself, then it's 
whatever version of OpenSSL is on your system.  To my knowledge, nobody 
provides pre-built packages of git for AIX.

 Could you please suggest the site from where I need to download git 
 for AIX OS.

As I mentioned above, you'll probably need to build it yourself.

 Who are the vendors of git so that I will check how to proceed on this.

When I referred to having your vendor patch the check out, I meant your vendor 
of OpenSSL.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
--
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

Re: Git Help needed

[brian m. carlson]

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 to be used to
 recompile, what parameter settings they need to do, etc.  IBM team
 told it is easy to recompile if they have provided with the details.
 
 Could you please help us to provide additional details for
 compilation. Thanks in advance.

I don't have any more information than this, but I believe Debian and
Red Hat have patched that check out.  Any reasonable developer should be
able to discover the check and remove it.

This is getting off-topic for the list, so I recommend you discuss it
with IBM or simply recompile Git for the new version of OpenSSL, as this
really isn't a Git issue.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [PATCH v4 0/3] Make 'git help everyday' work

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

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
Philip
--
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

[PATCH v4 3/3] Make 'git help everyday' work

[Philip Oakley]

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.

giteveryday.txt now formats well with AsciiDoc as a man page and
refreshed content to a more command modern style.

Add 'everyday' to the help --guides list and update git(1) and 5
other links to giteveryday.

Signed-off-by: Philip Oakley philipoak...@iee.org
---
 Documentation/Makefile |   3 +-
 Documentation/everyday.txt | 455 -
 Documentation/everyday.txto|   9 +
 Documentation/git-push.txt |   2 +-
 Documentation/git.txt  |   4 +-
 Documentation/gitcore-tutorial.txt |   2 +-
 Documentation/gitcvs-migration.txt |   2 +-
 Documentation/giteveryday.txt  | 455 +
 Documentation/gitglossary.txt  |   2 +-
 Documentation/gittutorial-2.txt|   4 +-
 Documentation/gittutorial.txt  |   4 +-
 README |   2 +-
 builtin/help.c |   1 +
 13 files changed, 478 insertions(+), 467 deletions(-)
 delete mode 100644 Documentation/everyday.txt
 create mode 100644 Documentation/everyday.txto
 create mode 100644 Documentation/giteveryday.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3b56714..8d0f709 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -27,6 +27,7 @@ MAN7_TXT += gitcore-tutorial.txt
 MAN7_TXT += gitcredentials.txt
 MAN7_TXT += gitcvs-migration.txt
 MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += giteveryday.txt
 MAN7_TXT += gitglossary.txt
 MAN7_TXT += gitnamespaces.txt
 MAN7_TXT += gitrevisions.txt
@@ -38,11 +39,11 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
 MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT))
 MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT))
 
+OBSOLETE_HTML += everyday.html
 OBSOLETE_HTML += git-remote-helpers.html
 DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML)
 
 ARTICLES += howto-index
-ARTICLES += everyday
 ARTICLES += git-tools
 ARTICLES += git-bisect-lk2009
 # with their own formatting rules.
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
deleted file mode 100644
index 97cecce..000
--- a/Documentation/everyday.txt
+++ /dev/null
@@ -1,455 +0,0 @@
-giteveryday(7)
-===
-
-NAME
-
-giteveryday - A useful minimum set of commands for Everyday Git
-
-SYNOPSIS
-
-
-Everyday Git With 20 Commands Or So
-
-DESCRIPTION

-
-Git users can broadly be grouped into four categories for the purposes of
-describing here a small set of useful command for everyday Git.
-
-*  STANDALONE,Individual Developer (Standalone) commands are essential
-   for anybody who makes a commit, even for somebody who works alone.
-
-*  If you work with other people, you will need commands listed in
-   the PARTICIPANT,Individual Developer (Participant) section as well.
-
-*  People who play the INTEGRATOR,Integrator role need to learn some
-   more commands in addition to the above.
-
-*  ADMINISTRATION,Repository Administration commands are for system
-   administrators who are responsible for the care and feeding
-   of Git repositories.
-
-
-Individual Developer (Standalone)[[STANDALONE]]

-
-A standalone individual developer does not exchange patches with
-other people, and works alone in a single repository, using the
-following commands.
-
-  * linkgit:git-init[1] to create a new repository.
-
-  * linkgit:git-log[1] to see what happened.
-
-  * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
-branches.
-
-  * linkgit:git-add[1] to manage the index file.
-
-  * linkgit:git-diff[1] and linkgit:git-status[1] to see what
-you are in the middle of doing.
-
-  * linkgit:git-commit[1] to advance the current branch.
-
-  * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
-pathname parameters) to undo changes.
-
-  * linkgit:git-merge[1] to merge between local branches.
-
-  * linkgit:git-rebase[1] to maintain topic branches.
-
-  * linkgit:git-tag[1] to mark a known point.
-
-Examples
-
-
-Use a tarball as a starting point for a new repository.::
-+
-
-$ tar zxf frotz.tar.gz
-$ cd frotz
-$ git init
-$ git add . 1
-$ git commit -m import of frotz source tree.
-$ git tag v2.43 2
-
-+
-1 add everything under the current directory.
-2 make a lightweight, unannotated tag.
-
-Create a topic branch and develop.::
-+
-
-$ git checkout -b alsa-audio 1
-$ edit/compile/test
-$ git checkout -- curses/ux_audio_oss.c 2
-$ git add curses/ux_audio_alsa.c 3
-$ edit/compile/test
-$ git diff HEAD 4
-$ git commit -a -s 5
-$ edit/compile/test
-$ git diff HEAD^ 6
-$ git commit -a --amend 7
-$ git checkout master 8
-$ git merge alsa-audio 9
-$ git log --since='3 days

[PATCH v4 0/3] Make 'git help everyday' work

[Philip Oakley]

This is hopefully the final revision of the patch...
and integrates Junio's comments. 

I've eye-balled the man page and web page results, and corrected a few quote / 
back tick
items to be more consistent.

Re: [PATCH v3 1/3] doc: modernise everyday.txt wording and format in man page 
style
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, September 30, 2014 12:24 AM
Subject: Re: [PATCH v3 1/3] doc: modernise everyday.txt wording and format in 
man page style
 Philip Oakley philipoak...@iee.org writes:
 
 @@ -45,7 +58,7 @@ following commands.
  
* linkgit:git-rebase[1] to maintain topic branches.
  
 -  * linkgit:git-tag[1] to mark known point.
 +  * linkgit:git-tag[1] to mark a known point.
 
 I really appreciate your attention to details here.
 
 +10 review commit logs; other forms to limit output can be
  combined and include `--max-count=10` (show 10 commits),
  `--until=2005-12-10`, etc.
 
 s/--max-count=//; perhaps?
I've shown both in the update, as it's a help guide. How does it look?

 
 @@ -131,27 +145,34 @@ Clone the upstream and work on it.  Feed changes to 
 upstream.::
  
  $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
  $ cd my2.6
 +$ git checkout -b mine master 1
 +$ edit/compile/test; git commit -a -s 2
 +$ git format-patch master 3
 +$ git send-email --to=person em...@example.com 00*.patch 4
 +$ git pull 5
 
 This may be found somewhat questionable by some people, as mine
 does not build on the master at origin.  Insert git checkout master
 before this step to cause 5 update the pristine copy of their
 master, perhaps?  That way, the next step
I'd misunderstood this initially (confusion as to build start point).
I've added the checkout with a comment, and renumber those following.

 
 +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 6
 
 starts making more sense.
 
 +$ git fetch --tags 11
 ...
 +11 from time to time, obtain official tags from the `origin`
  and store them under `.git/refs/tags/`.
 
 I am not sure if fetch --tags still needs to be taught, especially
 in a quick guide document, because fetch has auto-followed
 relevant tags for a long time since the original version of this
 document was written.
Done - removed.

 
 +3 arrange `git push` to push all local branches to
 +their corresponding branch of the mothership machine.
 +4 push will stash all our work away on `remotes/satellite/*`
 +remote-tracking branches on the mothership machine.  You could use this
  as a back-up method.
 
 The original mentions a back-up method, but a larger benefit of
 this kind of settings is that it lets you pretend that mothership
 fetched from you.
 
 We may want to say You can use this to pretend as if the origin,
 aka mothership, ran 'git fetch' from you, aka satellite.  This is
 especially true because the next step 5 is about how to integrate
 your work done on 'satellite' into 'mothership' that cannot fetch
 from 'satellite' (imagine satellite is behind a NAT and it can only
 ssh out to mothership but not the other way around).
Text updated to include those points.

 
 -Integrator[[Integrator]]
 +Integrator[[INTEGRATOR]]
  
  
  A fairly central person acting as the integrator in a group
 @@ -213,6 +235,9 @@ project receives changes made by others, reviews and 
 integrates
  them and publishes the result for others to use, using these
  commands in addition to the ones needed by participants.
  
 +This section can also be applied to a git-request-pull workflow,
 +or the GitHub (www.github.com) pull-request flow.
 
 Clarify which end of that workflow this can be applied, perhaps?
 E.g. ... also be used by the person who responds to 'git
 request-pull' or pull-request on GitHub to integrate others' work
 into your history.
Sorted, as below.

 
 
 @@ -225,23 +250,26 @@ commands in addition to the ones needed by 
 participants.
  
* linkgit:git-push[1] to publish the bleeding edge.
  
 +  * linkgit:git-request-pull[1] to create 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.
 
 Yes, I know a sub-area lieutenant would request a pull by the
 top-level maintainer, but when you interact with your 'upstream',
 you are not acting as an integrator.
 
 If you really want to add request-pull to common 20-or-so commands,
 it would make more sense to do so in the participant's section and
 to explain that an sub-area lieutenant acts both as a participant
 and as an integrator.
Added text in line with your comment.

 
 Thanks.

--

Philip Oakley (3):
  doc: modernise everyday.txt wording and format in man page style
  doc: Makefile regularise OBSOLETE_HTML list building
  Make 'git help everyday' work

 Documentation/Makefile |   6 +-
 Documentation/everyday.txt | 413

Re: [PATCH v4 0/3] Make 'git help everyday' work

[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.
--
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

[PATCH v3 3/3] Make 'git help everyday' work

[Philip Oakley]

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.

giteveryday.txt now formats well with AsciiDoc as a man page and
refreshed content to a more command modern style.

Add 'everyday' to the help --guides list and update git(1) and 5
other links to giteveryday.

Signed-off-by: Philip Oakley philipoak...@iee.org
---
 Documentation/Makefile |   3 +-
 Documentation/everyday.txt | 447 -
 Documentation/everyday.txto|   9 +
 Documentation/git-push.txt |   2 +-
 Documentation/git.txt  |   4 +-
 Documentation/gitcore-tutorial.txt |   2 +-
 Documentation/gitcvs-migration.txt |   2 +-
 Documentation/giteveryday.txt  | 447 +
 Documentation/gitglossary.txt  |   2 +-
 Documentation/gittutorial-2.txt|   4 +-
 Documentation/gittutorial.txt  |   4 +-
 README |   2 +-
 builtin/help.c |   1 +
 13 files changed, 470 insertions(+), 459 deletions(-)
 delete mode 100644 Documentation/everyday.txt
 create mode 100644 Documentation/everyday.txto
 create mode 100644 Documentation/giteveryday.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3b56714..8d0f709 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -27,6 +27,7 @@ MAN7_TXT += gitcore-tutorial.txt
 MAN7_TXT += gitcredentials.txt
 MAN7_TXT += gitcvs-migration.txt
 MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += giteveryday.txt
 MAN7_TXT += gitglossary.txt
 MAN7_TXT += gitnamespaces.txt
 MAN7_TXT += gitrevisions.txt
@@ -38,11 +39,11 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
 MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT))
 MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT))
 
+OBSOLETE_HTML += everyday.html
 OBSOLETE_HTML += git-remote-helpers.html
 DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML)
 
 ARTICLES += howto-index
-ARTICLES += everyday
 ARTICLES += git-tools
 ARTICLES += git-bisect-lk2009
 # with their own formatting rules.
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
deleted file mode 100644
index cd7f87c..000
--- a/Documentation/everyday.txt
+++ /dev/null
@@ -1,447 +0,0 @@
-giteveryday(7)
-===
-
-NAME
-
-giteveryday - A useful minimum set of commands for Everyday Git
-
-SYNOPSIS
-
-
-Everyday Git With 20 Commands Or So
-
-DESCRIPTION

-
-Git users can broadly be grouped into four categories for the purposes of
-describing here a small set of useful command for everyday Git.
-
-*  STANDALONE,Individual Developer (Standalone) commands are essential
-   for anybody who makes a commit, even for somebody who works alone.
-
-*  If you work with other people, you will need commands listed in
-   the PARTICIPANT,Individual Developer (Participant) section as well.
-
-*  People who play the INTEGRATOR,Integrator role need to learn some
-   more commands in addition to the above.
-
-*  ADMINISTRATION,Repository Administration commands are for system
-   administrators who are responsible for the care and feeding
-   of Git repositories.
-
-
-Individual Developer (Standalone)[[STANDALONE]]

-
-A standalone individual developer does not exchange patches with
-other people, and works alone in a single repository, using the
-following commands.
-
-  * linkgit:git-init[1] to create a new repository.
-
-  * linkgit:git-log[1] to see what happened.
-
-  * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
-branches.
-
-  * linkgit:git-add[1] to manage the index file.
-
-  * linkgit:git-diff[1] and linkgit:git-status[1] to see what
-you are in the middle of doing.
-
-  * linkgit:git-commit[1] to advance the current branch.
-
-  * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
-pathname parameters) to undo changes.
-
-  * linkgit:git-merge[1] to merge between local branches.
-
-  * linkgit:git-rebase[1] to maintain topic branches.
-
-  * linkgit:git-tag[1] to mark a known point.
-
-Examples
-
-
-Use a tarball as a starting point for a new repository.::
-+
-
-$ tar zxf frotz.tar.gz
-$ cd frotz
-$ git init
-$ git add . 1
-$ git commit -m import of frotz source tree.
-$ git tag v2.43 2
-
-+
-1 add everything under the current directory.
-2 make a lightweight, unannotated tag.
-
-Create a topic branch and develop.::
-+
-
-$ git checkout -b alsa-audio 1
-$ edit/compile/test
-$ git checkout -- curses/ux_audio_oss.c 2
-$ git add curses/ux_audio_alsa.c 3
-$ edit/compile/test
-$ git diff HEAD 4
-$ git commit -a -s 5
-$ edit/compile/test
-$ git diff HEAD^ 6
-$ git commit -a --amend 7
-$ git checkout master 8
-$ git merge alsa-audio 9
-$ git log --since='3 days

[PATCH v3 0/3] Make 'git help everyday' work

[Philip Oakley]

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 make file, in line
with the currently queued version on pu.

Finally patch 3 swaps over the everyday.txt to the giteveryday.txt accessible
through the regular help system, and changes over all the links.

This follows from :
Subject: What's cooking in git.git (Sep 2014, #06; Wed, 24)
[...]
 * po/everyday-doc (2014-01-27) 1 commit
 - Make 'git help everyday' work
 
 This may make the said command to emit something, but the source is
 not meant to be formatted into a manual pages to begin with, and
 also its contents are a bit stale.  It may be a good first step in
 the right direction, but needs more work to at least get the
 mark-up right before public consumption.
 
 Waiting for a reroll (thread ending at $gmane/254746)
 

Philip

[1] http://thread.gmane.org/gmane.comp.version-control.git/240286
 [PATCH 0/6] Make 'git help everyday' work
[2] http://thread.gmane.org/gmane.comp.version-control.git/240354
 [PATCH v2] Make 'git help everyday' work

Philip Oakley (3):
  doc: modernise everyday.txt wording and format in man page style
  doc: Makefile regularise OBSOLETE_HTML list building
  Make 'git help everyday' work

 Documentation/Makefile |   6 +-
 Documentation/everyday.txt | 413 --
 Documentation/everyday.txto|   9 +
 Documentation/git-push.txt |   2 +-
 Documentation/git.txt  |   4 +-
 Documentation/gitcore-tutorial.txt |   2 +-
 Documentation/gitcvs-migration.txt |   2 +-
 Documentation/giteveryday.txt  | 447 +
 Documentation/gitglossary.txt  |   2 +-
 Documentation/gittutorial-2.txt|   4 +-
 Documentation/gittutorial.txt  |   4 +-
 README |   2 +-
 builtin/help.c |   1 +
 13 files changed, 472 insertions(+), 426 deletions(-)
 delete mode 100644 Documentation/everyday.txt
 create mode 100644 Documentation/everyday.txto
 create mode 100644 Documentation/giteveryday.txt

-- 
1.9.4.msysgit.0

--
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

Git Help needed

[RaviKiranGoud_Palpanoori]

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.3 or GIT 1.9.0

2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
able to extract code from git repository directly as well as from ant. 
Everything went well.
Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
are not working. Basic help and version works fine as expected. When I try to 
pull the code from git repository it give SSL 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. 
When I tried directly pulling code using git pull command - didn't work.
When I try to pull the code through the ant - didn't work

The ant version is 1.8.0RC1

AIX admin worked on this and provided below comments

Comments form AIX system admin  (Pasted as it is)
Even after installing 1.9.0 version of GIT the library files are not compatible 
with the latest version of SSL (1.0.5.1).
SSL works fine as a root user and other users. This compatibility issue only a 
raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH from 
the same location as GIT and this causes the incompatibility.
Can you find out from the GIT/ANT support team on what version of SSL GIT 
supports exactly. - The is specifically with the GIT/SSL as the user xyzabc . 
The SSL otherwise works perfectly fine.
You will have to re-compile the ANT libraries to use the latest library files.

Thanks in advance.

Regards,
Ravi.
--
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

Re: Git Help needed

[Ronnie Sahlberg]

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 against the version that the new version of
aix ships with.

Alternatively if you build git yourself on that host you should end up
with a binary that links with the version of the library that you
currently have.



On Fri, Aug 1, 2014 at 12:30 PM,  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.3 or GIT 1.9.0

 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
 able to extract code from git repository directly as well as from ant. 
 Everything went well.
 Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
 are not working. Basic help and version works fine as expected. When I try to 
 pull the code from git repository it give SSL 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.
 When I tried directly pulling code using git pull command - didn't work.
 When I try to pull the code through the ant - didn't work

 The ant version is 1.8.0RC1

 AIX admin worked on this and provided below comments

 Comments form AIX system admin  (Pasted as it is)
 Even after installing 1.9.0 version of GIT the library files are not 
 compatible with the latest version of SSL (1.0.5.1).
 SSL works fine as a root user and other users. This compatibility issue only 
 a raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH 
 from the same location as GIT and this causes the incompatibility.
 Can you find out from the GIT/ANT support team on what version of SSL GIT 
 supports exactly. - The is specifically with the GIT/SSL as the user xyzabc 
 . The SSL otherwise works perfectly fine.
 You will have to re-compile the ANT libraries to use the latest library files.

 Thanks in advance.

 Regards,
 Ravi.
 --
 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
--
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

Re: Git Help needed

[brian m. carlson]

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.3 or GIT 1.9.0

The INSTALL file doesn't mention a particular OpenSSL version that we
require, but I know that it works with versions as old as 0.9.8 and as
new as 1.0.1g.  It may work with still older versions, but I recommend
1.0.1 or newer as it gives you proper TLS 1.2 support.

 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked
 fine and able to extract code from git repository directly as well as
 from ant. Everything went well.
 Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git
 commands are not working. Basic help and version works fine as
 expected. When I try to pull the code from git repository it give SSL
 library compatibility issue.
 
 The error is 
 OpenSSL version mismatch. Built agains 1000105f, you have 10bf
 fatal: Could not read from remote repository

OpenSSL 1.0.0 (which you were using before) and OpenSSL 1.0.1 are binary
compatible if compiled with the same flags, but they contain a hard
version check that fails if they're not the same version.

This means you need to recompile git against the newer OpenSSL version,
or ask your vendor to patch this check out.  This is true for any
program that gives you this error.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

Hi Ronnie Sahlberg,
Thanks for your quick reply.

I downloaded git 1.9.0 from the site 
https://code.google.com/p/git-core/downloads/list.
Does it mean the package available at above location has issue? OR
The person  who built/installed git in AIX sever did something wrong by 
building it against a specific OpenSSL library


Could you please suggest the site from where I need to download git for AIX OS.

Regards,
Ravi.

-Original Message-
From: Ronnie Sahlberg [mailto:sahlb...@google.com] 
Sent: Friday, August 01, 2014 3:58 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
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 against the version that the new version of aix ships with.

Alternatively if you build git yourself on that host you should end up with a 
binary that links with the version of the library that you currently have.



On Fri, Aug 1, 2014 at 12:30 PM,  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.3 or GIT 1.9.0

 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
 able to extract code from git repository directly as well as from ant. 
 Everything went well.
 Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
 are not working. Basic help and version works fine as expected. When I try to 
 pull the code from git repository it give SSL 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.
 When I tried directly pulling code using git pull command - didn't work.
 When I try to pull the code through the ant - didn't work

 The ant version is 1.8.0RC1

 AIX admin worked on this and provided below comments

 Comments form AIX system admin  (Pasted as it is) Even after 
 installing 1.9.0 version of GIT the library files are not compatible with the 
 latest version of SSL (1.0.5.1).
 SSL works fine as a root user and other users. This compatibility issue only 
 a raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH 
 from the same location as GIT and this causes the incompatibility.
 Can you find out from the GIT/ANT support team on what version of SSL GIT 
 supports exactly. - The is specifically with the GIT/SSL as the user xyzabc 
 . The SSL otherwise works perfectly fine.
 You will have to re-compile the ANT libraries to use the latest library files.

 Thanks in advance.

 Regards,
 Ravi.
 --
 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
N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

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.
Does it mean the package available at above location has built with specific 
version of OpenSSL. How can I find out which OpenSSL version is used in the 
packages available at the above location.

Could you please suggest the site from where I need to download git for AIX OS.
Who are the vendors of git so that I will check how to proceed on this.

Regards,
Ravi.

-Original Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net] 
Sent: Friday, 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 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.3 or GIT 1.9.0

The INSTALL file doesn't mention a particular OpenSSL version that we require, 
but I know that it works with versions as old as 0.9.8 and as new as 1.0.1g.  
It may work with still older versions, but I recommend
1.0.1 or newer as it gives you proper TLS 1.2 support.

 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked 
 fine and able to extract code from git repository directly as well as 
 from ant. Everything went well.
 Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git 
 commands are not working. Basic help and version works fine as 
 expected. When I try to pull the code from git repository it give SSL 
 library compatibility issue.
 
 The error is
 OpenSSL version mismatch. Built agains 1000105f, you have 10bf
 fatal: Could not read from remote repository

OpenSSL 1.0.0 (which you were using before) and OpenSSL 1.0.1 are binary 
compatible if compiled with the same flags, but they contain a hard version 
check that fails if they're not the same version.

This means you need to recompile git against the newer OpenSSL version, or ask 
your vendor to patch this check out.  This is true for any program that gives 
you this error.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Re: Git Help needed

[brian m. carlson]

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/
Google Code no longer allows anyone to upload tarballs.

 Does it mean the package available at above location has built with
 specific version of OpenSSL. How can I find out which OpenSSL version
 is used in the packages available at the above location.

If you're downloading the source tarball and building it yourself, then
it's whatever version of OpenSSL is on your system.  To my knowledge,
nobody provides pre-built packages of git for AIX.

 Could you please suggest the site from where I need to download git
 for AIX OS.

As I mentioned above, you'll probably need to build it yourself.

 Who are the vendors of git so that I will check how to proceed on this.

When I referred to having your vendor patch the check out, I meant your
vendor of OpenSSL.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

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 Help needed

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/
Google Code no longer allows anyone to upload tarballs.

 Does it mean the package available at above location has built with 
 specific version of OpenSSL. How can I find out which OpenSSL version 
 is used in the packages available at the above location.

If you're downloading the source tarball and building it yourself, then it's 
whatever version of OpenSSL is on your system.  To my knowledge, nobody 
provides pre-built packages of git for AIX.

 Could you please suggest the site from where I need to download git 
 for AIX OS.

As I mentioned above, you'll probably need to build it yourself.

 Who are the vendors of git so that I will check how to proceed on this.

When I referred to having your vendor patch the check out, I meant your vendor 
of OpenSSL.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
--
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

Re: [PATCH] help: include list of aliases in git-help --all

[Junio C Hamano]

Joel Nothman joel.noth...@gmail.com 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 Nothman joel.nothman at gmail.com
 ---
  Documentation/git-help.txt |  4 +--
  builtin/help.c |  7 ++---
  help.c | 64 
 +++---
  help.h |  7 -
  4 files changed, 61 insertions(+), 21 deletions(-)

 diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
 index b21e9d7..c9fe791 100644
 --- a/Documentation/git-help.txt
 +++ b/Documentation/git-help.txt
 @@ -40,8 +40,8 @@ OPTIONS
  ---
  -a::
  --all::
 - Prints all the available commands on the standard output. This
 - option overrides any given command or guide name.
 + Prints all the available commands and aliases on the standard output.
 + This option overrides any given command or guide name.
  
  -g::
  --guides::
 diff --git a/builtin/help.c b/builtin/help.c
 index 1fdefeb..d1dfecd 100644
 --- a/builtin/help.c
 +++ b/builtin/help.c
 @@ -38,7 +38,7 @@ static int show_guides = 0;
  static unsigned int colopts;
  static enum help_format help_format = HELP_FORMAT_NONE;
  static struct option builtin_help_options[] = {
 - OPT_BOOL('a', all, show_all, N_(print all available commands)),
 + OPT_BOOL('a', all, show_all, N_(print all available commands and 
 aliases)),
   OPT_BOOL('g', guides, show_guides, N_(print list of useful 
 guides)),
   OPT_SET_INT('m', man, help_format, N_(show man page), 
 HELP_FORMAT_MAN),
   OPT_SET_INT('w', web, help_format, N_(show manual in web browser),
 @@ -453,6 +453,7 @@ int cmd_help(int argc, const char **argv, const char 
 *prefix)
   int nongit;
   const char *alias;
   enum help_format parsed_help_format;
 + struct cmdnames alias_cmds;
  
   argc = parse_options(argc, argv, prefix, builtin_help_options,
   builtin_help_usage, 0);
 @@ -461,8 +462,8 @@ int cmd_help(int argc, const char **argv, const char 
 *prefix)
   if (show_all) {
   git_config(git_help_config, NULL);
   printf(_(usage: %s%s), _(git_usage_string), \n\n);
 - load_command_list(git-, main_cmds, other_cmds);
 - list_commands(colopts, main_cmds, other_cmds);
 + load_commands_and_aliases(git-, main_cmds, other_cmds, 
 alias_cmds);
 + list_commands(colopts, main_cmds, other_cmds, alias_cmds);
   }
  
   if (show_guides)
 diff --git a/help.c b/help.c
 index df7d16d..3c14af4 100644
 --- a/help.c
 +++ b/help.c
 @@ -86,7 +86,7 @@ static void pretty_print_string_list(struct cmdnames *cmds,
   int i;
  
   for (i = 0; i  cmds-cnt; i++)
 - string_list_append(list, cmds-names[i]-name);
 + string_list_append(list, cmds-names[i]-name);
   /*
* always enable column display, we only consult column.*
* about layout strategy and stuff
 @@ -202,8 +202,48 @@ void load_command_list(const char *prefix,
   exclude_cmds(other_cmds, main_cmds);
  }
  
 +static struct cmdnames aliases;
 +
 +static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
 +{
 + int i;
 + ALLOC_GROW(cmds-names, cmds-cnt + old-cnt, cmds-alloc);
 +
 + for (i = 0; i  old-cnt; i++)
 + cmds-names[cmds-cnt++] = old-names[i];
 + free(old-names);
 + old-cnt = 0;
 + old-names = NULL;
 +}
 +
 +static int load_aliases_cb(const char *var, const char *value, void *cb)
 +{
 + if (starts_with(var, alias.))
 + add_cmdname(aliases, var + 6, strlen(var + 6));
 + return 0;
 +}
 +
 +void load_commands_and_aliases(const char *prefix,
 + struct cmdnames *main_cmds,
 + struct cmdnames *other_cmds,
 + struct cmdnames *alias_cmds)
 +{
 + load_command_list(prefix, main_cmds, other_cmds);
 +
 + /* reuses global aliases from unknown command functionality */
 + git_config(load_aliases_cb, NULL);
 +
 + add_cmd_list(alias_cmds, aliases);
 + qsort(alias_cmds-names, alias_cmds-cnt,
 +   sizeof(*alias_cmds-names), cmdname_compare);
 + uniq(alias_cmds);
 + exclude_cmds(alias_cmds, main_cmds);
 + exclude_cmds(alias_cmds, other_cmds);
 +}
 +
  void list_commands(unsigned int colopts,
 -struct cmdnames *main_cmds, struct cmdnames *other_cmds)
 +struct cmdnames *main_cmds, struct cmdnames *other_cmds,
 +struct cmdnames *alias_cmds)
  {
   if (main_cmds-cnt) {
   const char *exec_path = git_exec_path();
 @@ -219,6 +259,13 @@ void list_commands(unsigned int colopts,
   pretty_print_string_list(other_cmds, colopts);
   putchar('\n');
   }
 +
 + if (alias_cmds-cnt) {
 + printf_ln(_(aliases

Re: [PATCH] help: include list of aliases in git-help --all

[Joel Nothman]

On 26 February 2014 06:15, Junio C Hamano gits...@pobox.com wrote:
 Joel Nothman joel.noth...@gmail.com 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?

A fair question: I had considered it a conspicuous absence from the
list of commands in git help. After all, aliases are treated like
commands for a few purposes: they are executed as commands, they are
listed as possible command spelling corrections, and they are valid
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. A user may also
not recall whether they had implemented a particular shortcut as an
alias or as a script (one may initially implement a script, and
realise an alias is sufficient; one may at first implement an alias
and realise it is insufficient, and that a script is needed).

In short, for many of the purposes in which one would seek git help
-a, there is no reason to *exclude* aliases from a list of commands
executed likewise.


 Signed-off-by: Joel Nothman joel.nothman at gmail.com
 ---
  Documentation/git-help.txt |  4 +--
  builtin/help.c |  7 ++---
  help.c | 64 
 +++---
  help.h |  7 -
  4 files changed, 61 insertions(+), 21 deletions(-)

 diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
 index b21e9d7..c9fe791 100644
 --- a/Documentation/git-help.txt
 +++ b/Documentation/git-help.txt
 @@ -40,8 +40,8 @@ OPTIONS
  ---
  -a::
  --all::
 - Prints all the available commands on the standard output. This
 - option overrides any given command or guide name.
 + Prints all the available commands and aliases on the standard output.
 + This option overrides any given command or guide name.

  -g::
  --guides::
 diff --git a/builtin/help.c b/builtin/help.c
 index 1fdefeb..d1dfecd 100644
 --- a/builtin/help.c
 +++ b/builtin/help.c
 @@ -38,7 +38,7 @@ static int show_guides = 0;
  static unsigned int colopts;
  static enum help_format help_format = HELP_FORMAT_NONE;
  static struct option builtin_help_options[] = {
 - OPT_BOOL('a', all, show_all, N_(print all available commands)),
 + OPT_BOOL('a', all, show_all, N_(print all available commands and 
 aliases)),
   OPT_BOOL('g', guides, show_guides, N_(print list of useful 
 guides)),
   OPT_SET_INT('m', man, help_format, N_(show man page), 
 HELP_FORMAT_MAN),
   OPT_SET_INT('w', web, help_format, N_(show manual in web browser),
 @@ -453,6 +453,7 @@ int cmd_help(int argc, const char **argv, const char 
 *prefix)
   int nongit;
   const char *alias;
   enum help_format parsed_help_format;
 + struct cmdnames alias_cmds;

   argc = parse_options(argc, argv, prefix, builtin_help_options,
   builtin_help_usage, 0);
 @@ -461,8 +462,8 @@ int cmd_help(int argc, const char **argv, const char 
 *prefix)
   if (show_all) {
   git_config(git_help_config, NULL);
   printf(_(usage: %s%s), _(git_usage_string), \n\n);
 - load_command_list(git-, main_cmds, other_cmds);
 - list_commands(colopts, main_cmds, other_cmds);
 + load_commands_and_aliases(git-, main_cmds, other_cmds, 
 alias_cmds);
 + list_commands(colopts, main_cmds, other_cmds, alias_cmds);
   }

   if (show_guides)
 diff --git a/help.c b/help.c
 index df7d16d..3c14af4 100644
 --- a/help.c
 +++ b/help.c
 @@ -86,7 +86,7 @@ static void pretty_print_string_list(struct cmdnames *cmds,
   int i;

   for (i = 0; i  cmds-cnt; i++)
 - string_list_append(list, cmds-names[i]-name);
 + string_list_append(list, cmds-names[i]-name);
   /*
* always enable column display, we only consult column.*
* about layout strategy and stuff
 @@ -202,8 +202,48 @@ void load_command_list(const char *prefix,
   exclude_cmds(other_cmds, main_cmds);
  }

 +static struct cmdnames aliases;
 +
 +static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
 +{
 + int i;
 + ALLOC_GROW(cmds-names, cmds-cnt + old-cnt, cmds-alloc);
 +
 + for (i = 0; i  old-cnt; i++)
 + cmds-names[cmds-cnt++] = old-names[i];
 + free(old-names);
 + old-cnt = 0;
 + old-names = NULL;
 +}
 +
 +static int load_aliases_cb(const char *var, const char *value, void *cb)
 +{
 + if (starts_with(var, alias.))
 + add_cmdname(aliases, var + 6, strlen(var + 6));
 + return 0;
 +}
 +
 +void load_commands_and_aliases(const char *prefix,
 + struct cmdnames *main_cmds,
 + struct cmdnames *other_cmds,
 + struct cmdnames *alias_cmds)
 +{
 + load_command_list(prefix, main_cmds, other_cmds

Re: [PATCH] help: include list of aliases in git-help --all

[Junio C Hamano]

Joel Nothman joel.noth...@gmail.com 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 would be helped even more if they can get a list of ONLY
aliases, not buried in many standard commands they already know
about.

In other words, I was not fundamentally opposed to *a* way to get a
list that includes aliases, but I was not convinced if it is a good
idea to *change* the output, which people knew would consist of
commands but not aliases, to suddenly start including aliases.
--
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

Re: [PATCH] help: include list of aliases in git-help --all

[Joel Nothman]

On 26 February 2014 08:51, Junio C Hamano gits...@pobox.com wrote:
 Joel Nothman joel.noth...@gmail.com 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 would be helped even more if they can get a list of ONLY
 aliases, not buried in many standard commands they already know
 about.

The list is partitioned. It is partitioned already between
git-installed commands and others on the path. This patch adds a third
partition when required. So they *do* see only aliases... after all
the commands.

Note also that any command on the path will override an alias with the
same name. So in order to list (effective) aliases, you need to
calculate the list of commands as well. If someone defines an alias
overridden by a command, git help -a now makes that apparent by
excluding the alias and including the command above it, while `git
config --get-regexp ^alias` does not.

 In other words, I was not fundamentally opposed to *a* way to get a
 list that includes aliases, but I was not convinced if it is a good
 idea to *change* the output, which people knew would consist of
 commands but not aliases, to suddenly start including aliases.

I don't think this will concern most users for whom aliases are
non-existent, and hence no section will be shown.
--
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

Re: [PATCH] help: include list of aliases in git-help --all

[Philip Oakley]

From: Joel Nothman joel.noth...@gmail.com

On 26 February 2014 06:15, Junio C Hamano gits...@pobox.com wrote:

Joel Nothman joel.noth...@gmail.com 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?


A fair question: I had considered it a conspicuous absence from the
list of commands in git help.


Surely one alternative would be to add an --alias or --aliases option to 
the help command so the user can chose which ones s/he desires to be 
helped about.


At least that's the way I did it with the --guides option.


 After all, aliases are treated like
commands for a few purposes: they are executed as commands, they are
listed as possible command spelling corrections, and they are valid
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. A user may also
not recall whether they had implemented a particular shortcut as an
alias or as a script (one may initially implement a script, and
realise an alias is sufficient; one may at first implement an alias
and realise it is insufficient, and that a script is needed).

In short, for many of the purposes in which one would seek git help
-a, there is no reason to *exclude* aliases from a list of commands
executed likewise.



Signed-off-by: Joel Nothman joel.nothman at gmail.com
---
 Documentation/git-help.txt |  4 +--
 builtin/help.c |  7 ++---
 help.c | 64 
+++---

 help.h |  7 -
 4 files changed, 61 insertions(+), 21 deletions(-)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index b21e9d7..c9fe791 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -40,8 +40,8 @@ OPTIONS
 ---
 -a::
 --all::
- Prints all the available commands on the standard output. This
- option overrides any given command or guide name.
+ Prints all the available commands and aliases on the standard 
output.

+ This option overrides any given command or guide name.

 -g::
 --guides::
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..d1dfecd 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -38,7 +38,7 @@ static int show_guides = 0;
 static unsigned int colopts;
 static enum help_format help_format = HELP_FORMAT_NONE;
 static struct option builtin_help_options[] = {
- OPT_BOOL('a', all, show_all, N_(print all available 
commands)),
+ OPT_BOOL('a', all, show_all, N_(print all available 
commands and aliases)),
  OPT_BOOL('g', guides, show_guides, N_(print list of useful 
guides)),
  OPT_SET_INT('m', man, help_format, N_(show man page), 
HELP_FORMAT_MAN),
  OPT_SET_INT('w', web, help_format, N_(show manual in web 
browser),
@@ -453,6 +453,7 @@ int cmd_help(int argc, const char **argv, const 
char *prefix)

  int nongit;
  const char *alias;
  enum help_format parsed_help_format;
+ struct cmdnames alias_cmds;

  argc = parse_options(argc, argv, prefix, builtin_help_options,
  builtin_help_usage, 0);
@@ -461,8 +462,8 @@ int cmd_help(int argc, const char **argv, const 
char *prefix)

  if (show_all) {
  git_config(git_help_config, NULL);
  printf(_(usage: %s%s), _(git_usage_string), \n\n);
- load_command_list(git-, main_cmds, other_cmds);
- list_commands(colopts, main_cmds, other_cmds);
+ load_commands_and_aliases(git-, main_cmds, 
other_cmds, alias_cmds);
+ list_commands(colopts, main_cmds, other_cmds, 
alias_cmds);

  }

  if (show_guides)
diff --git a/help.c b/help.c
index df7d16d..3c14af4 100644
--- a/help.c
+++ b/help.c
@@ -86,7 +86,7 @@ static void pretty_print_string_list(struct 
cmdnames *cmds,

  int i;

  for (i = 0; i  cmds-cnt; i++)
- string_list_append(list, cmds-names[i]-name);
+ string_list_append(list, cmds-names[i]-name);
  /*
   * always enable column display, we only consult column.*
   * about layout strategy and stuff
@@ -202,8 +202,48 @@ void load_command_list(const char *prefix,
  exclude_cmds(other_cmds, main_cmds);
 }

+static struct cmdnames aliases;
+
+static void add_cmd_list(struct cmdnames *cmds, struct cmdnames 
*old)

+{
+ int i;
+ ALLOC_GROW(cmds-names, cmds-cnt + old-cnt, cmds-alloc);
+
+ for (i = 0; i  old-cnt; i++)
+ cmds-names[cmds-cnt++] = old-names[i];
+ free(old-names);
+ old-cnt = 0;
+ old-names = NULL;
+}
+
+static int load_aliases_cb(const char *var, const char *value, void 
*cb)

+{
+ if (starts_with(var, alias.))
+ add_cmdname(aliases, var + 6, strlen(var + 6));
+ return 0;
+}
+
+void load_commands_and_aliases(const char *prefix

Re: [PATCH] help: include list of aliases in git-help --all

[Junio C Hamano]

Joel Nothman joel.noth...@gmail.com 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 joel.nothman at gmail.com
 ---

Thanks.

 diff --git a/help.c b/help.c
 index df7d16d..3c14af4 100644
 --- a/help.c
 +++ b/help.c
 @@ -86,7 +86,7 @@ static void pretty_print_string_list(struct cmdnames *cmds,
   int i;
  
   for (i = 0; i  cmds-cnt; i++)
 - string_list_append(list, cmds-names[i]-name);
 + string_list_append(list, cmds-names[i]-name);

Why?

 @@ -202,8 +202,48 @@ void load_command_list(const char *prefix,
   exclude_cmds(other_cmds, main_cmds);
  }
  
 +static struct cmdnames aliases;

Instead of using a static global variable, perhaps make this an
on-stack variable in load_commands_and_aliases() that is passed as a
callback parameter to load_aliases_cb() thru git_config()?

 +static int load_aliases_cb(const char *var, const char *value, void *cb)
 +{

That is, cb here is the second parameter you gave to git_config().

  void list_commands(unsigned int colopts,
 -struct cmdnames *main_cmds, struct cmdnames *other_cmds)
 +struct cmdnames *main_cmds, struct cmdnames *other_cmds,
 +struct cmdnames *alias_cmds)
  {
   if (main_cmds-cnt) {
   const char *exec_path = git_exec_path();
 @@ -219,6 +259,13 @@ void list_commands(unsigned int colopts,
   pretty_print_string_list(other_cmds, colopts);
   putchar('\n');
   }
 +
 + if (alias_cmds-cnt) {
 + printf_ln(_(aliases defined in git configuration));

This will not break the use of git help -a in our completion
script, because it ignores anything that does not begin with two SP
followed by alphanumerics.

It may however break scripts that read from help -a done by other
people that may remove the lines in the output that are known to
them as not names of commands (i.e. available git commands...  and
git commands avaliable elsewhere...)---they haven't seen this new
string and would not know that this line must be skipped.

Other than that, looks reasonably cleanly done.  We'd need a test to
cover this so that other people will not break it in future patches.


--
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

[PATCH] help: include list of aliases in git-help --all

[Joel Nothman]

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 joel.nothman at gmail.com
---
 Documentation/git-help.txt |  4 +--
 builtin/help.c |  7 ++---
 help.c | 64 +++---
 help.h |  7 -
 4 files changed, 61 insertions(+), 21 deletions(-)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index b21e9d7..c9fe791 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -40,8 +40,8 @@ OPTIONS
 ---
 -a::
 --all::
-   Prints all the available commands on the standard output. This
-   option overrides any given command or guide name.
+   Prints all the available commands and aliases on the standard output.
+   This option overrides any given command or guide name.
 
 -g::
 --guides::
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..d1dfecd 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -38,7 +38,7 @@ static int show_guides = 0;
 static unsigned int colopts;
 static enum help_format help_format = HELP_FORMAT_NONE;
 static struct option builtin_help_options[] = {
-   OPT_BOOL('a', all, show_all, N_(print all available commands)),
+   OPT_BOOL('a', all, show_all, N_(print all available commands and 
aliases)),
OPT_BOOL('g', guides, show_guides, N_(print list of useful 
guides)),
OPT_SET_INT('m', man, help_format, N_(show man page), 
HELP_FORMAT_MAN),
OPT_SET_INT('w', web, help_format, N_(show manual in web browser),
@@ -453,6 +453,7 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
int nongit;
const char *alias;
enum help_format parsed_help_format;
+   struct cmdnames alias_cmds;
 
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
@@ -461,8 +462,8 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
if (show_all) {
git_config(git_help_config, NULL);
printf(_(usage: %s%s), _(git_usage_string), \n\n);
-   load_command_list(git-, main_cmds, other_cmds);
-   list_commands(colopts, main_cmds, other_cmds);
+   load_commands_and_aliases(git-, main_cmds, other_cmds, 
alias_cmds);
+   list_commands(colopts, main_cmds, other_cmds, alias_cmds);
}
 
if (show_guides)
diff --git a/help.c b/help.c
index df7d16d..3c14af4 100644
--- a/help.c
+++ b/help.c
@@ -86,7 +86,7 @@ static void pretty_print_string_list(struct cmdnames *cmds,
int i;
 
for (i = 0; i  cmds-cnt; i++)
-   string_list_append(list, cmds-names[i]-name);
+   string_list_append(list, cmds-names[i]-name);
/*
 * always enable column display, we only consult column.*
 * about layout strategy and stuff
@@ -202,8 +202,48 @@ void load_command_list(const char *prefix,
exclude_cmds(other_cmds, main_cmds);
 }
 
+static struct cmdnames aliases;
+
+static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
+{
+   int i;
+   ALLOC_GROW(cmds-names, cmds-cnt + old-cnt, cmds-alloc);
+
+   for (i = 0; i  old-cnt; i++)
+   cmds-names[cmds-cnt++] = old-names[i];
+   free(old-names);
+   old-cnt = 0;
+   old-names = NULL;
+}
+
+static int load_aliases_cb(const char *var, const char *value, void *cb)
+{
+   if (starts_with(var, alias.))
+   add_cmdname(aliases, var + 6, strlen(var + 6));
+   return 0;
+}
+
+void load_commands_and_aliases(const char *prefix,
+   struct cmdnames *main_cmds,
+   struct cmdnames *other_cmds,
+   struct cmdnames *alias_cmds)
+{
+   load_command_list(prefix, main_cmds, other_cmds);
+
+   /* reuses global aliases from unknown command functionality */
+   git_config(load_aliases_cb, NULL);
+
+   add_cmd_list(alias_cmds, aliases);
+   qsort(alias_cmds-names, alias_cmds-cnt,
+ sizeof(*alias_cmds-names), cmdname_compare);
+   uniq(alias_cmds);
+   exclude_cmds(alias_cmds, main_cmds);
+   exclude_cmds(alias_cmds, other_cmds);
+}
+
 void list_commands(unsigned int colopts,
-  struct cmdnames *main_cmds, struct cmdnames *other_cmds)
+  struct cmdnames *main_cmds, struct cmdnames *other_cmds,
+  struct cmdnames *alias_cmds)
 {
if (main_cmds-cnt) {
const char *exec_path = git_exec_path();
@@ -219,6 +259,13 @@ void list_commands(unsigned int colopts,
pretty_print_string_list(other_cmds, colopts);
putchar('\n');
}
+
+   if (alias_cmds-cnt) {
+   printf_ln(_(aliases defined in git configuration));
+   putchar('\n

Re: [PATCH] Provide a 'git help user-manual' route to the docbook

[Junio C Hamano]

Philip Oakley philipoak...@iee.org writes:

 diff --git a/Documentation/gituser-manual.txt 
 b/Documentation/gituser-manual.txt
 new file mode 100644
 index 000..9fd4744
 --- /dev/null
 +++ b/Documentation/gituser-manual.txt
 @@ -0,0 +1,34 @@
 +gituser-manual(7)
 +=
 +
 +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 have to click
to get there a worthwhile addition?

I would not mind having a clickable link in the output from

$ git help git

or something that does already have other useful information, though.

 +
 +DESCRIPTION
 +---
 +Git is a fast, scalable, distributed revision control system with an
 +unusually rich command set that provides both high-level operations
 +and full access to internals.
 +
 +The link:user-manual.html[Git User's Manual] provides an
 +in-depth introduction to Git.
 +
 +SEE ALSO
 +
 +linkgit:gittutorial[7],
 +linkgit:giteveryday[7],
 +linkgit:gitcli[7],
 +linkgit:gitworkflows[7]
 +
 +GIT
 +---
 +Part of the linkgit:git[1] suite
 diff --git a/builtin/help.c b/builtin/help.c
 index 1fdefeb..be7c39d 100644
 --- a/builtin/help.c
 +++ b/builtin/help.c
 @@ -427,6 +427,7 @@ static struct {
   { modules, N_(Defining submodule properties) },
   { revisions, N_(Specifying revisions and ranges for Git) },
   { tutorial, N_(A tutorial introduction to Git (for version 1.5.1 or 
 newer)) },
 + { user-manual, N_(A link to the user-manual docbook) },
   { workflows, N_(An overview of recommended workflows with Git) },
  };
--
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

Re: [PATCH] Provide a 'git help user-manual' route to the docbook

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org writes:

diff --git a/Documentation/gituser-manual.txt 
b/Documentation/gituser-manual.txt

new file mode 100644
index 000..9fd4744
--- /dev/null
+++ b/Documentation/gituser-manual.txt
@@ -0,0 +1,34 @@
+gituser-manual(7)
+=
+
+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 have to click
to get there a worthwhile addition?


It is a half-way house, partly because the current 'git help name' 
processing always assumes that the target is a man page, and that the 
page name will always be 'gitname. Thus the current user-manual isn't 
immediately visible to the help system. Also it's not (quite reasonably) 
formatted as a man page either.


This was an attempt to offer more ways for users to discover the 
user-manual, as it would also be listed in the 'git help -g' output. To 
make that work required a proper man-page, hence the patch. Also I was 
avoiding the renaming of the user-manual.txt  user-manual.html file 
because of possible link breakages from external sources.




I would not mind having a clickable link in the output from

$ git help git


There is now a link within the git(1) page, though folk maybe leaping 
past it to the list of commands and env variables, etc.


I'm generally in favour of providing more help sign-posting from more 
directions where possible.




or something that does already have other useful information, though.


+
+DESCRIPTION
+---
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+The link:user-manual.html[Git User's Manual] provides an
+in-depth introduction to Git.
+
+SEE ALSO
+
+linkgit:gittutorial[7],
+linkgit:giteveryday[7],
+linkgit:gitcli[7],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..be7c39d 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -427,6 +427,7 @@ static struct {
 { modules, N_(Defining submodule properties) },
 { revisions, N_(Specifying revisions and ranges for Git) },
 { tutorial, N_(A tutorial introduction to Git (for version 1.5.1 
or newer)) },

+ { user-manual, N_(A link to the user-manual docbook) },
 { workflows, N_(An overview of recommended workflows with 
Git) },

 };

--
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



--
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

[PATCH] Provide a 'git help user-manual' route to the docbook

[Philip Oakley]

Signed-off-by: Philip Oakley philipoak...@iee.org
---
 Documentation/Makefile   |  1 +
 Documentation/gituser-manual.txt | 34 ++
 builtin/help.c   |  1 +
 3 files changed, 36 insertions(+)
 create mode 100644 Documentation/gituser-manual.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index fc6b2cf..657523f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -31,6 +31,7 @@ MAN7_TXT += gitnamespaces.txt
 MAN7_TXT += gitrevisions.txt
 MAN7_TXT += gittutorial-2.txt
 MAN7_TXT += gittutorial.txt
+MAN7_TXT += gituser-manual.txt
 MAN7_TXT += gitworkflows.txt
 
 MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt
new file mode 100644
index 000..9fd4744
--- /dev/null
+++ b/Documentation/gituser-manual.txt
@@ -0,0 +1,34 @@
+gituser-manual(7)
+=
+
+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
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+The link:user-manual.html[Git User's Manual] provides an
+in-depth introduction to Git.
+
+SEE ALSO
+
+linkgit:gittutorial[7],
+linkgit:giteveryday[7],
+linkgit:gitcli[7],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..be7c39d 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -427,6 +427,7 @@ static struct {
{ modules, N_(Defining submodule properties) },
{ revisions, N_(Specifying revisions and ranges for Git) },
{ tutorial, N_(A tutorial introduction to Git (for version 1.5.1 or 
newer)) },
+   { user-manual, N_(A link to the user-manual docbook) },
{ workflows, N_(An overview of recommended workflows with Git) },
 };
 
-- 
1.8.3.msysgit.0

--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org 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 I think
readers would expect.


Sorry, but I still do not get it.  If you have a script


Ah, no, it's not a script.

I had simply moved the content of the stalenotes section into its own 
file 'stalenotes.txt' which could then be included 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 this would not actually include the latest 
release notes as literal text for immediate reading into the 
release-notes(7) man page, which would be my aim, and I think what 
Stefan had suggested as a preferred style.



 that reads
git.txt and extracts its stale-notes section to generate the source
to be processed into release-notes(7), why can't that script also
include the contents of the latest release notes inline into its
output?

My release notes are _not_ written to be compatible with/processable
by AsciiDoc (they are meant to be mere plain text)---perhaps you are
wondering if that would make it harder to maintain your script that
produces release-notes.txt?

Confused...


My thought was that the latest release note would be included as literal 
text, as noted above.
Like you say, it may need to be a script, but I was being cautious about 
what extra work that would entail for each release.






My other question would be to ask how you normally manage the 
up-issue

of the stalenotes, and when you would normally create that section in
git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere
else.


I'm not sure if I am understanding the question right (up-issue?),
but it used to be that the preformatted and web-reachable manual
pages at k.org were processed with stalenotes defined (which by the
way was disabled with adaa3caf Meta/dodoc.sh: adjust to the new
layout, 2011-11-15 on the todo branch), and 26cfcfbf Add release
notes to the distribution., 2007-02-13 used that facility to
prepare something like this:



I hadn't looked back into that part of history. I was somehow expecting 
to see 'stalenotes' being defined somewhere in the current documenation 
preparation options, hence my question about when you would set 
'stalenotes'.


I'll have a look back at that to see how it was used back then.


   docs/git.html
   /git-cat-file.html
   ...
   docs/vX.Y.Z/git.html
   docs/vX.Y.Z/git-cat-file.html
   ...

where the latest one lived immediately underneath docs/*, while
older ones were in versioned subdirectories.



--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Philip Oakley]

From: Stefan Näwe stefan.na...@atlas-elektronik.com

Am 16.01.2014 22:14, schrieb Philip Oakley:

From: Stefan Näwe stefan.na...@atlas-elektronik.com
[...]


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 text 
files

(see the ifdef::stalenotes[] in git/Documentation/git.txt)?

The latter allows individual release notes to be checked, but still
leaves folks with a difficult search problem if they want to find 
when

some command was 'tweaked'.

Obviously, any method would need to be easy to maintain. And the
RelNotes symlink would need handling.


'git help relnotes' should show the current release note with
a link to the previous.


OK, that seems very sensible, as the concatenated release notes run to 
15k lines!


Determining which is the current release note is possibly more 
problematic, which should be when making the documentation.




And 'git help git' should link to the current release note.

In some sense that 'current' should be the same as the 'git --version', 
but through an assumption of a common distribution of git and the 
documentation, rather than any run time determination.


At the moment the Documenation/git.txt 'stalenotes' section could be 
separated into its own file to act as the basis for the links, but as 
yet I don't have a good view as to how the current release notes (with / 
without maint notes?) would be embedded without a maintenance burden for 
Junio.


Philip 


--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Junio C Hamano]

Philip Oakley philipoak...@iee.org 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 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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org 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?


It's that the 'git help release-notes' would _include_ the latest 
release notes, not just link to them (which is what the stalenotes 
currently does). Or at least that was the idea.


Trying to determine the latest version, and then include those release 
notes, and the subsequent maint notes, into the putative 
release-notes(7) man page, without causing you any maintenance hassle, 
was the conceptual problem.


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 I think readers 
would expect.



My other question would be to ask how you normally manage the up-issue 
of the stalenotes, and when you would normally create that section in 
git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere 
else.


Philip

--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Junio C Hamano]

Philip Oakley philipoak...@iee.org 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 I think
 readers would expect.

Sorry, but I still do not get it.  If you have a script that reads
git.txt and extracts its stale-notes section to generate the source
to be processed into release-notes(7), why can't that script also
include the contents of the latest release notes inline into its
output?

My release notes are _not_ written to be compatible with/processable
by AsciiDoc (they are meant to be mere plain text)---perhaps you are
wondering if that would make it harder to maintain your script that
produces release-notes.txt?

Confused...


 My other question would be to ask how you normally manage the up-issue
 of the stalenotes, and when you would normally create that section in
 git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere
 else.

I'm not sure if I am understanding the question right (up-issue?),
but it used to be that the preformatted and web-reachable manual
pages at k.org were processed with stalenotes defined (which by the
way was disabled with adaa3caf Meta/dodoc.sh: adjust to the new
layout, 2011-11-15 on the todo branch), and 26cfcfbf Add release
notes to the distribution., 2007-02-13 used that facility to
prepare something like this:

docs/git.html
/git-cat-file.html
...
docs/vX.Y.Z/git.html
docs/vX.Y.Z/git-cat-file.html
...

where the latest one lived immediately underneath docs/*, while
older ones were in versioned subdirectories.
--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Stefan Näwe]

Am 16.01.2014 22:14, schrieb Philip Oakley:
 From: Stefan Näwe stefan.na...@atlas-elektronik.com
 [...]

 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 text files 
 (see the ifdef::stalenotes[] in git/Documentation/git.txt)?
 
 The latter allows individual release notes to be checked, but still 
 leaves folks with a difficult search problem if they want to find when 
 some command was 'tweaked'.
 
 Obviously, any method would need to be easy to maintain. And the 
 RelNotes symlink would need handling.

'git help relnotes' should show the current release note with
a link to the previous.

And 'git help git' should link to the current release note.


Stefan
-- 

/dev/random says: We now return you to your regularly scheduled flame-throwing
python -c print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
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

Re: [PATCH 0/6] Make 'git help everyday' work - relnotes

[Philip Oakley]

From: Stefan Näwe stefan.na...@atlas-elektronik.com
[...]


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 text files 
(see the ifdef::stalenotes[] in git/Documentation/git.txt)?


The latter allows individual release notes to be checked, but still 
leaves folks with a difficult search problem if they want to find when 
some command was 'tweaked'.


Obviously, any method would need to be easy to maintain. And the 
RelNotes symlink would need handling.


Philip

--

--
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

[PATCH] Provide a 'git help user-manual' route to the docbook

[Philip Oakley]

Signed-off-by: Philip Oakley philipoak...@iee.org
---
 Documentation/Makefile   |  1 +
 Documentation/gituser-manual.txt | 34 ++
 builtin/help.c   |  1 +
 3 files changed, 36 insertions(+)
 create mode 100644 Documentation/gituser-manual.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 36c58fc..3793e4c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -28,6 +28,7 @@ MAN7_TXT += gitnamespaces.txt
 MAN7_TXT += gitrevisions.txt
 MAN7_TXT += gittutorial-2.txt
 MAN7_TXT += gittutorial.txt
+MAN7_TXT += gituser-manual.txt
 MAN7_TXT += gitworkflows.txt
 
 MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt
new file mode 100644
index 000..9fd4744
--- /dev/null
+++ b/Documentation/gituser-manual.txt
@@ -0,0 +1,34 @@
+gituser-manual(7)
+=
+
+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
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+The link:user-manual.html[Git User's Manual] provides an
+in-depth introduction to Git.
+
+SEE ALSO
+
+linkgit:gittutorial[7],
+linkgit:giteveryday[7],
+linkgit:gitcli[7],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..be7c39d 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -427,6 +427,7 @@ static struct {
{ modules, N_(Defining submodule properties) },
{ revisions, N_(Specifying revisions and ranges for Git) },
{ tutorial, N_(A tutorial introduction to Git (for version 1.5.1 or 
newer)) },
+   { user-manual, N_(A link to the user-manual docbook) },
{ workflows, N_(An overview of recommended workflows with Git) },
 };
 
-- 
1.8.3.msysgit.0

--
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

[PATCH v2] Make 'git help everyday' work

[Philip Oakley]

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 giteveryday to the manpages make list.
Deprecate the old everyday.txt as *.txto in the same manner
as bd4a3d61 (Rename {git- = git}remote-helpers.txt,
2013-01-31), including a link to the new man page.

Add 'everyday' to the help --guides list.
Update git(1) and 5 other links to giteveryday.

Signed-off-by: Philip Oakley philipoak...@iee.org
---

The series has been squashed into a single complete patch as
suggested by Jonathan Nieder, and now uses the same deprecation
techniques as the old remote-helpers as pointed out by Junio.

The diff is now smaller because of the shift to '.txto' for the
obsolete old file, so there is no longer a bulk deletion listed.

---
 Documentation/Makefile  |  3 +-
 Documentation/everyday.txto |  9 ++
 Documentation/git.txt   |  4 +--
 Documentation/gitcore-tutorial.txt  |  2 +-
 Documentation/gitcvs-migration.txt  |  2 +-
 Documentation/{everyday.txt = giteveryday.txt} | 39 +
 Documentation/gitglossary.txt   |  2 +-
 Documentation/gittutorial-2.txt |  4 +--
 Documentation/gittutorial.txt   |  4 +--
 README  |  2 +-
 builtin/help.c  |  1 +
 11 files changed, 49 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/everyday.txto
 rename Documentation/{everyday.txt = giteveryday.txt} (94%)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 91a12c7..861560b 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -23,6 +23,7 @@ MAN7_TXT += gitcore-tutorial.txt
 MAN7_TXT += gitcredentials.txt
 MAN7_TXT += gitcvs-migration.txt
 MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += giteveryday.txt
 MAN7_TXT += gitglossary.txt
 MAN7_TXT += gitnamespaces.txt
 MAN7_TXT += gitrevisions.txt
@@ -35,10 +36,10 @@ MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT))
 MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT))
 
 OBSOLETE_HTML = git-remote-helpers.html
+OBSOLETE_HTML += everyday.html
 DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML)
 
 ARTICLES = howto-index
-ARTICLES += everyday
 ARTICLES += git-tools
 ARTICLES += git-bisect-lk2009
 # with their own formatting rules.
diff --git a/Documentation/everyday.txto b/Documentation/everyday.txto
new file mode 100644
index 000..3f8a4ea
--- /dev/null
+++ b/Documentation/everyday.txto
@@ -0,0 +1,9 @@
+Everyday Git With 20 Commands Or So
+===
+
+This document has been moved to linkgit:giteveryday[1].
+
+Please let the owners of the referring site know so that they can update the
+link you clicked to get here.
+
+Thanks.
\ No newline at end of file
diff --git a/Documentation/git.txt b/Documentation/git.txt
index aec3726..bf06dcc 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -22,7 +22,7 @@ unusually rich command set that provides both high-level 
operations
 and full access to internals.
 
 See linkgit:gittutorial[7] to get started, then see
-link:everyday.html[Everyday Git] for a useful minimum set of
+linkgit:giteveryday[7] for a useful minimum set of
 commands.  The link:user-manual.html[Git User's Manual] has a more
 in-depth introduction.
 
@@ -1037,7 +1037,7 @@ subscribed to the list to send a message there.
 SEE ALSO
 
 linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
 linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
 linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
 linkgit:gitworkflows[7]
diff --git a/Documentation/gitcore-tutorial.txt 
b/Documentation/gitcore-tutorial.txt
index 058a352..ccf31dd 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1667,7 +1667,7 @@ linkgit:gittutorial[7],
 linkgit:gittutorial-2[7],
 linkgit:gitcvs-migration[7],
 linkgit:git-help[1],
-link:everyday.html[Everyday git],
+linkgit:giteveryday[7],
 link:user-manual.html[The Git User's Manual]
 
 GIT
diff --git a/Documentation/gitcvs-migration.txt 
b/Documentation/gitcvs-migration.txt
index 5ea94cb..da8688d 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -194,7 +194,7 @@ linkgit:gittutorial[7],
 linkgit:gittutorial-2[7],
 linkgit:gitcore-tutorial[7],
 linkgit:gitglossary[7],
-link:everyday.html[Everyday Git],
+linkgit:giteveryday[7],
 link:user-manual.html[The Git User's Manual]
 
 GIT
diff --git a/Documentation/everyday.txt b/Documentation/giteveryday.txt
similarity index 94%
rename from Documentation/everyday.txt
rename to Documentation/giteveryday.txt
index 2a18c1f

Re: [PATCH 0/6] Make 'git help everyday' work

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org writes:


From: Junio C Hamano gits...@pobox.com

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 guides that it currently misses. (Tt also
misses the 'user-manual', which isn't a man page, but could have a
link page to guide the seeker of truth between 'git help' and the
actual user-manual)

The only method I can see for that (via help.c) is to get the 
filename

format correct.  Where you thinking of something else?


I do not have an objection against the creation of giteveryday.txt;
I was questioning the way the original everyday.txt was left behind
to bit-rot.  It is good to keep _something_ there, because there may
be old URLs floating around that point at Documentation/everyday.txt,
but the contents of that file does not have to be a stale copy.

Cf. bd4a3d61 (Rename {git- = git}remote-helpers.txt, 2013-01-31)
for how we renamed git-remote-helpers.txt to gitremote-helpers.txt



The commit also highlighted a couple of other places I needed to update

What's the right set of options for format-patch to avoid the bulk 
deletions and bulk insertions between the old an new versions? That 
commit was amended in situ, so never had the three way 
delete/move/create problem.


We have:
everyday.txt (old) - delete
everyday.txt (new) -create (5% similarity)
everyday.txt (old) - giteveryday.txt (95% similarity)

It just feels that 400+ lines of complete deletion doesn't need to be in 
the summary patch. I have it in my mind that we always end up with the 
deletions being listed.


Philip 


--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

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 guides that it currently misses. (Tt also misses the 
'user-manual', which isn't a man page, but could have a link page to 
guide the seeker of truth between 'git help' and the actual user-manual)


The only method I can see for that (via help.c) is to get the filename 
format correct.  Where you thinking of something else?




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 that after reorganizing with something like this series.


Agreed.


--


--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[Stefan Näwe]

Am 10.01.2014 00:49, schrieb 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.
 
 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 that after reorganizing with something like this series.

I'd really like to see 'git help relnotes' working as well...

Stefan
-- 

/dev/random says: Despite the high cost of living, it remains popular.
python -c print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[Junio C Hamano]

Philip Oakley philipoak...@iee.org writes:

 From: Junio C Hamano gits...@pobox.com
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 guides that it currently misses. (Tt also
 misses the 'user-manual', which isn't a man page, but could have a
 link page to guide the seeker of truth between 'git help' and the
 actual user-manual)

 The only method I can see for that (via help.c) is to get the filename
 format correct.  Where you thinking of something else?

I do not have an objection against the creation of giteveryday.txt;
I was questioning the way the original everyday.txt was left behind
to bit-rot.  It is good to keep _something_ there, because there may
be old URLs floating around that point at Documentation/everyday.txt,
but the contents of that file does not have to be a stale copy.

Cf. bd4a3d61 (Rename {git- = git}remote-helpers.txt, 2013-01-31)
for how we renamed git-remote-helpers.txt to gitremote-helpers.txt
--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[Jonathan Nieder]

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
patch.  They all are part of accomplishing the same task, they are not
too hard to read together, and the intermediate state after applying a
few but not the rest doesn't make much sense.  The details of patches
2-6/6 look good to me.

Alternatively, this could be two patches:

 1 - modify everyday.txt in place to be a suitable manpage
 2 - rename it, add a placeholder for the old name, and modify the
 build rules to treat it as an actual manpage

Hope that helps,
Jonathan
--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[Philip Oakley]

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org writes:


From: Junio C Hamano gits...@pobox.com

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 guides that it currently misses. (Tt also
misses the 'user-manual', which isn't a man page, but could have a
link page to guide the seeker of truth between 'git help' and the
actual user-manual)

The only method I can see for that (via help.c) is to get the 
filename

format correct.  Where you thinking of something else?


I do not have an objection against the creation of giteveryday.txt;
I was questioning the way the original everyday.txt was left behind
to bit-rot.  It is good to keep _something_ there, because there may
be old URLs floating around that point at Documentation/everyday.txt,
but the contents of that file does not have to be a stale copy.


Ah, OK. I had indicated it would be deprecated, but had resisted stating 
a date for deletion (e.g. git 2.0).


I was thinking of a moderate two step deprecation period with the next 
step being a severely cut down residual stub, before it's removal.




Cf. bd4a3d61 (Rename {git- = git}remote-helpers.txt, 2013-01-31)
for how we renamed git-remote-helpers.txt to gitremote-helpers.txt


I'll have a look at re-using that approach.

Anything else needed before a re-roll?

Philip

--
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

[PATCH 0/6] Make 'git help everyday' work

[Philip Oakley]

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 giteveryday.txt
Second modify giteveryday to fit man page formatting. Include the standard Git 
footer.
Third add giteveryday to the manpages make list.
Fourth add deprecation note to older everday.txt. Include link to new man page.
Fifth add 'everyday' to the help --guides list.
Finally, update the git(1) link.

The series could be squashed together once any foible have been eliminated.

Philip Oakley (6):
  copy everyday.txt to giteveryday.txt
  Update giteveryday.txt to fit man page formatting
  add giteveryday to the manpages make list
  Add deprecation note to old everyday.txt
  add 'everyday' to the help --guides list
  Update git(1) link to giteveryday

 Documentation/Makefile|   1 +
 Documentation/everyday.txt|   4 +
 Documentation/git.txt |   2 +-
 Documentation/giteveryday.txt | 428 ++
 builtin/help.c|   1 +
 5 files changed, 435 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/giteveryday.txt

-- 
1.8.3.msysgit.0

--
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

Re: [PATCH 0/6] Make 'git help everyday' work

[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.

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 that after reorganizing with something like this series.
--
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

Re: Should git help respect the 'pager' setting?

[Junio C Hamano]

John Keeping j...@keeping.me.uk writes:

 On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
 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?

Running man is the last thing we do before exitting git help and
exec_man_man() does seem to do execlp(), so I do not see it as an
issue.

 Overriding PAGER might make sense, but I'd be quite annoyed if Git
 decided to override MANPAGER without providing some way to override it.

Hmm, see below.

 If a user sets MANPAGER then it'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.

True, and for that matter, if the user sets PAGER to use with
non-Git (including manual pages) and also sets GIT_PAGER to use
specifically with Git, the user would be annoyed if we passed
formatted manual pages to GIT_PAGER by exporting PAGER (or driving
man with its -P option).
--
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

Should git help respect the 'pager' setting?

[Michael Campbell]

I have my global git config pager set to 'cat', but when I do a git
help command, 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-whatever, but wondered if this was a bug or user
error.  (git --no-pager help command does the same.)


12:31 [mcampbell] /tmp  % git --no-pager help log
WARNING: terminal is not fully functional
-  (press RETURN)
--
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

Re: Should git help respect the 'pager' setting?

[Matthieu Moy]

Michael Campbell michael.campb...@gmail.com writes:

 I have my global git config pager set to 'cat', but when I do a git
 help command, 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-whatever, but wondered if this was a bug or user
 error.  (git --no-pager help command does the same.)

git help foo just calls man git-foo by default, so what happens is
the same as if you called man git-foo by hand. Git does not have
much control over what man will do, it could probably call man -P
$pager when the Git pager is set, but I'd find it a bit weird.

If you're an Emacs user, you can read about man.viewer and set it to
woman, or set PAGER=cat when inside Emacs.

I personally run M-x git-foo RET, and never run git help.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

Re: Should git help respect the 'pager' setting?

[Matthieu Moy]

Ramkumar Ramachandra artag...@gmail.com writes:

 It just needs to set $PAGER or $MANPAGER before the exec(), no?

Yes, that should do the same as man -P.

 I would argue that it should do this. $GIT_PAGER works everywhere
 else, but obviously man has no knowledge about it.

I find it a bit weird that Git sets the configuration for external
commands, but it may make sense. No strong opinion here.

 If you're an Emacs user, you can read about man.viewer and set it to
 woman, or set PAGER=cat when inside Emacs.

 I just learnt about man.viewer.  There's 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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

Re: Should git help respect the 'pager' setting?

[Ramkumar Ramachandra]

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?
--
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

Re: Should git help respect the 'pager' setting?

[John Keeping]

On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
 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?

Overriding PAGER might make sense, but I'd be quite annoyed if Git
decided to override MANPAGER without providing some way to override it.

If a user sets MANPAGER then it'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

[PATCH V3 1/5] Show help: -a and -g option, and 'git help concept' usage.

[Philip Oakley]

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..2f8aa41 100644
--- a/git.c
+++ b/git.c
@@ -13,7 +13,9 @@ const char git_usage_string[] =
   command [args];
 
 const char git_more_info_string[] =
-   N_(See 'git help command' for more information on a specific 
command.);
+   N_('git help -a' and 'git help -g' lists available subcommands and 
some\n
+  concept guides. See 'git help command' or 'git help concept'\n
+  to read about a specific subcommand or concept.);
 
 static struct startup_info git_startup_info;
 static int use_pager = -1;
-- 
1.8.1.msysgit.1

--
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

[PATCH V3 0/5] Git help option to list user guides

[Philip Oakley]

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 inline with Junio's
suggestions, and re-spaced so that command example are not split over
line ends.

Junio's suggestions in $gmane/217354/focus=217355 have been included.
Junio also asked about the `if (!argv[0])` test which is, correctly,
performed _after_ the -a and -g options are taken, 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 concept' usage.
  Help.c use OPT_BOOL and refactor logic
  Help.c add --guide option
  Help.c: add list_common_guides_help() function
  Help doc: Include --guide option description

 Documentation/git-help.txt | 30 ++
 builtin/help.c | 17 +++--
 common-guides.h| 11 +++
 git.c  |  4 +++-
 help.c | 18 ++
 help.h |  1 +
 6 files changed, 70 insertions(+), 11 deletions(-)
 create mode 100644 common-guides.h

-- 
1.8.1.msysgit.1

--
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

Re: [PATCH V3 1/5] Show help: -a and -g option, and 'git help concept' usage.

[Junio C Hamano]

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, I
think.  If we stopped with 1/5, then the message will promise git
help -g does something useful, while the code is not yet ready.

  git.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/git.c b/git.c
 index 39ba6b1..2f8aa41 100644
 --- a/git.c
 +++ b/git.c
 @@ -13,7 +13,9 @@ const char git_usage_string[] =
  command [args];
  
  const char git_more_info_string[] =
 - N_(See 'git help command' for more information on a specific 
 command.);
 + N_('git help -a' and 'git help -g' lists available subcommands and 
 some\n
 +concept guides. See 'git help command' or 'git help concept'\n
 +to read about a specific subcommand or concept.);
  
  static struct startup_info git_startup_info;
  static int use_pager = -1;
--
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

Re: [PATCH] git help config: s/insn/instruction/

[Matthias Krüger]

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

(Is this sufficient or do I have to re-send the patch with the sign-off 
line?)

--
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

Re: [PATCH] git help config: s/insn/instruction/

[Junio C Hamano]

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-by: Matthias Krüger matthias.krue...@famsik.de

 (Is this sufficient or do I have to re-send the patch with the
 sign-off line?)

I can squash it in, so there is no need to resend.  The more
important thing is I won't have to for your future patches.

Thanks.
--
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

[PATCH] git help config: s/insn/instruction/

[Matthias Krüger]

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
+++ b/Documentation/config.txt
@@ -555,7 +555,7 @@ core.commentchar::
(default '#').
 
 sequence.editor::
-   Text editor used by `git rebase -i` for editing the rebase insn file.
+   Text editor used by `git rebase -i` for editing the rebase instruction 
file.
The value is meant to be interpreted by the shell when it is used.
It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
When not configured the default commit message editor is used instead.
-- 
1.8.2

--
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

Re: [PATCH] git help config: s/insn/instruction/

[Junio C Hamano]

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 info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] Git help option to list user guides

[Philip Oakley]

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 numbering
Patch 1: Use 'Git' in help messages
Dropped.
a. the 'git version' string is used in the wild for version checking,
in particular Git Gui checks the string is 'git version'.
b. a recent patch series fixed on lower case messages for 'usage:',
respect that.
c. many consider that the 'git' reference was to the 'git cmd' format
rather than (the system) Git's commands.

Patch 2 (now 1/5): Show 'git help guide' usage, with examples
Correct elipsis dots for unterminated list of examples.

Patch 2 (now 2/5): Help.c use OPT_COUNTUP
Unchanged.

Patch 4 (now 3/5): Help.c add --guide option
Update commit message to explain the -g|--guide logic.

Patch 5 (now 4/5): Help.c: add list_common_guides_help() function
Removed the 'build artefact' /* */ comment line.
Note that these are just the common guides and used in a usage message.
The data was generated by a script variant of generate-cmdlist.sh

Patch (new 5/5): Help doc: Include --guide option description
Update the documentation/git-help.txt - I had been caught out by
the same 'focus on the code' mistake made by many and forgot
the documenation ;-)

Patch 6 - 13: 
All dropped.
Drop the separate guide list.txt and extraction script, which was
copied from the common command list and script. If the guide usage
list is useful, extend the command-list.txt and generate-cmdlist.sh
at a later date.

Drop the rename of user-manual and everyday because they are not
formatted as manuals. They can't be started by help's call to 'man'
(and possibly other paths) anyway.

Philip Oakley (5):
  Show 'git help guide' usage, with examples
  Help.c use OPT_COUNTUP
  Help.c add --guide option
  Help.c: add list_common_guides_help() function
  Help doc: Include --guide option description

 Documentation/git-help.txt | 28 +---
 builtin/help.c | 11 ---
 common-guides.h| 11 +++
 git.c  |  4 +++-
 help.c | 18 ++
 help.h |  1 +
 6 files changed, 62 insertions(+), 11 deletions(-)
 create mode 100644 common-guides.h

-- 
1.8.1.msysgit.1

--
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

[PATCH v2 1/5] Show 'git help guide' usage, with examples

[Philip Oakley]

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-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 b10c18b..d9b71c1 100644
--- a/git.c
+++ b/git.c
@@ -13,7 +13,9 @@ const char git_usage_string[] =
   command [args];
 
 const char git_more_info_string[] =
-   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
+  While 'git help guide', will show the selected Git concept 
guide.\n
+  Examples: 'git help git', 'git help branch', 'git help 
tutorial'...);
 
 static struct startup_info git_startup_info;
 static int use_pager = -1;
-- 
1.8.1.msysgit.1

--
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

Re: [PATCH v2 1/5] Show 'git help guide' usage, with examples

[Junio C Hamano]

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' is an obvious guide to suggest.

 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 b10c18b..d9b71c1 100644
 --- a/git.c
 +++ b/git.c
 @@ -13,7 +13,9 @@ const char git_usage_string[] =
  command [args];
  
  const char git_more_info_string[] =
 - 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
 +While 'git help guide', will show the selected Git concept 
 guide.\n
 +Examples: 'git help git', 'git help branch', 'git help 
 tutorial'...);

While I think it is a good idea to mention that the argument to
help does not have to be the name of a subcommand, I have two
issues with this patch.

 * A free-standing While looks strange.  I would expect a sentence
   that begins with While 'git help guide' shows X to end with
   something negative like it is not recommended. Perhaps it is
   just me.

 * It took me two readings to realize that selected in selected
   Git concept guide refers to what the user chose to see by
   naming the guide.  It looked as if the command will give users
   only a selected few among 47 available ones, chosen by the
   implementors.

How about doing it this way if you are adding two lines anyway?

'git help -a' and 'git help -g' lists available subcommands
and concept guides. See 'git help command' or 'git help
concept' to read about a specific subcommand or concept.

Replacing Examples: that has to stay incomplete for brevity with
the way to get the list of subcommands and concepts would a better
approach, I think.  Teach them how to fish, instead of giving them
fish.



--
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

[PATCH v2 0/5] [RESEND with Cc:] Git help option to list user guides

[Philip Oakley]

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 numbering
Patch 1: Use 'Git' in help messages
Dropped.
a. the 'git version' string is used in the wild for version checking,
in particular Git Gui checks the string is 'git version'.
b. a recent patch series fixed on lower case messages for 'usage:',
respect that.
c. many consider that the 'git' reference was to the 'git cmd' format
rather than (the system) Git's commands.

Patch 2 (now 1/5): Show 'git help guide' usage, with examples
Correct elipsis dots for unterminated list of examples.

Patch 2 (now 2/5): Help.c use OPT_COUNTUP
Unchanged.

Patch 4 (now 3/5): Help.c add --guide option
Update commit message to explain the -g|--guide logic.

Patch 5 (now 4/5): Help.c: add list_common_guides_help() function
Removed the 'build artefact' /* */ comment line.
Note that these are just the common guides and used in a usage message.
The data was generated by a script variant of generate-cmdlist.sh

Patch (new 5/5): Help doc: Include --guide option description
Update the documentation/git-help.txt - I had been caught out by
the same 'focus on the code' mistake made by many and forgot
the documenation ;-)

Patch 6 - 13: 
All dropped.
Drop the separate guide list.txt and extraction script, which was
copied from the common command list and script. If the guide usage
list is useful, extend the command-list.txt and generate-cmdlist.sh
at a later date.

Drop the rename of user-manual and everyday because they are not
formatted as manuals. They can't be started by help's call to 'man'
(and possibly other paths) anyway.

Philip Oakley (5):
  Show 'git help guide' usage, with examples
  Help.c use OPT_COUNTUP
  Help.c add --guide option
  Help.c: add list_common_guides_help() function
  Help doc: Include --guide option description

 Documentation/git-help.txt | 28 +---
 builtin/help.c | 11 ---
 common-guides.h| 11 +++
 git.c  |  4 +++-
 help.c | 18 ++
 help.h |  1 +
 6 files changed, 62 insertions(+), 11 deletions(-)
 create mode 100644 common-guides.h

-- 
1.8.1.msysgit.1

--
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