* Re: [PATCH v2 1/5] Show 'git help <guide>' usage, with examples
From: Junio C Hamano @ 2013-03-03 23:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1362342072-1412-2-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@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 <philipoakley@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.
^ permalink raw reply
* Re: [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Junio C Hamano @ 2013-03-03 23:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1362342072-1412-3-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> rename deprecated option in preparation for 'git help --guides'.
s/rename/Rename/;
>
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
> ---
Hrm, I do not recall anybody ever declared that "--all" is deprecated.
I do not think we want --all and --all --all to be different, and we
certainly do not want --all --no-all to be not-all, so I cannot tell
what you want to achieve with this change at all, either from the
patch or the proposed log message.
> builtin/help.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/help.c b/builtin/help.c
> index d1d7181..d10cbed 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -39,7 +39,7 @@ static int show_all = 0;
> static unsigned int colopts;
> static enum help_format help_format = HELP_FORMAT_NONE;
> static struct option builtin_help_options[] = {
> - OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
> + OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
> 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"),
> HELP_FORMAT_WEB),
^ permalink raw reply
* Re: [PATCH v2 3/5] Help.c add --guide option
From: Junio C Hamano @ 2013-03-03 23:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1362342072-1412-4-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> Logic, but no actions, included.
I am not sure what you mean. Is that to break "bisect"?
Ahh, you meant "command line is parsed but we do not actually show
guides yet, which is done by later patches in this series". OK.
> The --all commands option, if given, will display first.
> The --guide option's list will then be displayed.
>
> The common commands list is only displayed if neither option,
> nor a command or guide name, is given.
>
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
> ---
> builtin/help.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/help.c b/builtin/help.c
> index d10cbed..6089d72 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -36,10 +36,12 @@ enum help_format {
> static const char *html_path;
>
> static int show_all = 0;
> +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_COUNTUP('a', "all", &show_all, N_("print all available commands")),
> + OPT_COUNTUP('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"),
> HELP_FORMAT_WEB),
> @@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {
> };
>
> static const char * const builtin_help_usage[] = {
> - N_("git help [--all] [--man|--web|--info] [command]"),
> + N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
> NULL
> };
>
> @@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
> list_commands(colopts, &main_cmds, &other_cmds);
> printf("%s\n", _(git_more_info_string));
> + if (!show_guides) return 0;
> + }
> + if (show_guides) {
> return 0;
> }
> -
Ugly.
if (show_all) {
... do not touch anything here ...
... but remove "return 0;" ...
}
if (show_guides) {
... show guides but do not "return 0" ...
}
if (show_all || show_guides) {
... we were asked to do either/or --all/--guides ...
... and have done what we were asked to do ...
return 0;
}
This is a tangent, but before all of the above, cmd_help() should
verify that it got no arguments (when show_all/show_guides is in
effect) or it got one argument (otherwise), I think.
> if (!argv[0]) {
> printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
> list_common_cmds_help();
^ permalink raw reply
* Re: [PATCH v2 5/5] Help doc: Include --guide option description
From: Junio C Hamano @ 2013-03-03 23:39 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1362342072-1412-6-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> Note that the ability to display an individual guide was
> always possible. Include this in the update.
>
> Also tell readers how git(1) can be accessed, especially for
> Git for Windows users who do not have the 'man' command.
> Likewise include a commentary on how to access this page (Catch 22).
>
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
> ---
> Documentation/git-help.txt | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
> index e07b6dc..498a94e 100644
> --- a/Documentation/git-help.txt
> +++ b/Documentation/git-help.txt
> @@ -8,31 +8,45 @@ git-help - Display help information about Git
> SYNOPSIS
> --------
> [verse]
> -'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
> +'git help' [-a|--all] [-g|--guide]
> + [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
>
> DESCRIPTION
> -----------
>
> -With no options and no COMMAND given, the synopsis of the 'git'
> +With no options and no COMMAND|GUIDE given, the synopsis of the 'git'
Please avoid BNF in the prose meant for human consumption unless
necessary. I think you can just say " or " here.
> command and a list of the most commonly used Git commands are printed
> on the standard output.
>
> If the option '--all' or '-a' is given, then all available commands are
> printed on the standard output.
>
> -If a Git subcommand is named, a manual page for that subcommand 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 the option '--guide' or '-g' is given then, a list of the useful
> +Git guides is also printed on the standard output.
s/given then,/given, then/ or just s/ then// make it easier to
follow? I personally would vote for doing s/given, then/given, /
for the previous paragraph on "--all" as well.
> -Note that `git --help ...` is identical to `git help ...` because the
> +If a Git subcommand, or a Git guide, is given, a manual page for that
"If the name of a command or a guide is given" without "Git/git"
would be much easier to read, especially when the first paragraph
talks about "COMMAND or GUIDE". I also think s/command/subcommand/
in the synopsis and in the first paragraph may be good for consistency
with this part.
> +subcommand is brought up. The 'man' program is used by default for this
> +purpose, but this can be overridden by other options or configuration
> +variables.
> +
> +Note that 'git --help ...' is identical to 'git help ...' because the
> former is internally converted into the latter.
>
> +To display the linkgit:git[1] man page use 'git help git'.
s/man page use/man page, use/;
> +
> +This page can be displayed with 'git help help' or 'git help --help'
> +
> OPTIONS
> -------
> -a::
> --all::
> Prints all the available commands on the standard output. This
> - option supersedes any other option.
> + option overides any given command or guide name.
> +
> +-g::
> +--guides::
> + Prints a list of useful guides on the standard output. This
> + option overides any given command or guide name.
Thanks. Overall this round looks a lot more manageable than the
previous one.
^ permalink raw reply
* [BUG] Incorrect/misleading error when `git rev-list --objects --all` hits the max open files limit
From: Peter Rabbitson @ 2013-03-03 23:29 UTC (permalink / raw)
To: git
Hi!
I was tinkering with a massive git repository (actually a bup
repository, but it is a standard valid git repo underneath). While
validating that a repack ran succesfully I executed the command:
git rev-list --objects --all > rev.list
And got back this:
error: packfile ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be accessed
fatal: missing blob object '27a8cf44da85b958aef2b5074931e7913e08ae95'
Several hours later after successful fsck, and after chasing down trees
blobs etc, I realized that the problem is too many open files. The hint
came from ls-tree which lists the correct error (among a lot of spurious
junk):
git ls-tree -r c636a5f51d4e > /dev/null
error: packfile ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be accessed
error: packfile ./objects/pack/pack-841e375f5e6c793a52fd1a3a2aea0b76219c4cdd.pack cannot be accessed
error: packfile ./objects/pack/pack-e67d9bf75e0840fc6113170b314d2d5a32cbb45a.pack cannot be accessed
error: packfile ./objects/pack/pack-b8fd8f083461c391fe6ec396840c328620d912e2.pack cannot be accessed
error: packfile ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be accessed
error: packfile ./objects/pack/pack-804e0fadf56e2a165c157ef257620369adeea595.pack cannot be accessed
error: unable to open object pack directory: ./objects/pack: Too many open files
error: packfile ./objects/pack/pack-804e0fadf56e2a165c157ef257620369adeea595.pack cannot be accessed
error: Could not read 32a050cb7e54a1e817d135d25ab251480e8d9e3c
Failure to report the correct message verified with git 1.7.2.5 and
1.8.2 (debian testing and experimental).
I hope this is sufficient description to address the underlying issue. I
will keep the un-repacked "many files" repo around just in case you need
more info/testing (though lowering the ulimit works equally well on
normal-size repos).
Cheers
^ permalink raw reply
* [PATCH v2 1/5] Show 'git help <guide>' usage, with examples
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
In-Reply-To: <1362354260-3772-1-git-send-email-philipoakley@iee.org>
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 <philipoakley@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
^ permalink raw reply related
* [PATCH v2 0/5] [RESEND with Cc:] Git help option to list user guides
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
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
^ permalink raw reply
* [PATCH v2 5/5] Help doc: Include --guide option description
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
In-Reply-To: <1362354260-3772-1-git-send-email-philipoakley@iee.org>
Note that the ability to display an individual guide was
always possible. Include this in the update.
Also tell readers how git(1) can be accessed, especially for
Git for Windows users who do not have the 'man' command.
Likewise include a commentary on how to access this page (Catch 22).
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/git-help.txt | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index e07b6dc..498a94e 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
--------
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+ [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
-----------
-With no options and no COMMAND given, the synopsis of the 'git'
+With no options and no COMMAND|GUIDE given, the synopsis of the 'git'
command and a list of the most commonly used Git commands are printed
on the standard output.
If the option '--all' or '-a' is given, then all available commands are
printed on the standard output.
-If a Git subcommand is named, a manual page for that subcommand 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 the option '--guide' or '-g' is given then, a list of the useful
+Git guides is also printed on the standard output.
-Note that `git --help ...` is identical to `git help ...` because the
+If a Git subcommand, or a Git guide, is given, a manual page for that
+subcommand is brought up. The 'man' program is used by default for this
+purpose, but this can be overridden by other options or configuration
+variables.
+
+Note that 'git --help ...' is identical to 'git help ...' because the
former is internally converted into the latter.
+To display the linkgit:git[1] man page use 'git help git'.
+
+This page can be displayed with 'git help help' or 'git help --help'
+
OPTIONS
-------
-a::
--all::
Prints all the available commands on the standard output. This
- option supersedes any other option.
+ option overides any given command or guide name.
+
+-g::
+--guides::
+ Prints a list of useful guides on the standard output. This
+ option overides any given command or guide name.
-i::
--info::
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
In-Reply-To: <1362354260-3772-1-git-send-email-philipoakley@iee.org>
rename deprecated option in preparation for 'git help --guides'.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index d1d7181..d10cbed 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -39,7 +39,7 @@ static int show_all = 0;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
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"),
HELP_FORMAT_WEB),
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 4/5] Help.c: add list_common_guides_help() function
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
In-Reply-To: <1362354260-3772-1-git-send-email-philipoakley@iee.org>
Re-use list_common_cmds_help but simply change the array name.
Candidate for future refactoring to pass a pointer to the array.
The common-guides.h list was generated with a simple variant of the
generate-cmdlist.sh and command-list.txt.
Do not list User-manual and Everday Git which not follow the naming
convention, nor gitrepository-layout which doesn't fit within the
name field size.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 1 +
common-guides.h | 11 +++++++++++
help.c | 18 ++++++++++++++++++
help.h | 1 +
4 files changed, 31 insertions(+)
create mode 100644 common-guides.h
diff --git a/builtin/help.c b/builtin/help.c
index 6089d72..e21ffa5 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -434,6 +434,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (!show_guides) return 0;
}
if (show_guides) {
+ list_common_guides_help();
return 0;
}
if (!argv[0]) {
diff --git a/common-guides.h b/common-guides.h
new file mode 100644
index 0000000..0e94fdc
--- /dev/null
+++ b/common-guides.h
@@ -0,0 +1,11 @@
+/* re-use struct cmdname_help in common-commands.h */
+
+static struct cmdname_help common_guides[] = {
+ {"attributes", "defining attributes per path"},
+ {"glossary", "A GIT Glossary"},
+ {"ignore", "Specifies intentionally untracked files to ignore"},
+ {"modules", "defining submodule properties"},
+ {"revisions", "specifying revisions and ranges for git"},
+ {"tutorial", "A tutorial introduction to git (for version 1.5.1 or newer)"},
+ {"workflows", "An overview of recommended workflows with git"},
+};
diff --git a/help.c b/help.c
index 1dfa0b0..f4de407 100644
--- a/help.c
+++ b/help.c
@@ -4,6 +4,7 @@
#include "levenshtein.h"
#include "help.h"
#include "common-cmds.h"
+#include "common-guides.h"
#include "string-list.h"
#include "column.h"
#include "version.h"
@@ -240,6 +241,23 @@ void list_common_cmds_help(void)
}
}
+void list_common_guides_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ if (longest < strlen(common_guides[i].name))
+ longest = strlen(common_guides[i].name);
+ }
+
+ puts(_("The common Git guides are:"));
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ printf(" %s ", common_guides[i].name);
+ mput_char(' ', longest - strlen(common_guides[i].name));
+ puts(_(common_guides[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
diff --git a/help.h b/help.h
index 0ae5a12..4ae1fd7 100644
--- a/help.h
+++ b/help.h
@@ -17,6 +17,7 @@ static inline void mput_char(char c, unsigned int num)
}
extern void list_common_cmds_help(void);
+extern void list_common_guides_help(void);
extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 3/5] Help.c add --guide option
From: Philip Oakley @ 2013-03-03 23:44 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, W. Trevor King, David Aguilar
In-Reply-To: <1362354260-3772-1-git-send-email-philipoakley@iee.org>
Logic, but no actions, included.
The --all commands option, if given, will display first.
The --guide option's list will then be displayed.
The common commands list is only displayed if neither option,
nor a command or guide name, is given.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index d10cbed..6089d72 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -36,10 +36,12 @@ enum help_format {
static const char *html_path;
static int show_all = 0;
+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_COUNTUP('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('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"),
HELP_FORMAT_WEB),
@@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {
};
static const char * const builtin_help_usage[] = {
- N_("git help [--all] [--man|--web|--info] [command]"),
+ N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
NULL
};
@@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
+ if (!show_guides) return 0;
+ }
+ if (show_guides) {
return 0;
}
-
if (!argv[0]) {
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_common_cmds_help();
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Philip Oakley @ 2013-03-03 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vwqtoyryp.fsf@alter.siamese.dyndns.org>
[Sorry if the resend with Cc: crossed over]
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, March 03, 2013 11:38 PM
Subject: Re: [PATCH v2 2/5] Help.c use OPT_COUNTUP
> Philip Oakley <philipoakley@iee.org> writes:
>
>> rename deprecated option in preparation for 'git help --guides'.
>
> s/rename/Rename/;
OK.
>
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>
> Hrm, I do not recall anybody ever declared that "--all" is deprecated.
No, it was the use OPT_COUNTUP rather than OPT_BOOLEAN that the
'deprecated' was refering to.
Maybe be I should have extended what option was being refered to.
>
> I do not think we want --all and --all --all to be different, and we
> certainly do not want --all --no-all to be not-all, so I cannot tell
> what you want to achieve with this change at all, either from the
> patch or the proposed log message.
>
>> builtin/help.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/builtin/help.c b/builtin/help.c
>> index d1d7181..d10cbed 100644
>> --- a/builtin/help.c
>> +++ b/builtin/help.c
>> @@ -39,7 +39,7 @@ static int show_all = 0;
>> static unsigned int colopts;
>> static enum help_format help_format = HELP_FORMAT_NONE;
>> static struct option builtin_help_options[] = {
>> - OPT_BOOLEAN('a', "all", &show_all, N_("print all available
>> commands")),
>> + OPT_COUNTUP('a', "all", &show_all, N_("print all available
>> commands")),
>> 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"),
>> HELP_FORMAT_WEB),
^ permalink raw reply
* Re: [PATCH v2 3/5] Help.c add --guide option
From: Philip Oakley @ 2013-03-04 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vk3poyryc.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, March 03, 2013 11:38 PM
> Philip Oakley <philipoakley@iee.org> writes:
>
>> Logic, but no actions, included.
>
> I am not sure what you mean. Is that to break "bisect"?
>
> Ahh, you meant "command line is parsed but we do not actually show
> guides yet, which is done by later patches in this series". OK.
True. I can add to the commit message.
>
>> The --all commands option, if given, will display first.
>> The --guide option's list will then be displayed.
>>
>> The common commands list is only displayed if neither option,
>> nor a command or guide name, is given.
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> builtin/help.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/builtin/help.c b/builtin/help.c
>> index d10cbed..6089d72 100644
>> --- a/builtin/help.c
>> +++ b/builtin/help.c
>> @@ -36,10 +36,12 @@ enum help_format {
>> static const char *html_path;
>>
>> static int show_all = 0;
>> +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_COUNTUP('a', "all", &show_all, N_("print all available
>> commands")),
>> + OPT_COUNTUP('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"),
>> HELP_FORMAT_WEB),
>> @@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {
>> };
>>
>> static const char * const builtin_help_usage[] = {
>> - N_("git help [--all] [--man|--web|--info] [command]"),
>> + N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
>> NULL
>> };
>>
>> @@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const
>> char *prefix)
>> printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
>> list_commands(colopts, &main_cmds, &other_cmds);
>> printf("%s\n", _(git_more_info_string));
>> + if (!show_guides) return 0;
>> + }
>> + if (show_guides) {
>> return 0;
>> }
>> -
>
> Ugly.
I was trying to minimise the apparent changes, but like you say...
>
> if (show_all) {
> ... do not touch anything here ...
> ... but remove "return 0;" ...
> }
>
> if (show_guides) {
> ... show guides but do not "return 0" ...
> }
>
> if (show_all || show_guides) {
> ... we were asked to do either/or --all/--guides ...
> ... and have done what we were asked to do ...
> return 0;
> }
Neater.
>
> This is a tangent, but before all of the above, cmd_help() should
> verify that it got no arguments (when show_all/show_guides is in
> effect) or it got one argument (otherwise), I think.
>
>> if (!argv[0]) {
>> printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
>> list_common_cmds_help();
Seems reasonable. Should that be a separate preparatory patch (likely),
or joined in with the rest?
Philip
^ permalink raw reply
* [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
From: John Keeping @ 2013-03-04 0:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, git, Johan Herland, Lars Hjemli, Jason A. Donenfeld
In-Reply-To: <7vzjyk83gn.fsf@alter.siamese.dyndns.org>
This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
CGit uses these symbols to output the correct HTML around graph
elements. Making these symbols private means that CGit cannot be
updated to use Git 1.8.0 or newer, so let's not do that.
On top of the revert, also add comments so that we avoid reintroducing
this problem in the future and suggest to those modifying this API
that they might want to discuss it with the CGit developers.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
On Sun, Mar 03, 2013 at 03:32:08PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> > I think CGit expects to have to respond to changes in Git, so I don't
> > think it's worth restricting changes in Git for that reason - it's just
> > a case of exposing useful functionality somehow.
>
> I think you misread me.
You're right - this makes more sense that what I originally thought you
meant :-)
> It is not about restricting. It is to use their expertise to come up
> with generally more useful API than responding only to the immediate
> need we see in in-tree users. We want a discussion/patch to update
> the graph.c infrastructure to be Cc'ed to them.
>
> For example, with the current codeflow, the callers of these
> functions we have in-tree may be limited to those in graph.c but if
> there are legitimate reason CGit wants to call them from sideways,
> perhaps there may be use cases in our codebase in the future to call
> them from outside the normal graph.c codeflow.
graph.c | 32 ++------------------------------
graph.h | 33 +++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/graph.c b/graph.c
index 2a3fc5c..b24d04c 100644
--- a/graph.c
+++ b/graph.c
@@ -8,34 +8,6 @@
/* Internal API */
/*
- * Output the next line for a graph.
- * This formats the next graph line into the specified strbuf. It is not
- * terminated with a newline.
- *
- * Returns 1 if the line includes the current commit, and 0 otherwise.
- * graph_next_line() will return 1 exactly once for each time
- * graph_update() is called.
- */
-static int graph_next_line(struct git_graph *graph, struct strbuf *sb);
-
-/*
- * Set up a custom scheme for column colors.
- *
- * The default column color scheme inserts ANSI color escapes to colorize
- * the graph. The various color escapes are stored in an array of strings
- * where each entry corresponds to a color, except for the last entry,
- * which denotes the escape for resetting the color back to the default.
- * When generating the graph, strings from this array are inserted before
- * and after the various column characters.
- *
- * This function allows you to enable a custom array of color escapes.
- * The 'colors_max' argument is the index of the last "reset" entry.
- *
- * This functions must be called BEFORE graph_init() is called.
- */
-static void graph_set_column_colors(const char **colors, unsigned short colors_max);
-
-/*
* Output a padding line in the graph.
* This is similar to graph_next_line(). However, it is guaranteed to
* never print the current commit line. Instead, if the commit line is
@@ -90,7 +62,7 @@ enum graph_state {
static const char **column_colors;
static unsigned short column_colors_max;
-static void graph_set_column_colors(const char **colors, unsigned short colors_max)
+void graph_set_column_colors(const char **colors, unsigned short colors_max)
{
column_colors = colors;
column_colors_max = colors_max;
@@ -1144,7 +1116,7 @@ static void graph_output_collapsing_line(struct git_graph *graph, struct strbuf
graph_update_state(graph, GRAPH_PADDING);
}
-static int graph_next_line(struct git_graph *graph, struct strbuf *sb)
+int graph_next_line(struct git_graph *graph, struct strbuf *sb)
{
switch (graph->state) {
case GRAPH_PADDING:
diff --git a/graph.h b/graph.h
index 19b0f66..0be62bd 100644
--- a/graph.h
+++ b/graph.h
@@ -4,6 +4,25 @@
/* A graph is a pointer to this opaque structure */
struct git_graph;
+/*
+ * Set up a custom scheme for column colors.
+ *
+ * The default column color scheme inserts ANSI color escapes to colorize
+ * the graph. The various color escapes are stored in an array of strings
+ * where each entry corresponds to a color, except for the last entry,
+ * which denotes the escape for resetting the color back to the default.
+ * When generating the graph, strings from this array are inserted before
+ * and after the various column characters.
+ *
+ * This function allows you to enable a custom array of color escapes.
+ * The 'colors_max' argument is the index of the last "reset" entry.
+ *
+ * This functions must be called BEFORE graph_init() is called.
+ *
+ * NOTE: This function isn't used in Git outside graph.c but it is used
+ * by CGit (http://git.zx2c4.com/cgit/) to use HTML for colors.
+ */
+void graph_set_column_colors(const char **colors, unsigned short colors_max);
/*
* Create a new struct git_graph.
@@ -33,6 +52,20 @@ void graph_update(struct git_graph *graph, struct commit *commit);
*/
int graph_is_commit_finished(struct git_graph const *graph);
+/*
+ * Output the next line for a graph.
+ * This formats the next graph line into the specified strbuf. It is not
+ * terminated with a newline.
+ *
+ * Returns 1 if the line includes the current commit, and 0 otherwise.
+ * graph_next_line() will return 1 exactly once for each time
+ * graph_update() is called.
+ *
+ * NOTE: This function isn't used in Git outside graph.c but it is used
+ * by CGit (http://git.zx2c4.com/cgit/) to wrap HTML around graph lines.
+ */
+int graph_next_line(struct git_graph *graph, struct strbuf *sb);
+
/*
* graph_show_*: helper functions for printing to stdout
--
1.8.2.rc1.339.g93ec2c9
^ permalink raw reply related
* Re: [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Junio C Hamano @ 2013-03-04 0:05 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <EE36F065A5DA4769989FC7345DF7BCE6@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
>> Hrm, I do not recall anybody ever declared that "--all" is deprecated.
>
> No, it was the use OPT_COUNTUP rather than OPT_BOOLEAN that the
> deprecated' was refering to.
Oh, no OPT_BOOLEAN was deprecated because too many people rightfully
thought it was about 0/1 choice and got burned by its count-up
behaviour. When you want to count-up, OPT_COUNTUP is the right
thing to do and replacing deprecated BOOLEAN with it is a correct
thing to do. But for this optoin, I do not think you want to count
up in the first place. You want a 0/1 choice, which is written as
OPT_BOOL these days.
^ permalink raw reply
* Re: [PATCH] submodule update: when using recursion, show full path
From: Jens Lehmann @ 2013-03-04 0:06 UTC (permalink / raw)
To: William Entriken
Cc: git, Phil Hord, Stefan Zager, William Entriken, Junio C Hamano
In-Reply-To: <1362253499-48847-1-git-send-email-github.com@phor.net>
Am 02.03.2013 20:44, schrieb William Entriken:
> Previously when using update with recursion, only the path for the
> inner-most module was printed. Now the path is printed relative to
> the directory the command was started from. This now matches the
> behavior of submodule foreach.
>
> Signed-off-by: William Entriken <github.com@phor.net>
Thanks, this patch cleanly applies against maint and addresses all
issues from the previous rounds.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Junio, could you please squash in this additional test?
--------8<-------
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index feaec6c..70528b7 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -612,7 +612,8 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
rm -rf super_update_r2 &&
git clone super_update_r super_update_r2 &&
(cd super_update_r2 &&
- git submodule update --init --recursive &&
+ git submodule update --init --recursive >actual &&
+ test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
(cd submodule/subsubmodule &&
git log > ../../expected
) &&
^ permalink raw reply related
* Re: [PATCH v2 5/5] Help doc: Include --guide option description
From: Philip Oakley @ 2013-03-04 0:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vd2vgyrxh.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, March 03, 2013 11:39 PM
> Philip Oakley <philipoakley@iee.org> writes:
>
>> Note that the ability to display an individual guide was
>> always possible. Include this in the update.
>>
>> Also tell readers how git(1) can be accessed, especially for
>> Git for Windows users who do not have the 'man' command.
>> Likewise include a commentary on how to access this page (Catch 22).
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> Documentation/git-help.txt | 28 +++++++++++++++++++++-------
>> 1 file changed, 21 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
>> index e07b6dc..498a94e 100644
>> --- a/Documentation/git-help.txt
>> +++ b/Documentation/git-help.txt
>> @@ -8,31 +8,45 @@ git-help - Display help information about Git
>> SYNOPSIS
>> --------
>> [verse]
>> -'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
>> +'git help' [-a|--all] [-g|--guide]
>> + [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
>>
>> DESCRIPTION
>> -----------
>>
>> -With no options and no COMMAND given, the synopsis of the 'git'
>> +With no options and no COMMAND|GUIDE given, the synopsis of the
>> 'git'
>
> Please avoid BNF in the prose meant for human consumption unless
> necessary. I think you can just say " or " here.
OK
>
>> command and a list of the most commonly used Git commands are
>> printed
>> on the standard output.
>>
>> If the option '--all' or '-a' is given, then all available commands
>> are
>> printed on the standard output.
>>
>> -If a Git subcommand is named, a manual page for that subcommand 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 the option '--guide' or '-g' is given then, a list of the useful
>> +Git guides is also printed on the standard output.
>
> s/given then,/given, then/ or just s/ then// make it easier to
> follow? I personally would vote for doing s/given, then/given, /
> for the previous paragraph on "--all" as well.
Agreed.
>
>> -Note that `git --help ...` is identical to `git help ...` because
>> the
>> +If a Git subcommand, or a Git guide, is given, a manual page for
>> that
>
> "If the name of a command or a guide is given" without "Git/git"
> would be much easier to read, especially when the first paragraph
> talks about "COMMAND or GUIDE". I also think s/command/subcommand/
> in the synopsis and in the first paragraph may be good for consistency
> with this part.
OK
>
>> +subcommand is brought up. The 'man' program is used by default for
>> this
>> +purpose, but this can be overridden by other options or
>> configuration
>> +variables.
>> +
>> +Note that 'git --help ...' is identical to 'git help ...' because
>> the
>> former is internally converted into the latter.
>>
>> +To display the linkgit:git[1] man page use 'git help git'.
>
> s/man page use/man page, use/;
Yes.
>
>> +
>> +This page can be displayed with 'git help help' or 'git help --help'
>> +
>> OPTIONS
>> -------
>> -a::
>> --all::
>> Prints all the available commands on the standard output. This
>> - option supersedes any other option.
>> + option overides any given command or guide name.
>> +
>> +-g::
>> +--guides::
>> + Prints a list of useful guides on the standard output. This
>> + option overides any given command or guide name.
>
> Thanks. Overall this round looks a lot more manageable than the
> previous one.
>
Thanks. It'll be a few days (or maybe more) for the update.
[My Linux laptop (for checking everything) was just pressed into service
for my son's university studies while his regular one is in repair]
Philip
^ permalink raw reply
* Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
From: Jason A. Donenfeld @ 2013-03-04 0:12 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <20130304000337.GP7738@serenity.lan>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
On Sun, Mar 3, 2013 at 7:03 PM, John Keeping <john@keeping.me.uk> wrote:
> This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>
> CGit uses these symbols to output the correct HTML around graph
> elements. Making these symbols private means that CGit cannot be
> updated to use Git 1.8.0 or newer, so let's not do that.
>
> On top of the revert, also add comments so that we avoid reintroducing
> this problem in the future and suggest to those modifying this API
> that they might want to discuss it with the CGit developers.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> On Sun, Mar 03, 2013 at 03:32:08PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>> > I think CGit expects to have to respond to changes in Git, so I don't
>> > think it's worth restricting changes in Git for that reason - it's just
>> > a case of exposing useful functionality somehow.
>>
>> I think you misread me.
>
> You're right - this makes more sense that what I originally thought you
> meant :-)
>
>> It is not about restricting. It is to use their expertise to come up
>> with generally more useful API than responding only to the immediate
>> need we see in in-tree users. We want a discussion/patch to update
>> the graph.c infrastructure to be Cc'ed to them.
>>
>> For example, with the current codeflow, the callers of these
>> functions we have in-tree may be limited to those in graph.c but if
>> there are legitimate reason CGit wants to call them from sideways,
>> perhaps there may be use cases in our codebase in the future to call
>> them from outside the normal graph.c codeflow.
>
> graph.c | 32 ++------------------------------
> graph.h | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 30 deletions(-)
>
> diff --git a/graph.c b/graph.c
> index 2a3fc5c..b24d04c 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -8,34 +8,6 @@
> /* Internal API */
>
> /*
> - * Output the next line for a graph.
> - * This formats the next graph line into the specified strbuf. It is not
> - * terminated with a newline.
> - *
> - * Returns 1 if the line includes the current commit, and 0 otherwise.
> - * graph_next_line() will return 1 exactly once for each time
> - * graph_update() is called.
> - */
> -static int graph_next_line(struct git_graph *graph, struct strbuf *sb);
> -
> -/*
> - * Set up a custom scheme for column colors.
> - *
> - * The default column color scheme inserts ANSI color escapes to colorize
> - * the graph. The various color escapes are stored in an array of strings
> - * where each entry corresponds to a color, except for the last entry,
> - * which denotes the escape for resetting the color back to the default.
> - * When generating the graph, strings from this array are inserted before
> - * and after the various column characters.
> - *
> - * This function allows you to enable a custom array of color escapes.
> - * The 'colors_max' argument is the index of the last "reset" entry.
> - *
> - * This functions must be called BEFORE graph_init() is called.
> - */
> -static void graph_set_column_colors(const char **colors, unsigned short colors_max);
> -
> -/*
> * Output a padding line in the graph.
> * This is similar to graph_next_line(). However, it is guaranteed to
> * never print the current commit line. Instead, if the commit line is
> @@ -90,7 +62,7 @@ enum graph_state {
> static const char **column_colors;
> static unsigned short column_colors_max;
>
> -static void graph_set_column_colors(const char **colors, unsigned short colors_max)
> +void graph_set_column_colors(const char **colors, unsigned short colors_max)
> {
> column_colors = colors;
> column_colors_max = colors_max;
> @@ -1144,7 +1116,7 @@ static void graph_output_collapsing_line(struct git_graph *graph, struct strbuf
> graph_update_state(graph, GRAPH_PADDING);
> }
>
> -static int graph_next_line(struct git_graph *graph, struct strbuf *sb)
> +int graph_next_line(struct git_graph *graph, struct strbuf *sb)
> {
> switch (graph->state) {
> case GRAPH_PADDING:
> diff --git a/graph.h b/graph.h
> index 19b0f66..0be62bd 100644
> --- a/graph.h
> +++ b/graph.h
> @@ -4,6 +4,25 @@
> /* A graph is a pointer to this opaque structure */
> struct git_graph;
>
> +/*
> + * Set up a custom scheme for column colors.
> + *
> + * The default column color scheme inserts ANSI color escapes to colorize
> + * the graph. The various color escapes are stored in an array of strings
> + * where each entry corresponds to a color, except for the last entry,
> + * which denotes the escape for resetting the color back to the default.
> + * When generating the graph, strings from this array are inserted before
> + * and after the various column characters.
> + *
> + * This function allows you to enable a custom array of color escapes.
> + * The 'colors_max' argument is the index of the last "reset" entry.
> + *
> + * This functions must be called BEFORE graph_init() is called.
> + *
> + * NOTE: This function isn't used in Git outside graph.c but it is used
> + * by CGit (http://git.zx2c4.com/cgit/) to use HTML for colors.
> + */
> +void graph_set_column_colors(const char **colors, unsigned short colors_max);
>
> /*
> * Create a new struct git_graph.
> @@ -33,6 +52,20 @@ void graph_update(struct git_graph *graph, struct commit *commit);
> */
> int graph_is_commit_finished(struct git_graph const *graph);
>
> +/*
> + * Output the next line for a graph.
> + * This formats the next graph line into the specified strbuf. It is not
> + * terminated with a newline.
> + *
> + * Returns 1 if the line includes the current commit, and 0 otherwise.
> + * graph_next_line() will return 1 exactly once for each time
> + * graph_update() is called.
> + *
> + * NOTE: This function isn't used in Git outside graph.c but it is used
> + * by CGit (http://git.zx2c4.com/cgit/) to wrap HTML around graph lines.
> + */
> +int graph_next_line(struct git_graph *graph, struct strbuf *sb);
> +
>
> /*
> * graph_show_*: helper functions for printing to stdout
> --
> 1.8.2.rc1.339.g93ec2c9
>
^ permalink raw reply
* Re: [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Philip Oakley @ 2013-03-04 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7v4ngsyqpx.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Monday, March 04, 2013 12:05 AM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> Hrm, I do not recall anybody ever declared that "--all" is
>>> deprecated.
>>
>> No, it was the use OPT_COUNTUP rather than OPT_BOOLEAN that the
>> deprecated' was refering to.
>
> Oh, no OPT_BOOLEAN was deprecated because too many people rightfully
> thought it was about 0/1 choice and got burned by its count-up
> behaviour. When you want to count-up, OPT_COUNTUP is the right
> thing to do and replacing deprecated BOOLEAN with it is a correct
> thing to do. But for this optoin, I do not think you want to count
> up in the first place. You want a 0/1 choice, which is written as
> OPT_BOOL these days.
Ah, I missed that.
Though, for the longer term --guides usage, I'd envisaged that having it
a second time could be used to invoke some extra search code that would
list all guides, rather than just the short list of common guides. But
I'm not sure how best to determine what are valid guides, including
Msysgit/Git4Windows which only uses the html versions (no man command),
so I'll use OPT_BOOL initially.
Philip
^ permalink raw reply
* Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
From: Johan Herland @ 2013-03-04 0:52 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Thomas Rast, git, Lars Hjemli, Jason A. Donenfeld
In-Reply-To: <20130304000337.GP7738@serenity.lan>
On Mon, Mar 4, 2013 at 1:03 AM, John Keeping <john@keeping.me.uk> wrote:
> This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>
> CGit uses these symbols to output the correct HTML around graph
> elements. Making these symbols private means that CGit cannot be
> updated to use Git 1.8.0 or newer, so let's not do that.
>
> On top of the revert, also add comments so that we avoid reintroducing
> this problem in the future and suggest to those modifying this API
> that they might want to discuss it with the CGit developers.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
Still-Acked-by: Johan Herland <johan@herland.net>
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] submodule update: when using recursion, show full path
From: Junio C Hamano @ 2013-03-04 3:48 UTC (permalink / raw)
To: Jens Lehmann
Cc: William Entriken, git, Phil Hord, Stefan Zager, William Entriken
In-Reply-To: <5133E570.7030507@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 02.03.2013 20:44, schrieb William Entriken:
>> Previously when using update with recursion, only the path for the
>> inner-most module was printed. Now the path is printed relative to
>> the directory the command was started from. This now matches the
>> behavior of submodule foreach.
>>
>> Signed-off-by: William Entriken <github.com@phor.net>
>
> Thanks, this patch cleanly applies against maint and addresses all
> issues from the previous rounds.
>
> Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
>
> Junio, could you please squash in this additional test?
Thanks.
I wish all areas of Git had competent and diligent area maintainers
like you. Makes it a lot easier for me _not_ to keep track of ;-).
>
> --------8<-------
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index feaec6c..70528b7 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -612,7 +612,8 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
> rm -rf super_update_r2 &&
> git clone super_update_r super_update_r2 &&
> (cd super_update_r2 &&
> - git submodule update --init --recursive &&
> + git submodule update --init --recursive >actual &&
> + test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
> (cd submodule/subsubmodule &&
> git log > ../../expected
> ) &&
^ permalink raw reply
* Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
From: Junio C Hamano @ 2013-03-04 3:42 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: John Keeping, Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <CAHmME9oAiZDcAeMCE=haUmC9yeC0crZCKB-WrxQ3CVd1YrBdHQ@mail.gmail.com>
"Jason A. Donenfeld" <Jason@zx2c4.com> writes:
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
I suspect that many people outside CGit circle may not know who this
Jason (who never appeared in git@vger.kernel.org) is, and are
wondering in what capacity he is sending a S-o-b for somebody else's
patch without explanation. An inroduction may help others (as can
be seen on Cc: line, I added Lars there because I didn't even know
he was still the man behind CGit).
Later last year, the project was taken over by an active contributor
with the other active contributor (Ferry Huberts)'s support and then
later with Lars's blessing:
http://hjemli.net/pipermail/cgit/2013-January/000884.html
That active contributor is Jason. The repository has also been moved
to Jason's http://git.zx2c4.com/cgit/ even though mailing list and
its archive seem to be still suported by Lars's hjemli.net. And the
latest CGit 0.9.1 was release mid November 2012 by him.
John Keeping has been actively working on making sure that CGit
works with newer codebase for the past couple of days, until he
found out that after our v1.7.12.4 some symbols were unavailable to
him from us X-< which triggered this topic. Jason's S-o-b as the
CGit maintainer is certainly appropriate for this patch.
So, thanks, Jason and John for your efforts.
^ permalink raw reply
* Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
From: Jason A. Donenfeld @ 2013-03-04 4:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <7vzjyjygnd.fsf@alter.siamese.dyndns.org>
On Sun, Mar 3, 2013 at 10:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I suspect that many people outside CGit circle may not know who this
> Jason
> That active contributor is Jason. The repository has also been moved
> to Jason's http://git.zx2c4.com/cgit/
> So, thanks, Jason and John for your efforts.
Hey folks,
Sorry for not providing the explanation myself, but Junio -- thanks
for introducing me!
Jason
^ permalink raw reply
* [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Eric Cousineau @ 2013-03-04 8:41 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
In this patch, foreach --recursive acts depth-first, much like the default
behavior described in the patch by Imram Yousuf in this
post <http://marc.info/?l=git&m=121066084508631&w=2>.
Changes were made so that the submodule "Entering ..." message was right
next to the output generated by the command too.
It also adds the --parent option for executing the command in the
supermodule as well.
I began by adding a --depth option, to preserve the original --recursive
behavior, and the --parent option, and trying to get that to work. However,
I pretty much confused myself for a while trying to straighten that out, so
I just ended up modifying the --recursive behavior.
If the --recursive behavior should be preserved, I could add the --depth
option back and only have --parent affect non-recursive and --depth
recursive behavior.
I had kind-of implemented this behavior with aliases / bash functions
(posted to pastebin <http://pastebin.com/yLHe9XWy>
, spurned by a
question I asked in StackOverflow <http://stackoverflow.com/q/14846967/170413>),
however I would always run into issues with escaping characters when
passing from the bash functions to git aliases (i.e., putting "'ello" as an
test commit message). I also tried out mb14's method from the StackOverflow
post, but I ran into the same issues.
Figured the best way to avoid that was to cut out the extra layers.
I've attached a test script to generate the tree that VonC suggested with
output showing the iteration.
[-- Attachment #2: 0001-area-submodules.patch --]
[-- Type: application/octet-stream, Size: 2196 bytes --]
From 851d65fcfb8f49131428a57fc318af7b56416430 Mon Sep 17 00:00:00 2001
From: eacousineau <eacousineau@gmail.com>
Date: Mon, 4 Mar 2013 01:08:07 -0600
Subject: [PATCH] area: submodules Make foreach --recursive do depth-first.
Make foreach --parent [--recursive] execute command in toplevel supermodule
Signed-off-by: Eric Cousineau <eacousineau@gmail.com>
---
git-submodule.sh | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..721c959 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -434,6 +434,9 @@ Use -f if you really want to add it." >&2
cmd_foreach()
{
# parse $args after "submodule ... foreach".
+ # Gratuitous local's to prevent recursive bleeding
+ local parent=
+ local recursive=
while test $# -ne 0
do
case "$1" in
@@ -443,6 +446,10 @@ cmd_foreach()
--recursive)
recursive=1
;;
+ --parent)
+ # Execute command in parent, after children commands are executed
+ parent=1
+ ;;
-*)
usage
;;
@@ -464,8 +471,8 @@ cmd_foreach()
do
die_if_unmatched "$mode"
if test -e "$sm_path"/.git
- then
- say "$(eval_gettext "Entering '\$prefix\$sm_path'")"
+ then
+ local message="$(eval_gettext "Entering '\$prefix\$sm_path'")"
name=$(module_name "$sm_path")
(
prefix="$prefix$sm_path/"
@@ -473,15 +480,29 @@ cmd_foreach()
# we make $path available to scripts ...
path=$sm_path
cd "$sm_path" &&
- eval "$@" &&
if test -n "$recursive"
then
cmd_foreach "--recursive" "$@"
- fi
+ fi &&
+ (
+ # Put message here so it stays somewhat tidy -- hopefully OK since prefixes are included
+ say "$message"
+ eval "$@"
+ )
) <&3 3<&- ||
die "$(eval_gettext "Stopping at '\$sm_path'; script returned non-zero status.")"
fi
- done
+ done &&
+ (
+ if test -n "$parent"
+ then
+ name=$(basename "$toplevel")
+ clear_local_git_env
+ path=.
+ say "$(eval_gettext "Entering '\$name'")" # Not sure of proper thing here
+ eval "$@" || die "$(eval_gettext "Stopping at supermodule; script returned non-zero status.")"
+ fi
+ )
}
#
--
1.8.2.rc1.24.g06d67b8
[-- Attachment #3: test.sh --]
[-- Type: application/x-sh, Size: 849 bytes --]
^ permalink raw reply related
* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Matthieu Moy @ 2013-03-04 8:56 UTC (permalink / raw)
To: Michael Haggerty
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <vpqfw0rb25c.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> A few more random thoughts (not on my personal todo-list):
One more:
When sending commit emails, it may help to ensure that the dates are
strictly monotonic, so that the thread is seen in the right order.
IIRC, "git send-email" does this by tweaking the Date: field to make
sure there is at least one second between two emails (although they may
be actually sent at the same second). It would be cool to have the same
for git multimail.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox