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

[Junio C Hamano]

Joel Nothman  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  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);
> +
> + 

[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  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)
 {
i

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

[Philip Oakley]

From: "Junio C Hamano" 

Philip Oakley  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 ' 
processing always assumes that the target is a man page, and that the 
page name will always be 'git. 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

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

[Junio C Hamano]

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

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

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
 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

[PATCH] log: add --show-linear-break to help see non-linear history

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

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 This is a more serious attempt to make non-linear history more
 visible without --graph. It looks like this

commit e4ddb05720710213108cd13ddd5a115e12a6211d
Author: Andy Spencer 

tree_entry_interesting: match against all pathspecs

..

commit a0332337be53f266682279c72a5e553986638c87
Author: Jeff King 

t7700: do not use "touch" unnecessarily

commit 088304bf73b9b4149e04d2246fe08a06eef6e795
Author: Jeff King 

t7501: fix "empty commit" test with NO_PERL

..

commit 74b4f7f27736f3e196a4eb3db41c68e37a6e2160
Author: Nguyễn Thái Ngọc Duy 

tree-walk.c: ignore trailing slash on submodule in 
tree_entry_interesting()

 You can use fancier break bars from [1] instead of plain dots. I'm
 not sure it works with all combinations of rev-list. But at least
 log (with/out pathspec) and log --reverse work.
 
 [1] http://www.ascii-art.de/ascii/ab/border.txt

 Documentation/rev-list-options.txt |  7 +
 log-tree.c |  4 +++
 revision.c | 52 +++---
 revision.h |  6 +
 4 files changed, 66 insertions(+), 3 deletions(-)

diff --git a/Documentation/rev-list-options.txt 
b/Documentation/rev-list-options.txt
index 03533af..a0780be 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -750,6 +750,13 @@ This enables parent rewriting, see 'History 
Simplification' below.
 This implies the `--topo-order` option by default, but the
 `--date-order` option may also be specified.
 
+--show-linear-break[=]::
+   When --graph is not used, all history branches are flatten and
+   could be hard to see that the two consecutive commits do not
+   belong to a linear branch. This option puts a break bar in
+   between them in that case. If `` is specified, it
+   is the string that will be shown instead of the default one.
+
 ifdef::git-rev-list[]
 --count::
Print a number stating how many commits would have been
diff --git a/log-tree.c b/log-tree.c
index 08970bf..17862f6 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -805,12 +805,16 @@ int log_tree_commit(struct rev_info *opt, struct commit 
*commit)
if (opt->line_level_traverse)
return line_log_print(opt, commit);
 
+   if (opt->track_linear && !opt->linear && !opt->reverse_output_stage)
+   printf("\n%s\n", opt->break_bar);
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
log.parent = NULL;
show_log(opt);
shown = 1;
}
+   if (opt->track_linear && !opt->linear && opt->reverse_output_stage)
+   printf("\n%s\n", opt->break_bar);
opt->loginfo = NULL;
maybe_flush_or_die(stdout, "stdout");
return shown;
diff --git a/revision.c b/revision.c
index a0df72f..ff3107f 100644
--- a/revision.c
+++ b/revision.c
@@ -1836,6 +1836,12 @@ static int handle_revision_opt(struct rev_info *revs, 
int argc, const char **arg
revs->notes_opt.use_default_notes = 1;
} else if (!strcmp(arg, "--show-signature")) {
revs->show_signature = 1;
+   } else if (!strcmp(arg, "--show-linear-break")) {
+   revs->track_linear = 1;
+   revs->break_bar = "..";
+   } else if (starts_with(arg, "--show-linear-break=")) {
+   revs->track_linear = 1;
+   revs->break_bar = xstrdup(arg + 20);
} else if (starts_with(arg, "--show-notes=") ||
   starts_with(arg, "--notes=")) {
struct strbuf buf = STRBUF_INIT;
@@ -2901,6 +2907,32 @@ enum commit_action simplify_commit(struct rev_info 
*revs, struct commit *commit)
return action;
 }
 
+define_commit_slab(saved_linear, int);
+
+static void track_linear(struct rev_info *revs, struct commit *commit)
+{
+   struct commit_list *p = revs->previous_parents;
+
+   if (p) {
+   int got_parent = 0;
+   for (; p && !got_parent; p = p->next)
+   got_parent = !hashcmp(p->item->object.sha1,
+ commit->object.sha1);
+   revs->linear = got_parent;
+   free_commit_list(revs->previous_parents);
+   } else
+   revs->linear = 1;
+   if (revs->reverse) {
+   if (!revs->saved_linear_slab) {
+   revs->saved_linear_slab = xmalloc(sizeof(struct 
saved_linear));
+   init_saved_linear(revs->saved_linear_slab);
+   }
+
+   *saved_linear_at(revs->saved_linear_slab, commit) = 
revs->linear;
+   }
+   revs->previous_parents = copy_commit_list(commit->parents);
+}
+
 stat

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

[Philip Oakley]

From: "Junio C Hamano" 

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

[Junio C Hamano]

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

[Philip Oakley]

From: "Junio C Hamano" 

"Philip Oakley"  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"  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: "Stefan Näwe" 

Am 16.01.2014 22:14, schrieb Philip Oakley:

From: "Stefan Näwe" 
[...]


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

[Stefan Näwe]

Am 16.01.2014 22:14, schrieb Philip Oakley:
> From: "Stefan Näwe" 
> [...]
>>
>> 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" 
[...]


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 2/2] pull: add --ff-only to the help text

[David Aguilar]

Signed-off-by: David Aguilar 
---
 git-pull.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-pull.sh b/git-pull.sh
index 7dbf6b1..68b2e40 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
 #
 # Fetch one or more remote refs and merge it/them into the current HEAD.
 
-USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff] 
[--[no-]rebase|--rebase=preserve] [-s strategy]... []  
...'
+USAGE='[-n | --no-stat] [--[no-]commit] [--[no-]squash] [--[no-]ff|--ff-only] 
[--[no-]rebase|--rebase=preserve] [-s strategy]... []  
...'
 LONG_USAGE='Fetch one or more remote refs and integrate it/them with the 
current HEAD.'
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
-- 
1.8.5.3.322.g71d2a99

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

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 

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

[Philip Oakley]

From: "Junio C Hamano" 

"Philip Oakley"  writes:


From: "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.


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" 

"Philip Oakley"  writes:


From: "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.


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

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

[Junio C Hamano]

"Philip Oakley"  writes:

> From: "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.
>
> 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

[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

[Philip Oakley]

From: "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.


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

[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

[PATCH 5/6] add 'everyday' to the help --guides list

[Philip Oakley]

Signed-off-by: Philip Oakley 
---
 builtin/help.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/help.c b/builtin/help.c
index cc17e67..45509ce 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -418,6 +418,7 @@ static struct {
const char *help;
 } common_guides[] = {
{ "attributes", N_("Defining attributes per path") },
+   { "everyday", N_("Everyday Git With 20 Commands Or So") },
{ "glossary", N_("A Git glossary") },
{ "ignore", N_("Specifies intentionally untracked files to ignore") },
{ "modules", N_("Defining submodule properties") },
-- 
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 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

[PATCH v3 8/9] test-hg.sh: help user correlate verbose output with email test

[Richard Hansen]

It's hard to tell which author conversion test failed when the email
addresses look similar.

Signed-off-by: Richard Hansen 
Reviewed-by: Felipe Contreras 
---
 contrib/remote-helpers/test-hg.sh | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contrib/remote-helpers/test-hg.sh 
b/contrib/remote-helpers/test-hg.sh
index eb72db8..642ad93 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -206,16 +206,16 @@ test_expect_success 'authors' '
 
>../expected &&
author_test alpha "" "H G Wells " &&
-   author_test beta "test" "test " &&
-   author_test gamma "test  (comment)" "test 
" &&
-   author_test delta "" "Unknown " &&
-   author_test epsilon "name" "name " 
&&
-   author_test zeta "name " &&
-   author_test eta " test " "test " &&
-   author_test theta "test < t...@example.com >" "test " 
&&
-   author_test iota "test >t...@example.com>" "test " &&
-   author_test kappa "test < test  example  com>" "test 
" &&
-   author_test lambda "t...@example.com" "Unknown "
+   author_test beta "beta" "beta " &&
+   author_test gamma "gamma  (comment)" "gamma 
" &&
+   author_test delta "" "Unknown " &&
+   author_test epsilon "epsilon" "epsilon 
" &&
+   author_test zeta "zeta " &&
+   author_test eta " eta " "eta " &&
+   author_test theta "theta < t...@example.com >" "theta 
" &&
+   author_test iota "iota >t...@example.com>" "iota " &&
+   author_test kappa "kappa < test  example  com>" "kappa 
" &&
+   author_test lambda "lam...@example.com" "Unknown "
) &&
 
git clone "hg::hgrepo" gitrepo &&
-- 
1.8.5.rc1.208.g8ff7964

--
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 8/9] test-hg.sh: help user correlate verbose output with email test

[Richard Hansen]

It's hard to tell which author conversion test failed when the email
addresses look similar.

Signed-off-by: Richard Hansen 
---
 contrib/remote-helpers/test-hg.sh | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contrib/remote-helpers/test-hg.sh 
b/contrib/remote-helpers/test-hg.sh
index eb72db8..642ad93 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -206,16 +206,16 @@ test_expect_success 'authors' '
 
>../expected &&
author_test alpha "" "H G Wells " &&
-   author_test beta "test" "test " &&
-   author_test gamma "test  (comment)" "test 
" &&
-   author_test delta "" "Unknown " &&
-   author_test epsilon "name" "name " 
&&
-   author_test zeta "name " &&
-   author_test eta " test " "test " &&
-   author_test theta "test < t...@example.com >" "test " 
&&
-   author_test iota "test >t...@example.com>" "test " &&
-   author_test kappa "test < test  example  com>" "test 
" &&
-   author_test lambda "t...@example.com" "Unknown "
+   author_test beta "beta" "beta " &&
+   author_test gamma "gamma  (comment)" "gamma 
" &&
+   author_test delta "" "Unknown " &&
+   author_test epsilon "epsilon" "epsilon 
" &&
+   author_test zeta "zeta " &&
+   author_test eta " eta " "eta " &&
+   author_test theta "theta < t...@example.com >" "theta 
" &&
+   author_test iota "iota >t...@example.com>" "iota " &&
+   author_test kappa "kappa < test  example  com>" "kappa 
" &&
+   author_test lambda "lam...@example.com" "Unknown "
) &&
 
git clone "hg::hgrepo" gitrepo &&
-- 
1.8.5.rc1.208.g8ff7964

--
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 6/7] test-hg.sh: help user correlate verbose output with email test

[Richard Hansen]

On 2013-11-11 14:29, Felipe Contreras wrote:
> On Mon, Nov 11, 2013 at 1:19 PM, Richard Hansen  wrote:
>> On 2013-11-11 06:42, Felipe Contreras wrote:
>>> Richard Hansen wrote:
 It's hard to tell which author conversion test failed when the email
 addresses look similar.

 Signed-off-by: Richard Hansen 
 ---
  contrib/remote-helpers/test-hg.sh | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

 diff --git a/contrib/remote-helpers/test-hg.sh 
 b/contrib/remote-helpers/test-hg.sh
 index 84c67ff..5eda265 100755
 --- a/contrib/remote-helpers/test-hg.sh
 +++ b/contrib/remote-helpers/test-hg.sh
 @@ -209,16 +209,16 @@ test_expect_success 'authors' '

  >../expected &&
  author_test alpha "" "H G Wells " &&
 -author_test beta "test" "test " &&
 -author_test beta "test  (comment)" "test 
 " &&
>>
>> Notice the two betas here in the original code.
> 
> Ahh, that's a bug.
> 
 -author_test gamma "" "Unknown " &&
 -author_test delta "name" "name " 
 &&
 -author_test epsilon "name >>> " &&
 -author_test zeta " test " "test " &&
 -author_test eta "test < t...@example.com >" "test " 
 &&
 -author_test theta "test >t...@example.com>" "test " 
 &&
 -author_test iota "test < test  example  com>" "test 
 " &&
 -author_test kappa "t...@example.com" "Unknown "
 +author_test beta "beta" "beta " &&
 +author_test beta "beta  (comment)" "beta 
 " &&
>>>
>>> Two betas?
>>
>> See above.  I can change them to beta1 and beta2, or if you'd prefer I
>> can change them to beta and gamma and increment the subsequent entries.
> 
> Yeah, I would prefer that in two patches, one that fixes the sequence,
> and the other one that changes the emails.

Will do.

Thanks,
Richard

> If you don't have time for
> that the original patch is OK by me. The problem with the sequence can
> be fixed later.
> 
> Cheers.
> 

--
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 6/7] test-hg.sh: help user correlate verbose output with email test

[Felipe Contreras]

On Mon, Nov 11, 2013 at 1:19 PM, Richard Hansen  wrote:
> On 2013-11-11 06:42, Felipe Contreras wrote:
>> Richard Hansen wrote:
>>> It's hard to tell which author conversion test failed when the email
>>> addresses look similar.
>>>
>>> Signed-off-by: Richard Hansen 
>>> ---
>>>  contrib/remote-helpers/test-hg.sh | 20 ++--
>>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/contrib/remote-helpers/test-hg.sh 
>>> b/contrib/remote-helpers/test-hg.sh
>>> index 84c67ff..5eda265 100755
>>> --- a/contrib/remote-helpers/test-hg.sh
>>> +++ b/contrib/remote-helpers/test-hg.sh
>>> @@ -209,16 +209,16 @@ test_expect_success 'authors' '
>>>
>>>  >../expected &&
>>>  author_test alpha "" "H G Wells " &&
>>> -author_test beta "test" "test " &&
>>> -author_test beta "test  (comment)" "test 
>>> " &&
>
> Notice the two betas here in the original code.

Ahh, that's a bug.

>>> -author_test gamma "" "Unknown " &&
>>> -author_test delta "name" "name " &&
>>> -author_test epsilon "name " 
>>> &&
>>> -author_test zeta " test " "test " &&
>>> -author_test eta "test < t...@example.com >" "test " 
>>> &&
>>> -author_test theta "test >t...@example.com>" "test " 
>>> &&
>>> -author_test iota "test < test  example  com>" "test 
>>> " &&
>>> -author_test kappa "t...@example.com" "Unknown "
>>> +author_test beta "beta" "beta " &&
>>> +author_test beta "beta  (comment)" "beta 
>>> " &&
>>
>> Two betas?
>
> See above.  I can change them to beta1 and beta2, or if you'd prefer I
> can change them to beta and gamma and increment the subsequent entries.

Yeah, I would prefer that in two patches, one that fixes the sequence,
and the other one that changes the emails. If you don't have time for
that the original patch is OK by me. The problem with the sequence can
be fixed later.

Cheers.

-- 
Felipe Contreras
--
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 6/7] test-hg.sh: help user correlate verbose output with email test

[Richard Hansen]

On 2013-11-11 06:42, Felipe Contreras wrote:
> Richard Hansen wrote:
>> It's hard to tell which author conversion test failed when the email
>> addresses look similar.
>>
>> Signed-off-by: Richard Hansen 
>> ---
>>  contrib/remote-helpers/test-hg.sh | 20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/contrib/remote-helpers/test-hg.sh 
>> b/contrib/remote-helpers/test-hg.sh
>> index 84c67ff..5eda265 100755
>> --- a/contrib/remote-helpers/test-hg.sh
>> +++ b/contrib/remote-helpers/test-hg.sh
>> @@ -209,16 +209,16 @@ test_expect_success 'authors' '
>>  
>>  >../expected &&
>>  author_test alpha "" "H G Wells " &&
>> -author_test beta "test" "test " &&
>> -author_test beta "test  (comment)" "test 
>> " &&

Notice the two betas here in the original code.

>> -author_test gamma "" "Unknown " &&
>> -author_test delta "name" "name " &&
>> -author_test epsilon "name " 
>> &&
>> -author_test zeta " test " "test " &&
>> -author_test eta "test < t...@example.com >" "test " &&
>> -author_test theta "test >t...@example.com>" "test " &&
>> -author_test iota "test < test  example  com>" "test " 
>> &&
>> -author_test kappa "t...@example.com" "Unknown "
>> +author_test beta "beta" "beta " &&
>> +author_test beta "beta  (comment)" "beta 
>> " &&
> 
> Two betas?

See above.  I can change them to beta1 and beta2, or if you'd prefer I
can change them to beta and gamma and increment the subsequent entries.

Thanks,
Richard

> 
>> +author_test gamma "" "Unknown " &&
>> +author_test delta "delta" "delta " 
>> &&
>> +author_test epsilon "epsilon > " &&
>> +author_test zeta " zeta " "zeta " &&
>> +author_test eta "eta < t...@example.com >" "eta " &&
>> +author_test theta "theta >t...@example.com>" "theta " 
>> &&
>> +author_test iota "iota < test  example  com>" "iota " 
>> &&
>> +author_test kappa "ka...@example.com" "Unknown "
>>  ) &&
>>  
>>  git clone "hg::hgrepo" gitrepo &&
> 

--
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 6/7] test-hg.sh: help user correlate verbose output with email test

[Felipe Contreras]

Richard Hansen wrote:
> It's hard to tell which author conversion test failed when the email
> addresses look similar.
> 
> Signed-off-by: Richard Hansen 
> ---
>  contrib/remote-helpers/test-hg.sh | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/contrib/remote-helpers/test-hg.sh 
> b/contrib/remote-helpers/test-hg.sh
> index 84c67ff..5eda265 100755
> --- a/contrib/remote-helpers/test-hg.sh
> +++ b/contrib/remote-helpers/test-hg.sh
> @@ -209,16 +209,16 @@ test_expect_success 'authors' '
>  
>   >../expected &&
>   author_test alpha "" "H G Wells " &&
> - author_test beta "test" "test " &&
> - author_test beta "test  (comment)" "test 
> " &&
> - author_test gamma "" "Unknown " &&
> - author_test delta "name" "name " &&
> - author_test epsilon "name " 
> &&
> - author_test zeta " test " "test " &&
> - author_test eta "test < t...@example.com >" "test " &&
> - author_test theta "test >t...@example.com>" "test " &&
> - author_test iota "test < test  example  com>" "test " 
> &&
> - author_test kappa "t...@example.com" "Unknown "
> + author_test beta "beta" "beta " &&
> + author_test beta "beta  (comment)" "beta 
> " &&

Two betas?

> + author_test gamma "" "Unknown " &&
> + author_test delta "delta" "delta " 
> &&
> + author_test epsilon "epsilon  " &&
> + author_test zeta " zeta " "zeta " &&
> + author_test eta "eta < t...@example.com >" "eta " &&
> + author_test theta "theta >t...@example.com>" "theta " 
> &&
> + author_test iota "iota < test  example  com>" "iota " 
> &&
> + author_test kappa "ka...@example.com" "Unknown "
>   ) &&
>  
>   git clone "hg::hgrepo" gitrepo &&

-- 
Felipe Contreras
--
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 6/7] test-hg.sh: help user correlate verbose output with email test

[Richard Hansen]

It's hard to tell which author conversion test failed when the email
addresses look similar.

Signed-off-by: Richard Hansen 
---
 contrib/remote-helpers/test-hg.sh | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contrib/remote-helpers/test-hg.sh 
b/contrib/remote-helpers/test-hg.sh
index 84c67ff..5eda265 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -209,16 +209,16 @@ test_expect_success 'authors' '
 
>../expected &&
author_test alpha "" "H G Wells " &&
-   author_test beta "test" "test " &&
-   author_test beta "test  (comment)" "test 
" &&
-   author_test gamma "" "Unknown " &&
-   author_test delta "name" "name " &&
-   author_test epsilon "name " 
&&
-   author_test zeta " test " "test " &&
-   author_test eta "test < t...@example.com >" "test " &&
-   author_test theta "test >t...@example.com>" "test " &&
-   author_test iota "test < test  example  com>" "test " 
&&
-   author_test kappa "t...@example.com" "Unknown "
+   author_test beta "beta" "beta " &&
+   author_test beta "beta  (comment)" "beta 
" &&
+   author_test gamma "" "Unknown " &&
+   author_test delta "delta" "delta " 
&&
+   author_test epsilon "epsilon " &&
+   author_test zeta " zeta " "zeta " &&
+   author_test eta "eta < t...@example.com >" "eta " &&
+   author_test theta "theta >t...@example.com>" "theta " 
&&
+   author_test iota "iota < test  example  com>" "iota " 
&&
+   author_test kappa "ka...@example.com" "Unknown "
) &&
 
git clone "hg::hgrepo" gitrepo &&
-- 
1.8.5.rc1.207.gc17dd22

--
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 22/86] help: replace prefixcmd() with has_prefix()

[Christian Couder]

Signed-off-by: Christian Couder 
---
 help.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/help.c b/help.c
index f068925..b41d2d5 100644
--- a/help.c
+++ b/help.c
@@ -148,7 +148,7 @@ static void list_commands_in_dir(struct cmdnames *cmds,
while ((de = readdir(dir)) != NULL) {
int entlen;
 
-   if (prefixcmp(de->d_name, prefix))
+   if (!has_prefix(de->d_name, prefix))
continue;
 
strbuf_setlen(&buf, len);
@@ -255,7 +255,7 @@ static int git_unknown_cmd_config(const char *var, const 
char *value, void *cb)
if (!strcmp(var, "help.autocorrect"))
autocorrect = git_config_int(var,value);
/* Also use aliases for command lookup */
-   if (!prefixcmp(var, "alias."))
+   if (has_prefix(var, "alias."))
add_cmdname(&aliases, var + 6, strlen(var + 6));
 
return git_default_config(var, value, cb);
@@ -329,7 +329,7 @@ const char *help_unknown_cmd(const char *cmd)
if ((n < ARRAY_SIZE(common_cmds)) && !cmp) {
/* Yes, this is one of the common commands */
n++; /* use the entry from common_cmds[] */
-   if (!prefixcmp(candidate, cmd)) {
+   if (has_prefix(candidate, cmd)) {
/* Give prefix match a very good score */
main_cmds.names[i]->len = 0;
continue;
@@ -414,7 +414,7 @@ static int append_similar_ref(const char *refname, const 
unsigned char *sha1,
struct similar_ref_cb *cb = (struct similar_ref_cb *)(cb_data);
char *branch = strrchr(refname, '/') + 1;
/* A remote branch of the same name is deemed similar */
-   if (!prefixcmp(refname, "refs/remotes/") &&
+   if (has_prefix(refname, "refs/remotes/") &&
!strcmp(branch, cb->base_ref))
string_list_append(cb->similar_refs,
   refname + strlen("refs/remotes/"));
-- 
1.8.4.1.566.geca833c


--
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 60/86] builtin/help: replace prefixcmd() with has_prefix()

[Christian Couder]

Signed-off-by: Christian Couder 
---
 builtin/help.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/builtin/help.c b/builtin/help.c
index f1e236b..2478e9a 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -100,7 +100,7 @@ static int check_emacsclient_version(void)
 */
finish_command(&ec_process);
 
-   if (prefixcmp(buffer.buf, "emacsclient")) {
+   if (!has_prefix(buffer.buf, "emacsclient")) {
strbuf_release(&buffer);
return error(_("Failed to parse emacsclient version."));
}
@@ -258,7 +258,7 @@ static int add_man_viewer_info(const char *var, const char 
*value)
 
 static int git_help_config(const char *var, const char *value, void *cb)
 {
-   if (!prefixcmp(var, "column."))
+   if (has_prefix(var, "column."))
return git_column_config(var, value, "help", &colopts);
if (!strcmp(var, "help.format")) {
if (!value)
@@ -278,7 +278,7 @@ static int git_help_config(const char *var, const char 
*value, void *cb)
add_man_viewer(value);
return 0;
}
-   if (!prefixcmp(var, "man."))
+   if (has_prefix(var, "man."))
return add_man_viewer_info(var, value);
 
return git_default_config(var, value, cb);
@@ -306,7 +306,7 @@ static const char *cmd_to_page(const char *git_cmd)
 {
if (!git_cmd)
return "git";
-   else if (!prefixcmp(git_cmd, "git"))
+   else if (has_prefix(git_cmd, "git"))
return git_cmd;
else if (is_git_command(git_cmd))
return prepend("git-", git_cmd);
-- 
1.8.4.1.566.geca833c


--
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: Help creating git alias

[Eugene Sajine]

On Thu, Oct 31, 2013 at 3:41 PM, Junio C Hamano  wrote:
> Eugene Sajine  writes:
>
>> One note: i tried the ${GIT_PREFIX:-.}  and ${GIT_PREFIX} and it seems
>> to give the same results. What is the expected difference here?
>
> GIT_PREFIX may be an empty string when you run from the top-level,
> in which case you would end up with "cd && ..." and end up working
> in your $HOME.
>


got it! thank you!

Eugene
--
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: Help creating git alias

[Junio C Hamano]

Eugene Sajine  writes:

> One note: i tried the ${GIT_PREFIX:-.}  and ${GIT_PREFIX} and it seems
> to give the same results. What is the expected difference here?

GIT_PREFIX may be an empty string when you run from the top-level,
in which case you would end up with "cd && ..." and end up working
in your $HOME.

--
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: Help creating git alias

[Eugene Sajine]

On Thu, Oct 31, 2013 at 2:15 PM, David Aguilar  wrote:
> On Thu, Oct 31, 2013 at 11:07:19AM -0700, Junio C Hamano wrote:
>> David Aguilar  writes:
>>
>> > A-ha.. I think adding the chdir to alias is possible using a function.
>>
>> You do not have to use a function to do so, no?
>
> Right, of course.
>
> So something like:
>
> [alias]
> example = "!cd ${GIT_PREFIX:-.} && git log \"$@\""
>
> should do the trick.
> --
> David


Awesome! It does work!
One note: i tried the ${GIT_PREFIX:-.}  and ${GIT_PREFIX} and it seems
to give the same results. What is the expected difference here?

Thank you!
--
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: Help creating git alias

[David Aguilar]

On Thu, Oct 31, 2013 at 11:07:19AM -0700, Junio C Hamano wrote:
> David Aguilar  writes:
> 
> > A-ha.. I think adding the chdir to alias is possible using a function.
> 
> You do not have to use a function to do so, no?

Right, of course.

So something like:

[alias]
example = "!cd ${GIT_PREFIX:-.} && git log \"$@\""

should do the trick.
-- 
David
--
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: Help creating git alias

[Junio C Hamano]

David Aguilar  writes:

> A-ha.. I think adding the chdir to alias is possible using a function.

You do not have to use a function to do so, no?
--
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: Help creating git alias

[David Aguilar]

On Thu, Oct 31, 2013 at 11:36:59AM -0400, Eugene Sajine wrote:
> On Wed, Oct 30, 2013 at 11:54 PM, Junio C Hamano  wrote:
> > Eugene Sajine  writes:
> >
> >> That was my initial intention, because I would like to be able to pass
> >> parameters like to git log or git blame correctly without the explicit
> >> use of $1. Could you please advise about how to make it work with the
> >> !sh -c ?
> >>
> >> Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c".
> >
> > You can make it work if you think step-by-step.  First, this is what
> > you want to run:
> >
> > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' -
> >
> > so that "git euguess master..next" would turn into
> >
> > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next
> >
> > Now, you want to wrap it into an alias, i.e.
> >
> > [alias]
> > euguess = "!sh -c ..."
> >
> > That ... part is read by our configuration reader, so you need to
> > quote the double quotes and backslashes with backslash, which would
> > give you something like:
> >
> > [alias]
> > euguess = "!sh -c 'git log --format=\"%h %ae %s\" 
> > --date=short \"$@\" | sed \"s/@\\S*//\"' -"
> >
> >
> 
> Junio,
> 
> Thanks for taking the time - I appreciate that a lot.
> It does work properly now except there is some difference between the
> required pathnames:
> 
> when i'm in a subfolder in git repo i can say
> 
> git log filename
> 
> But it seems that if the alias is used i need to specify full path
> from the root of the repo no matter where i am.
> 
> git log a/b/c/filename
> 
> the difference is obviously in the working directory
> 
> when i add an alias:
> 
> pd = "!sh -c 'pwd'"
> 
> i get this:
> 
> $ git pd
> /home/users/euguess/repo
> 
> $ pwd
> /home/users/euguess/repo/a/b/c
> 
> Is there any way to help that situation?

Here's the relevant details from Documentation/config.txt:

"""
If the alias expansion is prefixed with an exclamation point,
it will be treated as a shell command.  For example, defining
"alias.new = !gitk --all --not ORIG_HEAD", the invocation
"git new" is equivalent to running the shell command
"gitk --all --not ORIG_HEAD".  Note that shell commands will be
executed from the top-level directory of a repository, which may
not necessarily be the current directory.

'GIT_PREFIX' is set as returned by running 'git rev-parse --show-prefix'
from the original current directory. See linkgit:git-rev-parse[1].
"""

The $GIT_PREFIX variable should be available to the alias; it is
a path relative to the root which corresponds to the current
directory.

That doesn't quite play well with these aliases because they use
"$@", though.

One way to do it is to add another layer of indirection.  Maybe
someone else on this list has a better suggestion, but this
should do the trick...

Create a shell script to contain your alias, and then point
your alias at it.  e.g.

[alias]
example = "!/path/to/alias-script \"$@\""

and then the script can look like:

#!/bin/sh

unset CDPATH
if test -n "$GIT_PREFIX"
then
cd "$GIT_PREFIX"
fi
git log --format='%h %ae %s' --date=short "$@" | sed 's/@\\S*//'


...or something like that.  I hope that helps.
I'm also curious if there's a way to avoid needing the extra script...

...

A-ha.. I think adding the chdir to alias is possible using a function.

[alias]
example = "!f() { cd \"${GIT_PREFIX:-.}\" && git log \"$@\"; }; f"

Does that work for you?
I hope that helps.

cheers,
-- 
David
--
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: Help creating git alias

[Eugene Sajine]

On Wed, Oct 30, 2013 at 11:54 PM, Junio C Hamano  wrote:
> Eugene Sajine  writes:
>
>> That was my initial intention, because I would like to be able to pass
>> parameters like to git log or git blame correctly without the explicit
>> use of $1. Could you please advise about how to make it work with the
>> !sh -c ?
>>
>> Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c".
>
> You can make it work if you think step-by-step.  First, this is what
> you want to run:
>
> sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' -
>
> so that "git euguess master..next" would turn into
>
> sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next
>
> Now, you want to wrap it into an alias, i.e.
>
> [alias]
> euguess = "!sh -c ..."
>
> That ... part is read by our configuration reader, so you need to
> quote the double quotes and backslashes with backslash, which would
> give you something like:
>
> [alias]
> euguess = "!sh -c 'git log --format=\"%h %ae %s\" 
> --date=short \"$@\" | sed \"s/@\\S*//\"' -"
>
>

Junio,

Thanks for taking the time - I appreciate that a lot.
It does work properly now except there is some difference between the
required pathnames:

when i'm in a subfolder in git repo i can say

git log filename

But it seems that if the alias is used i need to specify full path
from the root of the repo no matter where i am.

git log a/b/c/filename

the difference is obviously in the working directory

when i add an alias:

pd = "!sh -c 'pwd'"

i get this:

$ git pd
/home/users/euguess/repo

$ pwd
/home/users/euguess/repo/a/b/c

Is there any way to help that situation?

Thanks,
Eugene

Thanks,
Eugene
--
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: Help creating git alias

[Junio C Hamano]

Eugene Sajine  writes:

> That was my initial intention, because I would like to be able to pass
> parameters like to git log or git blame correctly without the explicit
> use of $1. Could you please advise about how to make it work with the
> !sh -c ?
>
> Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c".

You can make it work if you think step-by-step.  First, this is what
you want to run:

sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' -

so that "git euguess master..next" would turn into

sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next

Now, you want to wrap it into an alias, i.e.

[alias]
euguess = "!sh -c ..."

That ... part is read by our configuration reader, so you need to
quote the double quotes and backslashes with backslash, which would
give you something like:

[alias]
euguess = "!sh -c 'git log --format=\"%h %ae %s\" --date=short 
\"$@\" | sed \"s/@\\S*//\"' -"


--
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: Help creating git alias

[Eugene Sajine]

On Wed, Oct 30, 2013 at 5:02 PM, Junio C Hamano  wrote:
> Eugene Sajine  writes:
>
>> On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow  wrote:
>>> lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g'
>>>
>>> should work.
>>
>>
>> It did! thanks! I didn't know that "!sh -c" is not needed
>
> "sh -c" is often used when you pass arguments to your scriptlets,
> e.g. to allow
>
> git lg master..next
>
> you would want
>
> sh -c 'git log ... "$@" | sed ...' -
>
> so that
>
> git lg master..next
>
> turns into
>
> sh -c 'git log ... "$@" | sed ...' - master..next
>
> which makes $1="master..next" and fed to "git log".

Junio,

That was my initial intention, because I would like to be able to pass
parameters like to git log or git blame correctly without the explicit
use of $1. Could you please advise about how to make it work with the
!sh -c ?

Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c".

Thanks,
Eugene
--
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: Help creating git alias

[Junio C Hamano]

Eugene Sajine  writes:

> On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow  wrote:
>> lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g'
>>
>> should work.
>
>
> It did! thanks! I didn't know that "!sh -c" is not needed

"sh -c" is often used when you pass arguments to your scriptlets,
e.g. to allow

git lg master..next

you would want

sh -c 'git log ... "$@" | sed ...' -

so that

git lg master..next

turns into

sh -c 'git log ... "$@" | sed ...' - master..next

which makes $1="master..next" and fed to "git log".
--
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: Help creating git alias

[Eugene Sajine]

On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow  wrote:
> lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g'
>
> should work.


It did! thanks! I didn't know that "!sh -c" is not needed

>
> On Wed, Oct 30, 2013 at 8:34 PM, Eugene Sajine  wrote:
>> Hi,
>>
>> I need some advice about creating the git command alias:
>>
>> I have this as the command:
>>
>> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g'
>>
>>
>> The purpose is to cut off the email domain and keep only username.
>>
>> I'm trying to create this as the alias:
>>
>>
>> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short |
>> sed 's/@\S*//g'' -
>>
>> but it complains about the \S and i'm failing to come up with the
>> escape sequence to make it work right.
>>
>> I know i can work around that by creating shell alias, but it is not
>> what i would like to have.
>>
>> Any ideas?
>>
>> 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
--
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: Help creating git alias

[Ralf Thielow]

lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g'

should work.

On Wed, Oct 30, 2013 at 8:34 PM, Eugene Sajine  wrote:
> Hi,
>
> I need some advice about creating the git command alias:
>
> I have this as the command:
>
> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g'
>
>
> The purpose is to cut off the email domain and keep only username.
>
> I'm trying to create this as the alias:
>
>
> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short |
> sed 's/@\S*//g'' -
>
> but it complains about the \S and i'm failing to come up with the
> escape sequence to make it work right.
>
> I know i can work around that by creating shell alias, but it is not
> what i would like to have.
>
> Any ideas?
>
> 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
--
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: Help creating git alias

[Eugene Sajine]

On Wed, Oct 30, 2013 at 3:47 PM, Andrew Ardill  wrote:
> Have you tried backslash escaping the backslash? double escaping?
>
> I don't know how many are required, but I would try first \S, then
> \\S, then S, etc
> Regards,
>
> Andrew Ardill

When i do that it stops understanding \S* as regexp so it removes only
"@", while i need to remove from @ to the next whitespace

Thanks,
Eugene



>
> On 30 October 2013 12:34, Eugene Sajine  wrote:
>> Hi,
>>
>> I need some advice about creating the git command alias:
>>
>> I have this as the command:
>>
>> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g'
>>
>>
>> The purpose is to cut off the email domain and keep only username.
>>
>> I'm trying to create this as the alias:
>>
>>
>> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short |
>> sed 's/@\S*//g'' -
>>
>> but it complains about the \S and i'm failing to come up with the
>> escape sequence to make it work right.
>>
>> I know i can work around that by creating shell alias, but it is not
>> what i would like to have.
>>
>> Any ideas?
>>
>> 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
--
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: Help creating git alias

[Andrew Ardill]

Have you tried backslash escaping the backslash? double escaping?

I don't know how many are required, but I would try first \S, then
\\S, then S, etc
Regards,

Andrew Ardill


On 30 October 2013 12:34, Eugene Sajine  wrote:
> Hi,
>
> I need some advice about creating the git command alias:
>
> I have this as the command:
>
> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g'
>
>
> The purpose is to cut off the email domain and keep only username.
>
> I'm trying to create this as the alias:
>
>
> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short |
> sed 's/@\S*//g'' -
>
> but it complains about the \S and i'm failing to come up with the
> escape sequence to make it work right.
>
> I know i can work around that by creating shell alias, but it is not
> what i would like to have.
>
> Any ideas?
>
> 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
--
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

Help creating git alias

[Eugene Sajine]

Hi,

I need some advice about creating the git command alias:

I have this as the command:

git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g'


The purpose is to cut off the email domain and keep only username.

I'm trying to create this as the alias:


lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short |
sed 's/@\S*//g'' -

but it complains about the \S and i'm failing to come up with the
escape sequence to make it work right.

I know i can work around that by creating shell alias, but it is not
what i would like to have.

Any ideas?

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: [PATCH] mergetool--lib: Fix typo in the merge/difftool help

[David Aguilar]

On Fri, Oct 4, 2013 at 7:34 AM, Stefan Saasen  wrote:
> The help text for the `tool` flag should mention:
>
> --tool=
>
> instead of:
>
> --tool-
>
> Signed-off-by: Stefan Saasen 
> ---

Good eyes!

Reviewed-by: David Aguilar 

Thanks

>  git-mergetool--lib.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index feee6a4..e1c7eb1 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -263,7 +263,7 @@ list_merge_tool_candidates () {
>  }
>
>  show_tool_help () {
> -   tool_opt="'git ${TOOL_MODE}tool --tool-'"
> +   tool_opt="'git ${TOOL_MODE}tool --tool='"
>
> tab='   '
> LF='
> --
> 1.8.4.474.g128a96c.dirty
>
-- 
David
--
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] mergetool--lib: Fix typo in the merge/difftool help

[Stefan Saasen]

The help text for the `tool` flag should mention:

--tool=

instead of:

--tool-

Signed-off-by: Stefan Saasen 
---
 git-mergetool--lib.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index feee6a4..e1c7eb1 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -263,7 +263,7 @@ list_merge_tool_candidates () {
 }
 
 show_tool_help () {
-   tool_opt="'git ${TOOL_MODE}tool --tool-'"
+   tool_opt="'git ${TOOL_MODE}tool --tool='"
 
tab='   '
LF='
-- 
1.8.4.474.g128a96c.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

PLEASE I NEED YOUR HELP

[Foots, Alisha]

I am Mrs, Nancy Butler. I have a foundation/Estate uncompleted {worth sum of 
USD 4,142,728.00 Dollars} and need somebody to help me finish it because of my 
health. Contact me with this email ( 
nancybutler...@yahoo.co.uk<mailto:nancybutler...@yahoo.co.uk> ).
--
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 pack v4: next step, help required

[Duy Nguyen]

On Thu, Sep 19, 2013 at 12:40 AM, Nicolas Pitre  wrote:
>
> I think the pack v4 format and compatibility code is pretty stable now,
> and probably as optimal as it can reasonably be.
>
> @Junio: might be a good idea to refresh your pu branch again.
>
> Now the biggest problem to solve is the actual tree
> "deltification".  I don't have the time to spend on this otherwise very
> interesting problem (IMHO at least) so I'm sending this request for help
> in the hope that more people would be keen to contribute their computing
> skills to solve this challenge.

Just so we're clear as I'm involved a bit in packv4 series. I plan to
make the test suite fully pass, then add v4 support to git protocol.
After that I may look into adding multi-base tree support to
index-pack/unpack-objects, and only then either look into this
challenge or continue to add v4-aware tree walker to git. In short,
you you are intereted in Nico's challenge, go ahead, it will not
overlap with my work, at least in the next one or two months.
-- 
Duy
--
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 pack v4: next step, help required

[Nicolas Pitre]

I think the pack v4 format and compatibility code is pretty stable now, 
and probably as optimal as it can reasonably be.

@Junio: might be a good idea to refresh your pu branch again.

Now the biggest problem to solve is the actual tree 
"deltification".  I don't have the time to spend on this otherwise very 
interesting problem (IMHO at least) so I'm sending this request for help 
in the hope that more people would be keen to contribute their computing 
skills to solve this challenge.

I'll make a quick description of the pv4 tree encoding first and explain 
the problem to solve afterwards.

A pv4 tree is comprised of two types of records: immediate tree entry 
and tree sequence copy.

1) Immediate Tree Entry

This is made of the following tuple:

,{SHA1 reference index>

The path component index refers to the path dictionary table where path 
strings and file modes are uniquely stored.  The SHA1 index refers to 
the sorted SHA1 table as previously found in the pack index but which is 
now part of the pack file itself.  So on average a single tree entry may 
take between 1 to 2 bytes for the path component index and 1 to 3 bytes 
for the SHA1 index.

2) Tree Sequence Copy

This is used to literally copy a contiguous list of tree entries from 
another tree object.  This goes as follows:

,
[,]

So instead of having arbitrary copying of data like in delta objects, we 
refer directly to tree entries in another object.  The big advantage 
here is that the tree walker may directly jump to the copied object 
without having to do any delta patching and caching. The SHA1 index is 
optional if it refers to the same copied object as the previous tree 
sequence copy record in this tree object.  And another possible 
optimization for the tree walker when enumerating objects is to skip the 
copy entry entirely if the object being copied from has already been 
enumerated.

The size of this entry is more variable and is typically between 1 to 2 
bytes for the start index, 1 to 2 bytes for the copy size, and 0 to 3 
bytes for the SHA1 index.

So... what to do with this?

Currently the "deltification" is achieved using a pretty dumb heuristic 
which is to simply take each tree object in a pack v2 with their 
corresponding base delta object and perform a straight conversion into 
pack v4 tree format i.e. use copy records whenever possible as long as 
they represent a space saving over the corresponding immediate tree 
entries (which is normally the case).

However this is rather sub-optimal for two reasons:

1) This doesn't benefit from the ability to use multiple base objects to 
   copy from and is potentially missing on additional opportunities for 
   copy sequences which are not possible in the selected base object 
   from the pack v2 delta base selection. Pack v4 is already quite 
   smaller than pack v2 yet it might possibly be smaller still.

2) This makes deep delta chains very inefficient at runtime when the 
   pack is subsequently accessed.

Let's consider this example to fully illustrate #2.

Tree A:
entry 0:"foo.txt"
entry 1-3:  copy from tree B: start=2 count=3

Tree B:
entry 0-5:  copy from tree C: start=2 count=5
entry 6:"bar.txt"

Tree C:
entry 0:"file_a"
entry 1:"file_b"
entry 2:"file_c"
entry 3:"file_D"
entry 4:"file_E"
entry 5:"file_F"
entry 6:"file_G"

This is a good example of what typically happens when the above heuristic 
is applied.  And it is not uncommon to see a long indirection chain of 
"copy those 2 entries from that other object" sometimes reaching 50 
levels deep where the same 2 (or more) entries require up to 50 object 
hops before they can be obtained.

Obviously here the encoding should be optimized to reduce the chaining 
effect simply by referring to the final object directly.  Hence tree A 
could be encoded as follows:

Tree A:
entry 0:"foo.txt"
entry 1-3:  copy from tree C: start=4 count=3

The on-disk encoding is likely to be the same size but the runtime 
access is greatly optimized.

Now... instead of trying to do reference simplification by factoring out 
the chain effect, I think a whole new approach to tree delta compression 
for pack v4 should be developed which would also address issue #1 above.

For example, we may try to make each canonical tree objects into 
sequences of hashed tree entries in memory where each tree entry would 
be reduced down to a single CRC32 value (or even Adler32 for speed).  
Each tree object would then be represented by some kind of 32-bit 
character "string".  Then it is just a matter of applying substring 
matching algorithms

[PATCH v4 4/4] gitweb: make search help link less ugly

[Tony Finch]

The search help link was a superscript question mark right next to
a drop-down menu, which looks misaligned and is a cramped and
awkward click target. Remove the superscript tags and add some
spacing to fix these nits. Add a title attribute to provide an
explanatory mouseover.

Signed-off-by: Tony Finch 
---
 gitweb/gitweb.perl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d69ada..59af7de 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4030,8 +4030,8 @@ sub print_search_form {
  $cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) 
. "\n" .
  $cgi->popup_menu(-name => 'st', -default => 'commit',
   -values => ['commit', 'grep', 'author', 
'committer', 'pickaxe']) .
- $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
- " search:\n",
+ " " . $cgi->a({-href => href(action=>"search_help"),
+-title => "search help" }, "?") . " search:\n",
  $cgi->textfield(-name => "s", -value => $searchtext, -override => 
1) . "\n" .
  "" .
  $cgi->checkbox(-name => 'sr', -value => 1, -label => 're',
-- 
1.8.3.1.605.g85318f5

--
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: Help with sparse checkouts

[Duy Nguyen]

On Tue, Aug 13, 2013 at 1:27 AM, Ari Entlich  wrote:
> Hello all!
>
> At my current workplace, I have a git-svn repository which has an extremely 
> large working directory. I did not use the --stdlayout option in this clone, 
> so I have a number of branches in my working directory which duplicate large 
> amounts of trunk. There is a particularly large subdirectory which has now 
> been copied to branches four times (and hence shows up in my working 
> directory 5 times). This directory and its copies are making up the vast 
> majority of the files and storage space in my working directory. Furthermore, 
> I do not need or want to have access to the data in these particular 
> directories. Hence, I would like to use the sparse checkouts feature to 
> exclude them from my working directory.
>
> Let's say that these directories are all called "thedir". What I would like 
> to do with the sparse checkouts feature is to simply ignore directories with 
> this name anywhere in the working tree. Intuitively, it seems like I should 
> be able to put:
>
> !thedir
>
> or possibly
>
> !thedir/
>

I think this should work (but I haven't tested it)

/
!thedir

The first rule is to include all, the we exclude what we don't want
using the second one (trailing slash or not is ok).

> in the sparse-checkout file, but these don't seem to work. I've tried a 
> number of other things, but I always seem to either get the "sparse checkout 
> leaves no entry on working directory" error or no effect at all. In the end, 
> I basically just don't really understand how this file is supposed to work, 
> so I'd rather get some expert help here rather than thrashing about randomly. 
> I realize that sparse checkouts is usually used to select a specific 
> directory rather than what I'm trying to do, so I accept that what I want may 
> simply not be possible with the current implementation. I've asked on IRC, 
> but I wanted to ask here also since it seemed that most of the people I 
> talked to weren't that familiar with the sparse checkouts feature.
>
> Note that, while using --stdlayout would mitigate the massive working 
> directory somewhat, I would still probably want to exclude this directory 
> from my worktree. I will probably do a reclone at some point and use 
> --stdlayout, but I will still want to exclude this particular directory even 
> at that point. I had a lot of people on IRC telling me to just use 
> --stdlayout, which was a good suggestion, but didn't fully fulfill my needs.
>
> Thanks!
>
> Ari
> --
> 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



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

Help with sparse checkouts

[Ari Entlich]

Hello all!

At my current workplace, I have a git-svn repository which has an extremely 
large working directory. I did not use the --stdlayout option in this clone, so 
I have a number of branches in my working directory which duplicate large 
amounts of trunk. There is a particularly large subdirectory which has now been 
copied to branches four times (and hence shows up in my working directory 5 
times). This directory and its copies are making up the vast majority of the 
files and storage space in my working directory. Furthermore, I do not need or 
want to have access to the data in these particular directories. Hence, I would 
like to use the sparse checkouts feature to exclude them from my working 
directory.

Let's say that these directories are all called "thedir". What I would like to 
do with the sparse checkouts feature is to simply ignore directories with this 
name anywhere in the working tree. Intuitively, it seems like I should be able 
to put:

!thedir

or possibly

!thedir/

in the sparse-checkout file, but these don't seem to work. I've tried a number 
of other things, but I always seem to either get the "sparse checkout leaves no 
entry on working directory" error or no effect at all. In the end, I basically 
just don't really understand how this file is supposed to work, so I'd rather 
get some expert help here rather than thrashing about randomly. I realize that 
sparse checkouts is usually used to select a specific directory rather than 
what I'm trying to do, so I accept that what I want may simply not be possible 
with the current implementation. I've asked on IRC, but I wanted to ask here 
also since it seemed that most of the people I talked to weren't that familiar 
with the sparse checkouts feature.

Note that, while using --stdlayout would mitigate the massive working directory 
somewhat, I would still probably want to exclude this directory from my 
worktree. I will probably do a reclone at some point and use --stdlayout, but I 
will still want to exclude this particular directory even at that point. I had 
a lot of people on IRC telling me to just use --stdlayout, which was a good 
suggestion, but didn't fully fulfill my needs.

Thanks!

Ari
--
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 4/4] gitweb: make search help link less ugly

[Tony Finch]

Jakub Narębski  wrote:

> > -  -values => ['commit', 'grep', 'author', 
> > 'committer', 'pickaxe']) .
> > +  -values => ['commit', 'grep', 'author', 
> > 'committer', 'pickaxe']) .
>
> Nb. what changed here (in line above)?

Whoops, tab damage. I will re-roll. Thanks for the review.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

Re: [PATCH 4/4] gitweb: make search help link less ugly

[Jakub Narębski]

On Tue, Jul 9, 2013 at 7:15 PM, Tony Finch  wrote:

> The search help link was a superscript question mark right next to
> a drop-down menu, which looks misaligned

I think the idea was to simulate footnote explaining search terms
(I think, I am not the author of this feature)...

>and is a 
> cramped and
> awkward click target. Remove the superscript tags and add some
> spacing to fix these nits. Add a title attribute to provide an
> explanatory mouseover.

... but I agree that it makes for poor UI.

>
> Signed-off-by: Tony Finch 
> ---
>  gitweb/gitweb.perl | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c029b98..874c948 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4029,9 +4029,9 @@ sub print_search_form {
>   $cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . 
> "\n" .
>   $cgi->input({-name=>"h", -value=>$search_hash, 
> -type=>"hidden"}) . "\n" .
>   $cgi->popup_menu(-name => 'st', -default => 'commit',
> -  -values => ['commit', 'grep', 'author', 
> 'committer', 'pickaxe']) .
> - $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) 
> .
> - " search:\n",
> +  -values => ['commit', 'grep', 'author', 
> 'committer', 'pickaxe']) .

Nb. what changed here (in line above)?

> + " " . $cgi->a({-href => href(action=>"search_help"),
> +-title => "search help" }, "?") . " search:\n",
>   $cgi->textfield(-name => "s", -value => $searchtext, -override 
> => 1) . "\n" .
>   "" .
>   $cgi->checkbox(-name => 'sr', -value => 1, -label => 're',
> --
> 1.8.3.1.605.g85318f5
--
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: Help using git subtree

[Gabriel Jover]

Al 30/07/13 11:58, En/na Fredrik Gustafsson ha escrit:


Git subtree is very convenient to get all the sub-projects into the
main-project directory tree
and to send back sub-project commits to the corresponding repository.
But I don't understand the work flow very well.

I haven't used subtree that much however how do you commit to upstream?
AFAIK every commit to the subtree must be done in the subtree branch and
then merged back to the "superproject"-branch with a subtree merge.

I use "git subtree pull" and "git subtree push".
AFAIK with subtree all commits are in the same repository, thus one does 
not need
to go to the subtree branch to commit. This is one of the advantages of 
subtree.



I can add a subtree with a given prefix and pull/push my commits to
the repository,
but how do I do to pull/push commits from the main-project to the
corresponding repository
avoiding sub-projects to be sent?

You don't. A subtree is a subtree in your git-repo and is therefore a
part of your repository. When you're using subtree that project will be
a part of you project.

I expected that there would be a way to split the main project and push it,
in the same way that one can split one subtree and push it.
If not, this could be a feature request.


An other question I have is when will be subtree included in git packages.
I had to compile git from sources in order to get this feature.


If you're asking when git-subtree will move from contrib/ to core git, I
don't know. That's a decision for Junio. I would argue that it shouldn't
because submodules can do everything that subtrees are good at and
git.git should focus on doing one solution well instead of doing the
same thing in two bad ways. However since git.git already uses a
subtree-like style for gitk, git-gui, etc.  it doesn't seem like Junio
agrees with me on this point.

Right, I rephrase: When git-subtree will move from contrib/ to core git?

Let me also empathize that I find git-subtree much more convenient than 
sub-modules.
One can work with a single repository as it were a single project, one 
can commit changes
that affect different sub-projects with just one command, use common 
tags and branches and so on.



Si heu rebut aquest correu per error, us informo que pot contenir informació 
confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho 
comuniqueu al remitent i l'elimineu. Gràcies.
Si ha recibido este correo por error, le informo de que puede contener 
información confidencial  y privada y que está prohibido su uso. Le agradeceré 
que lo comunique a su remitente y lo elimine. Gracias.
If you have received  this e-mail by error, please note that it may contain 
confidential and private  information, therefore, the use of this information 
is strictly forbidden. Please inform the sender of the error and delete the 
information received. Thank you.

Is this really something to have in e-mails to a public list? Some lists
won't accept this type of e-mails, or simply just ignore you.

Don't worry about this signature, it only applies if one receives this 
e-mail by mistake.


Best regards,

Gabriel

--


Si heu rebut aquest correu per error, us informo que pot contenir informació 
confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho 
comuniqueu al remitent i l'elimineu. Gràcies.
Si ha recibido este correo por error, le informo de que puede contener 
información confidencial  y privada y que está prohibido su uso. Le agradeceré 
que lo comunique a su remitente y lo elimine. Gracias.
If you have received  this e-mail by error, please note that it may contain 
confidential and private  information, therefore, the use of this information 
is strictly forbidden. Please inform the sender of the error and delete the 
information received. Thank you.

--
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: Help using git subtree

[Fredrik Gustafsson]

On Tue, Jul 30, 2013 at 11:32:22AM +0200, Gabriel Jover wrote:
> Dear all,
> 
> I am trying to avoid using git submodules and thus I am testing if
> git subtree fit my needs.
> I have a set of sub-projects linked to a main-project.

Just out of curiosity, why are you trying to avoid submodules?

> 
> Git subtree is very convenient to get all the sub-projects into the
> main-project directory tree
> and to send back sub-project commits to the corresponding repository.
> But I don't understand the work flow very well.

I haven't used subtree that much however how do you commit to upstream?
AFAIK every commit to the subtree must be done in the subtree branch and
then merged back to the "superproject"-branch with a subtree merge.

> 
> I can add a subtree with a given prefix and pull/push my commits to
> the repository,
> but how do I do to pull/push commits from the main-project to the
> corresponding repository
> avoiding sub-projects to be sent?

You don't. A subtree is a subtree in your git-repo and is therefore a
part of your repository. When you're using subtree that project will be
a part of you project.

> 
> An other question I have is when will be subtree included in git packages.
> I had to compile git from sources in order to get this feature.
> 

git-subtree is a part of git, located in the contrib section. When your
software distribution choose to distribute that with your git-package
is not up to the git project to decide but something you need to ask
your package maintainer.

If you're asking when git-subtree will move from contrib/ to core git, I
don't know. That's a decision for Junio. I would argue that it shouldn't
because submodules can do everything that subtrees are good at and
git.git should focus on doing one solution well instead of doing the
same thing in two bad ways. However since git.git already uses a
subtree-like style for gitk, git-gui, etc.  it doesn't seem like Junio
agrees with me on this point.

> 
> Si heu rebut aquest correu per error, us informo que pot contenir informació 
> confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho 
> comuniqueu al remitent i l'elimineu. Gràcies.
> Si ha recibido este correo por error, le informo de que puede contener 
> información confidencial  y privada y que está prohibido su uso. Le 
> agradeceré que lo comunique a su remitente y lo elimine. Gracias.
> If you have received  this e-mail by error, please note that it may contain 
> confidential and private  information, therefore, the use of this information 
> is strictly forbidden. Please inform the sender of the error and delete the 
> information received. Thank you.

Is this really something to have in e-mails to a public list? Some lists
won't accept this type of e-mails, or simply just ignore you.

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.com
--
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

Help using git subtree

[Gabriel Jover]

Dear all,

I am trying to avoid using git submodules and thus I am testing if git 
subtree fit my needs.

I have a set of sub-projects linked to a main-project.

Git subtree is very convenient to get all the sub-projects into the 
main-project directory tree

and to send back sub-project commits to the corresponding repository.
But I don't understand the work flow very well.

I can add a subtree with a given prefix and pull/push my commits to the 
repository,
but how do I do to pull/push commits from the main-project to the 
corresponding repository

avoiding sub-projects to be sent?

An other question I have is when will be subtree included in git packages.
I had to compile git from sources in order to get this feature.

Sincerely,

G. Jover-Manas

--
++
 Gabriel V. Jover Mañas
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: gjo...@cells.es
 Phone: +34 93 592 4471
 Office: ALBA P0 Of8/18
++

Si heu rebut aquest correu per error, us informo que pot contenir informació 
confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho 
comuniqueu al remitent i l'elimineu. Gràcies.
Si ha recibido este correo por error, le informo de que puede contener 
información confidencial  y privada y que está prohibido su uso. Le agradeceré 
que lo comunique a su remitente y lo elimine. Gracias.
If you have received  this e-mail by error, please note that it may contain 
confidential and private  information, therefore, the use of this information 
is strictly forbidden. Please inform the sender of the error and delete the 
information received. Thank you.

--
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] Let index-pack help with connectivity check on cloning via smart http

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

This is an extension of c6807a4 (clone: open a shortcut for
connectivity check - 2013-05-26) to reduce the cost of connectivity
check at clone time, this time with smart http protocol.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/git-fetch-pack.txt|  4 
 Documentation/gitremote-helpers.txt | 10 ++
 builtin/fetch-pack.c|  9 +
 remote-curl.c   | 15 ++-
 transport-helper.c  | 10 ++
 5 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index 1e71754..444b805 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -90,6 +90,10 @@ be in a separate packet, and the list must end with a flush 
packet.
 --no-progress::
Do not show the progress.
 
+--check-self-contained-and-connected::
+   Output "connectivity-ok" if the received pack is
+   self-contained and connected.
+
 -v::
Run verbosely.
 
diff --git a/Documentation/gitremote-helpers.txt 
b/Documentation/gitremote-helpers.txt
index 0827f69..bc069c2 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -143,6 +143,10 @@ Supported commands: 'list', 'fetch'.
 +
 Supported commands: 'list', 'import'.
 
+'check-connectivity'::
+   Can guarantee that when a clone is requested, the received
+   pack is self contained and is connected.
+
 If a helper advertises 'connect', Git will use it if possible and
 fall back to another capability if the helper requests so when
 connecting (see the 'connect' command under COMMANDS).
@@ -270,6 +274,9 @@ Optionally may output a 'lock ' line indicating a 
file under
 GIT_DIR/objects/pack which is keeping a pack until refs can be
 suitably updated.
 +
+If option 'check-connectivity' is requested, the helper must output
+'connectivity-ok' if the clone is self-contained and connected.
++
 Supported if the helper has the "fetch" capability.
 
 'push' +:::
@@ -416,6 +423,9 @@ set by Git if the remote helper has the 'option' capability.
must not rely on this option being set before
connect request occurs.
 
+'option check-connectivity' \{'true'|'false'\}::
+   Request the helper to check connectivity of a clone.
+
 SEE ALSO
 
 linkgit:git-remote[1]
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index aba4465..3e19d71 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -100,6 +100,10 @@ int cmd_fetch_pack(int argc, const char **argv, const char 
*prefix)
pack_lockfile_ptr = &pack_lockfile;
continue;
}
+   if (!strcmp("--check-self-contained-and-connected", arg)) {
+   args.check_self_contained_and_connected = 1;
+   continue;
+   }
usage(fetch_pack_usage);
}
 
@@ -152,6 +156,11 @@ int cmd_fetch_pack(int argc, const char **argv, const char 
*prefix)
printf("lock %s\n", pack_lockfile);
fflush(stdout);
}
+   if (args.check_self_contained_and_connected &&
+   args.self_contained_and_connected) {
+   printf("connectivity-ok\n");
+   fflush(stdout);
+   }
close(fd[0]);
close(fd[1]);
if (finish_connect(conn))
diff --git a/remote-curl.c b/remote-curl.c
index 5b3ce9e..6918668 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -16,6 +16,7 @@ struct options {
int verbosity;
unsigned long depth;
unsigned progress : 1,
+   check_self_contained_and_connected : 1,
followtags : 1,
dry_run : 1,
thin : 1;
@@ -67,6 +68,15 @@ static int set_option(const char *name, const char *value)
return -1;
return 0;
}
+   else if (!strcmp(name, "check-connectivity")) {
+   if (!strcmp(value, "true"))
+   options.check_self_contained_and_connected = 1;
+   else if (!strcmp(value, "false"))
+   options.check_self_contained_and_connected = 0;
+   else
+   return -1;
+   return 0;
+   }
else {
return 1 /* unsupported */;
}
@@ -654,7 +664,7 @@ static int fetch_git(struct discovery *heads,
struct strbuf preamble = STRBUF_INIT;
char *depth_arg = NULL;
int argc = 0, i, err;
-   const char *argv[15];
+   const char *argv[16];
 
argv[argc++] = "fetch-pack";
argv[argc++] = "--stateless-rpc";
@@ -668,6 +678,8 @@ static int fetch_git(struct discovery *heads,
argv[argc++] = "-v";
argv[argc++] = "-v";
}
+   if (options.check_self_contained_and_connected)
+   argv[argc++] = "--check-self-contained-and-connected";
if (!

[PATCH 4/4] gitweb: make search help link less ugly

[Tony Finch]

The search help link was a superscript question mark right next to
a drop-down menu, which looks misaligned and is a cramped and
awkward click target. Remove the superscript tags and add some
spacing to fix these nits. Add a title attribute to provide an
explanatory mouseover.

Signed-off-by: Tony Finch 
---
 gitweb/gitweb.perl | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c029b98..874c948 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4029,9 +4029,9 @@ sub print_search_form {
  $cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . 
"\n" .
  $cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) 
. "\n" .
  $cgi->popup_menu(-name => 'st', -default => 'commit',
-  -values => ['commit', 'grep', 'author', 
'committer', 'pickaxe']) .
- $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
- " search:\n",
+  -values => ['commit', 'grep', 'author', 
'committer', 'pickaxe']) .
+ " " . $cgi->a({-href => href(action=>"search_help"),
+-title => "search help" }, "?") . " search:\n",
  $cgi->textfield(-name => "s", -value => $searchtext, -override => 
1) . "\n" .
  "" .
  $cgi->checkbox(-name => 'sr', -value => 1, -label => 're',
-- 
1.8.3.1.605.g85318f5

--
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] configure: fix help screen

[Junio C Hamano]

Stefano Lattarini  writes:

> The configure option to disable threading is '--disable-pthreads',
> not '--without-pthreads'.
>
> Signed-off-by: Stefano Lattarini 
> ---

Thanks.

>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index f3462d9..2f43393 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -193,7 +193,7 @@ AC_ARG_ENABLE([pthreads],
>[FLAGS is the value to pass to the compiler to enable POSIX Threads.]
>[The default if FLAGS is not specified is to try first -pthread]
>[and then -lpthread.]
> -  [--without-pthreads will disable threading.])],
> +  [--disable-pthreads will disable threading.])],
>  [
>  if test "x$enableval" = "xyes"; then
> AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads])
--
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] configure: fix help screen

[Stefano Lattarini]

The configure option to disable threading is '--disable-pthreads',
not '--without-pthreads'.

Signed-off-by: Stefano Lattarini 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index f3462d9..2f43393 100644
--- a/configure.ac
+++ b/configure.ac
@@ -193,7 +193,7 @@ AC_ARG_ENABLE([pthreads],
   [FLAGS is the value to pass to the compiler to enable POSIX Threads.]
   [The default if FLAGS is not specified is to try first -pthread]
   [and then -lpthread.]
-  [--without-pthreads will disable threading.])],
+  [--disable-pthreads will disable threading.])],
 [
 if test "x$enableval" = "xyes"; then
AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads])
-- 
1.8.3.1.605.g85318f5

--
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: [HELP] Corrupted repository

[Matthieu Moy]

Junio C Hamano  writes:

> Ramkumar Ramachandra  writes:
>
>> Junio C Hamano wrote:
   $ ~/src/git
   error: object file
 .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
   error: object file
 .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
 in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>>>
>>> So fsync() and close() thought that the filesystem stored this loose
>>> object safely, but it turns out that the data is not on disk.
>>
>> Where should I start digging if I want to fix this?  Actually you just
>> need to tell me how to build reduced-case corruptions to test: I can
>> trace and figure out the rest.
>
> That is a trip in the kernel source, isn't it?  I cannot be your
> guide there.

Not necessarily. AFAICT, Git won't fsync object files by default, but
does for pack files (to make sure the pack is written before unlinking
the object files being packed):

   core.fsyncobjectfiles
   This boolean will enable fsync() when writing object files.

   This is a total waste of time and effort on a filesystem that
   orders data writes properly, but can be useful for
   filesystems that do not use journalling (traditional UNIX
   filesystems) or that only journal metadata and not file
   contents (OS X’s HFS+, or Linux ext3 with "data=writeback").


-- 
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: [PATCH] help: introduce man.viewer = eman

[Ramkumar Ramachandra]

John Keeping wrote:
> Would it be nicer to pass a string in here instead of a flag?  Then this
> becomes:
>
> strbuf_addf(&man_page, "(%s \"%s\")", command, page);
>
> You should probably also rename this function to "exec_emacsclient" or
> something as well now that it doesn't just launch woman.

Sure, will do both.
--
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: introduce man.viewer = eman

[John Keeping]

On Sat, Jun 22, 2013 at 05:13:29PM +0530, Ramkumar Ramachandra wrote:
> Corresponding to woman.
> 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  Documentation/git-help.txt |  3 +++
>  builtin/help.c | 11 ---
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
> index b21e9d7..0cb4c46 100644
> --- a/Documentation/git-help.txt
> +++ b/Documentation/git-help.txt
> @@ -104,6 +104,9 @@ The 'man.viewer' config variable will be checked if the 
> 'man' format
>  is chosen. The following values are currently supported:
>  
>  * "man": use the 'man' program as usual,
> +* "eman": use 'emacsclient' to launch the "man" mode in emacs
> +(this only works starting with emacsclient versions 22), on systems
> +with man,
>  * "woman": use 'emacsclient' to launch the "woman" mode in emacs
>  (this only works starting with emacsclient versions 22),
>  * "konqueror": use 'kfmclient' to open the man page in a new konqueror
> diff --git a/builtin/help.c b/builtin/help.c
> index 062957f..7cb44e0 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -120,7 +120,7 @@ static int check_emacsclient_version(void)
>   return 0;
>  }
>  
> -static void exec_woman_emacs(const char *path, const char *page)
> +static void exec_woman_emacs(const char *path, const char *page, int eman)
>  {
>   if (!check_emacsclient_version()) {
>   /* This works only with emacsclient version >= 22. */
> @@ -128,7 +128,10 @@ static void exec_woman_emacs(const char *path, const 
> char *page)
>  
>   if (!path)
>   path = "emacsclient";
> - strbuf_addf(&man_page, "(woman \"%s\")", page);
> + if (eman)
> + strbuf_addf(&man_page, "(man \"%s\")", page);
> + else
> + strbuf_addf(&man_page, "(woman \"%s\")", page);

Would it be nicer to pass a string in here instead of a flag?  Then this
becomes:

strbuf_addf(&man_page, "(%s \"%s\")", command, page);

You should probably also rename this function to "exec_emacsclient" or
something as well now that it doesn't just launch woman.

>   execlp(path, "emacsclient", "-e", man_page.buf, (char *)NULL);
>   warning(_("failed to exec '%s': %s"), path, strerror(errno));
>   }
> @@ -341,8 +344,10 @@ static void exec_viewer(const char *name, const char 
> *page)
>  
>   if (!strcasecmp(name, "man"))
>   exec_man_man(info, page);
> + else if (!strcasecmp(name, "eman"))
> + exec_woman_emacs(info, page, 1);
>   else if (!strcasecmp(name, "woman"))
> - exec_woman_emacs(info, page);
> + exec_woman_emacs(info, page, 0);
>   else if (!strcasecmp(name, "konqueror"))
>   exec_man_konqueror(info, page);
>   else if (info)
> -- 
> 1.8.3.1.487.g3e7a5b4.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] help: introduce man.viewer = eman

[Ramkumar Ramachandra]

Corresponding to woman.

Signed-off-by: Ramkumar Ramachandra 
---
 Documentation/git-help.txt |  3 +++
 builtin/help.c | 11 ---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index b21e9d7..0cb4c46 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -104,6 +104,9 @@ The 'man.viewer' config variable will be checked if the 
'man' format
 is chosen. The following values are currently supported:
 
 * "man": use the 'man' program as usual,
+* "eman": use 'emacsclient' to launch the "man" mode in emacs
+(this only works starting with emacsclient versions 22), on systems
+with man,
 * "woman": use 'emacsclient' to launch the "woman" mode in emacs
 (this only works starting with emacsclient versions 22),
 * "konqueror": use 'kfmclient' to open the man page in a new konqueror
diff --git a/builtin/help.c b/builtin/help.c
index 062957f..7cb44e0 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -120,7 +120,7 @@ static int check_emacsclient_version(void)
return 0;
 }
 
-static void exec_woman_emacs(const char *path, const char *page)
+static void exec_woman_emacs(const char *path, const char *page, int eman)
 {
if (!check_emacsclient_version()) {
/* This works only with emacsclient version >= 22. */
@@ -128,7 +128,10 @@ static void exec_woman_emacs(const char *path, const char 
*page)
 
if (!path)
path = "emacsclient";
-   strbuf_addf(&man_page, "(woman \"%s\")", page);
+   if (eman)
+   strbuf_addf(&man_page, "(man \"%s\")", page);
+   else
+   strbuf_addf(&man_page, "(woman \"%s\")", page);
execlp(path, "emacsclient", "-e", man_page.buf, (char *)NULL);
warning(_("failed to exec '%s': %s"), path, strerror(errno));
}
@@ -341,8 +344,10 @@ static void exec_viewer(const char *name, const char *page)
 
if (!strcasecmp(name, "man"))
exec_man_man(info, page);
+   else if (!strcasecmp(name, "eman"))
+   exec_woman_emacs(info, page, 1);
else if (!strcasecmp(name, "woman"))
-   exec_woman_emacs(info, page);
+   exec_woman_emacs(info, page, 0);
else if (!strcasecmp(name, "konqueror"))
exec_man_konqueror(info, page);
else if (info)
-- 
1.8.3.1.487.g3e7a5b4.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: [HELP] Corrupted repository

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> A tl;dr is that we _trust_ our refs and everything reachable from
> them has to be complete.  If that is not the case, things will not
> work, and it is not a priority to add workarounds in the normal
> codepath to slow things down.

Makes sense.

> That does not forbid an addition of "git recover-corrupted-repo"
> command, whose "assume everything might be broken" code is not
> shared with the fastpath of other commands.

I'm not looking for a kitchen-sink command: I'm looking for a
well-documented toolset to precisely fix corruptions.  We have some
corruption tests in our testsuite already: I think I'll start digging
there.

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: [HELP] Corrupted repository

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>>>   $ ~/src/git
>>>   error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>   error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>>
>> So fsync() and close() thought that the filesystem stored this loose
>> object safely, but it turns out that the data is not on disk.
>
> Where should I start digging if I want to fix this?  Actually you just
> need to tell me how to build reduced-case corruptions to test: I can
> trace and figure out the rest.

That is a trip in the kernel source, isn't it?  I cannot be your
guide there.

>
>>>   artagnon|remote-cruft*+:~/src/git$ git prune
>>>   artagnon|remote-cruft*+:~/src/git$ git status
>>>   fatal: bad object HEAD
>>>   fatal: bad object HEAD
>>
>> And the value in the HEAD was???
>
> ref: refs/heads/remote-cruft.  That's why I included my prompt :)
>
>>>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>>>   artagnon|master*+=:~/src/git$ git status
>>>   ## master
>>>   MM Documentation/git-ls-remote.txt
>>>   MM remote.c
>>>   MM t/t5505-remote.sh
>>>   MM t/t5510-fetch.sh
>>>   MM t/t5515-fetch-merge-logic.sh
>>>   MM t/t5516-fetch-push.sh
>>>   ?? lib/
>>>   ?? outgoing/
>>>
>>> That status is completely bogus, by the way.
>>
>> ... which may suggest that your index file may have been corrupted
>> on the filesystem.
>
> Yeah, my question pertains to why is the index half-corrupted.  Is
> there no checksum to say "index corrupted; do not display bogus
> nonsense"?

Another possibility is perhaps the objects that are referred to by
the index were missing or unreadable, and the index weren't.

>
>>>   artagnon|master*+=:~/src/git$ git checkout remote-cruft
>>>   fatal: reference is not a tree: remote-cruft
>>>   artagnon|master=:~/src/git$ git reflog
>>>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>>> refs/heads/remote-cruft
>>>
>>> What happened to the rest of my reflog?!
>>
>> On the filesystem known to not record the last consistent state of
>> the repository, the answer to that question may be rather obvious,
>> no?
>
> I didn't understand.  What does .git/logs/HEAD have to do with any of
> this?  Why is it truncated?

Explain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
was truncated to yourself, and the same explanation would apply to
the .git/logs/HEAD file, I think.

> This was mainly a learning exercise for me: I wanted to see how good
> git was at working with corrupted repositories.

You could have just asked ;-).

A tl;dr is that we _trust_ our refs and everything reachable from
them has to be complete.  If that is not the case, things will not
work, and it is not a priority to add workarounds in the normal
codepath to slow things down.

That does not forbid an addition of "git recover-corrupted-repo"
command, whose "assume everything might be broken" code is not
shared with the fastpath of other commands.

--
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: [HELP] Corrupted repository

[Ramkumar Ramachandra]

Junio C Hamano wrote:
>>   $ ~/src/git
>>   error: object file
>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>   error: object file
>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>
> So fsync() and close() thought that the filesystem stored this loose
> object safely, but it turns out that the data is not on disk.

Where should I start digging if I want to fix this?  Actually you just
need to tell me how to build reduced-case corruptions to test: I can
trace and figure out the rest.

>>   artagnon|remote-cruft*+:~/src/git$ git prune
>>   artagnon|remote-cruft*+:~/src/git$ git status
>>   fatal: bad object HEAD
>>   fatal: bad object HEAD
>
> And the value in the HEAD was???

ref: refs/heads/remote-cruft.  That's why I included my prompt :)

>>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>>   artagnon|master*+=:~/src/git$ git status
>>   ## master
>>   MM Documentation/git-ls-remote.txt
>>   MM remote.c
>>   MM t/t5505-remote.sh
>>   MM t/t5510-fetch.sh
>>   MM t/t5515-fetch-merge-logic.sh
>>   MM t/t5516-fetch-push.sh
>>   ?? lib/
>>   ?? outgoing/
>>
>> That status is completely bogus, by the way.
>
> ... which may suggest that your index file may have been corrupted
> on the filesystem.

Yeah, my question pertains to why is the index half-corrupted.  Is
there no checksum to say "index corrupted; do not display bogus
nonsense"?

>>   artagnon|master*+=:~/src/git$ git checkout remote-cruft
>>   fatal: reference is not a tree: remote-cruft
>>   artagnon|master=:~/src/git$ git reflog
>>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>> refs/heads/remote-cruft
>>
>> What happened to the rest of my reflog?!
>
> On the filesystem known to not record the last consistent state of
> the repository, the answer to that question may be rather obvious,
> no?

I didn't understand.  What does .git/logs/HEAD have to do with any of
this?  Why is it truncated?

>>   artagnon|master=:~/src/git$ git branch -D remote-cruft
>>   error: Couldn't look up commit object for 'refs/heads/remote-cruft'
>
> The command would want to report what was at the tip, so it is
> understandable it may want to look up that commit before removing
> the ref.

I would have expected it to display a warning and remove the ref
anyway.  Or error out, and override with a force-flag?

>> Fine, let's fetch.
>
> Why?
>
> "fetch" walks the ancestry graph on both ends to minimize transfers.
> It's not something you would expect to work when you know refs at
> your end does not even record what you do have.  It _may_ appear to
> work if your refs are intact but you are missing objects, as they
> will not be transferred again from the good copy if you let your
> repository's ref claim that you have _all_ objects behind it when
> you actually don't.

Right.  I expected it to figure out that I have a broken history and
fetch everything (which is what happened the second time, no?).

> What would have been a better starting point to untangle is to make
> a separate clone, pretending as if this repository did not even
> exist, and copy the resulting packfile into this repository.  That
> would at least give you a known good copies of objects that you
> already have pushed out.

Yeah, I deliberately avoided doing that: apart from the config and
refs, I had no real unpushed work in ~/src/git anyway (I push _very_
frequently, which explains my "resolve HEAD early in current" patch).
The most important part of what I did was running unpack-objects by
hand: that fixed everything.  I shouldn't have had to run that by hand
though: why isn't there an in-built way to unpack everything, remove
corruptions, and repack the good stuff?

> And the next step would have been (without doing any of the above
> "remove this branch, recreate this one anew") to compare the tips
> of refs in this broken repository and the clone.  The same ones you
> can trust, and different ones you dig further.

Right.  I didn't have local data in this case, so I didn't bother.

>> Was I being stupid, or is fixing corrupted repositories really this
>> non-trivial?  Comments appreciated.
>
> I think "Let's fetch first" was the step that took you in a wrong
> direction that requires unnecessary work.

This was mainly a learning exercise for me: I wanted to see how good
git was at working with corrupted repositories.  I did my surgery
fairly quickly, and avoided large network transfers (I have a slow
connection).
--
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: [HELP] Corrupted repository

[Junio C Hamano]

Ramkumar Ramachandra  writes:

>   $ ~/src/git
>   error: object file
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>   error: object file
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt

So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.

>   artagnon|remote-cruft*+:~/src/git$ rm
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f

As you know it is empty, removing (as long as you do not forget what
the object name was, which may later become useful when untangling
the mess further) does not hurt very much.

>   artagnon|remote-cruft*+:~/src/git$ git prune
>   artagnon|remote-cruft*+:~/src/git$ git status
>   fatal: bad object HEAD
>   fatal: bad object HEAD

And the value in the HEAD was???

>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>   artagnon|master*+=:~/src/git$ git status
>   ## master
>   MM Documentation/git-ls-remote.txt
>   MM remote.c
>   MM t/t5505-remote.sh
>   MM t/t5510-fetch.sh
>   MM t/t5515-fetch-merge-logic.sh
>   MM t/t5516-fetch-push.sh
>   ?? lib/
>   ?? outgoing/
>
> That status is completely bogus, by the way.

... which may suggest that your index file may have been corrupted
on the filesystem.

>   artagnon|master*+=:~/src/git$ git reset --hard

... and using that known-to-be-corrupt index, the working tree state
is discarded.

>   artagnon|master*+=:~/src/git$ git checkout remote-cruft
>   fatal: reference is not a tree: remote-cruft
>   artagnon|master=:~/src/git$ git reflog
>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
> refs/heads/remote-cruft
>
> What happened to the rest of my reflog?!

On the filesystem known to not record the last consistent state of
the repository, the answer to that question may be rather obvious,
no?

>   artagnon|master=:~/src/git$ git branch -D remote-cruft
>   error: Couldn't look up commit object for 'refs/heads/remote-cruft'

The command would want to report what was at the tip, so it is
understandable it may want to look up that commit before removing
the ref.

>   artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft
>   artagnon|master=:~/src/git$ git checkout -b remote-cruft
>   Switched to a new branch 'remote-cruft'
>
> Huh?  What happened to my upstream?
>
>   artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft
>   warning: ignoring broken ref refs/remotes/ram/remote-cruft.

So remotes/ram/remote-cruft is also broken.

> Fine, let's fetch.

Why?

"fetch" walks the ancestry graph on both ends to minimize transfers.
It's not something you would expect to work when you know refs at
your end does not even record what you do have.  It _may_ appear to
work if your refs are intact but you are missing objects, as they
will not be transferred again from the good copy if you let your
repository's ref claim that you have _all_ objects behind it when
you actually don't.

What would have been a better starting point to untangle is to make
a separate clone, pretending as if this repository did not even
exist, and copy the resulting packfile into this repository.  That
would at least give you a known good copies of objects that you
already have pushed out.

And the next step would have been (without doing any of the above
"remove this branch, recreate this one anew") to compare the tips
of refs in this broken repository and the clone.  The same ones you
can trust, and different ones you dig further.

> Was I being stupid, or is fixing corrupted repositories really this
> non-trivial?  Comments appreciated.

I think "Let's fetch first" was the step that took you in a wrong
direction that requires unnecessary work.

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

[HELP] Corrupted repository

[Ramkumar Ramachandra]

Hi,

Until now, my interest in corrupted repositories has been very
limited.  Just now, the power went out for a second and my UPS failed
me.  As a result, my ~/src/git is completely borked.  For your
amusement, here's a quick session showing me bumbling around:

  $ ~/src/git
  error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
  error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
  fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
  artagnon|remote-cruft*+:~/src/git$ rm
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
  artagnon|remote-cruft*+:~/src/git$ git prune
  artagnon|remote-cruft*+:~/src/git$ git status
  fatal: bad object HEAD
  fatal: bad object HEAD
  artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
  artagnon|master*+=:~/src/git$ git status
  ## master
  MM Documentation/git-ls-remote.txt
  MM remote.c
  MM t/t5505-remote.sh
  MM t/t5510-fetch.sh
  MM t/t5515-fetch-merge-logic.sh
  MM t/t5516-fetch-push.sh
  ?? lib/
  ?? outgoing/

That status is completely bogus, by the way.

  artagnon|master*+=:~/src/git$ git reset --hard
  artagnon|master*+=:~/src/git$ git checkout remote-cruft
  fatal: reference is not a tree: remote-cruft
  artagnon|master=:~/src/git$ git reflog
  21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
refs/heads/remote-cruft

What happened to the rest of my reflog?!  Okay, I give up.  Let's go
back to what's present on Github.  I push often, so it's not a
problem.

  artagnon|master=:~/src/git$ git branch -D remote-cruft
  error: Couldn't look up commit object for 'refs/heads/remote-cruft'
  artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft
  artagnon|master=:~/src/git$ git checkout -b remote-cruft
  Switched to a new branch 'remote-cruft'

Huh?  What happened to my upstream?

  artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft
  warning: ignoring broken ref refs/remotes/ram/remote-cruft.

Fine, let's fetch.

  artagnon|remote-cruft:~/src/git$ git fetch ram
  remote: Counting objects: 101, done.
  remote: Compressing objects: 100% (24/24), done.
  remote: Total 92 (delta 78), reused 82 (delta 68)
  error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
  fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored
in .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt
  fatal: unpack-objects failed

Fine, let's run an fsck and get rid of all the corrupted objects.

  $ git fsck
  error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
  error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
  fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored
in .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt
  artagnon|remote-cruft:~/src/git$ rm
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6
  artagnon|remote-cruft:~/src/git$ git repack
  artagnon|remote-cruft:~/src/git$ git fetch ram
  remote: Counting objects: 101, done.
  remote: Compressing objects: 100% (24/24), done.
  remote: Total 92 (delta 78), reused 82 (delta 68)
  Unpacking objects: 100% (92/92), done.
  error: object file
.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty
  fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored
in .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt
  error: github.com:artagnon/git did not send all necessary objects

Fine, my packfiles are corrupt.  Let's unpack-objects by hand.

  artagnon|remote-cruft:~/src/git$ mv .git/objects/pack .git/objects/pack.old
  artagnon|remote-cruft+:~/src/git$ for i in
.git/objects/pack.old/*.pack; do git unpack-objects -r <$i; done
  artagnon|remote-cruft:~/src/git$ git fetch ram
  remote: Counting objects: 101, done.
  remote: Compressing objects: 100% (24/24), done.
  remote: Total 92 (delta 78), reused 82 (delta 68)
  Unpacking objects: 100% (92/92), done.
  error: object file
.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty
  fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored
in .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt
  error: github.com:artagnon/git did not send all necessary objects

  Auto packing the repository for optimum performance. You may also
  run "git gc" manually. See "git help gc" for more information.
  error: bad ref for refs/remotes/ram/remote-cruft
  error: bad ref for refs/remotes/ram/remote-cruft
  Counting objects: 161917, done.
  Delta compression using up to 8 threads.
  Compressing objects: 100% (159963/159963), done.
  Writing objects: 100% (161917/161917), done.
  Total 161917 (delta 117725), reused 0 (delta 0)
  Removing duplicate objects: 100% (256/256), done.
  error: bad ref for re

[PATCH v3 1/7] t/t7512-status-help: test "HEAD detached from"

[Ramkumar Ramachandra]

From: Junio C Hamano 

b397ea (status: show more info than "currently not on any branch",
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from.  The last
test added by that commit to t/status-help shows one example,
immediately after HEAD is detached via a checkout.  Enhance that test to
test the "HEAD detached from" message is displayed when the user further
resets to another commit.

Signed-off-by: Junio C Hamano 
Signed-off-by: Ramkumar Ramachandra 
---
 t/t7512-status-help.sh | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index bf08d4e..bafa5e7 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -667,7 +667,7 @@ test_expect_success 'status when cherry-picking after 
resolving conflicts' '
test_i18ncmp expected actual
 '
 
-test_expect_success 'status showing detached from a tag' '
+test_expect_success 'status showing detached at and from a tag' '
test_commit atag tagging &&
git checkout atag &&
cat >expected <<-\EOF
@@ -675,6 +675,14 @@ test_expect_success 'status showing detached from a tag' '
nothing to commit (use -u to show untracked files)
EOF
git status --untracked-files=no >actual &&
+   test_i18ncmp expected actual &&
+
+   git reset --hard HEAD^ &&
+   cat >expected <<-\EOF
+   # HEAD detached from atag
+   nothing to commit (use -u to show untracked files)
+   EOF
+   git status --untracked-files=no >actual &&
test_i18ncmp expected actual
 '
 
-- 
1.8.3.1.449.g41b32a4.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 v2 1/7] t/t7512-status-help: test "HEAD detached from"

[Ramkumar Ramachandra]

From: Junio C Hamano 

b397ea (status: show more info than "currently not on any branch",
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from.  The last
test added by that commit to t/status-help shows one example,
immediately after HEAD is detached via a checkout.  Enhance that test to
test the "HEAD detached from" message is displayed when the user further
resets to another commit.

Signed-off-by: Junio C Hamano 
Signed-off-by: Ramkumar Ramachandra 
---
 t/t7512-status-help.sh | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index bf08d4e..bafa5e7 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -667,7 +667,7 @@ test_expect_success 'status when cherry-picking after 
resolving conflicts' '
test_i18ncmp expected actual
 '
 
-test_expect_success 'status showing detached from a tag' '
+test_expect_success 'status showing detached at and from a tag' '
test_commit atag tagging &&
git checkout atag &&
cat >expected <<-\EOF
@@ -675,6 +675,14 @@ test_expect_success 'status showing detached from a tag' '
nothing to commit (use -u to show untracked files)
EOF
git status --untracked-files=no >actual &&
+   test_i18ncmp expected actual &&
+
+   git reset --hard HEAD^ &&
+   cat >expected <<-\EOF
+   # HEAD detached from atag
+   nothing to commit (use -u to show untracked files)
+   EOF
+   git status --untracked-files=no >actual &&
test_i18ncmp expected actual
 '
 
-- 
1.8.3.1.455.g5932b31

--
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/8] t/status-help: test "HEAD detached from"

[Ramkumar Ramachandra]

From: Junio C Hamano 

b397ea (status: show more info than "currently not on any branch",
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from.  The last
test added by that commit to t/status-help shows one example,
immediately after HEAD is detached via a checkout.  Enhance that test to
test the "HEAD detached from" message is displayed when the user further
resets to another commit.

Signed-off-by: Junio C Hamano 
Signed-off-by: Ramkumar Ramachandra 
---
 t/t7512-status-help.sh | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index bf08d4e..bafa5e7 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -667,7 +667,7 @@ test_expect_success 'status when cherry-picking after 
resolving conflicts' '
test_i18ncmp expected actual
 '
 
-test_expect_success 'status showing detached from a tag' '
+test_expect_success 'status showing detached at and from a tag' '
test_commit atag tagging &&
git checkout atag &&
cat >expected <<-\EOF
@@ -675,6 +675,14 @@ test_expect_success 'status showing detached from a tag' '
nothing to commit (use -u to show untracked files)
EOF
git status --untracked-files=no >actual &&
+   test_i18ncmp expected actual &&
+
+   git reset --hard HEAD^ &&
+   cat >expected <<-\EOF
+   # HEAD detached from atag
+   nothing to commit (use -u to show untracked files)
+   EOF
+   git status --untracked-files=no >actual &&
test_i18ncmp expected actual
 '
 
-- 
1.8.3.1.456.gb7f4cb6

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

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

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?

[Matthieu Moy]

Ramkumar Ramachandra  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:
> Michael Campbell  writes:
>> I have my global git config pager set to 'cat', but when I do a "git
>> help ", it still uses a pager.  This is especially irksome in
>> emacs shell buffers, where I am most of the time.  I know I can do a
>> M-x man -> git-, but wondered if this was a bug or user
>> error.  ("git --no-pager help " 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.

It just needs to set $PAGER or $MANPAGER before the exec(), no?  I
would argue that it should do this.  $GIT_PAGER works everywhere else,
but obviously man has no knowledge about it.

> 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 personally run M-x git-foo RET, and never run "git help".

M-x man git-foo RET, you mean?  My style is slightly different: I love
typing out 'man git log' on the terminal (dashless); I get it to open
in an Emacs buffer using this hack:

function man_ () {
emacsclient -e "(man \"$*\")" 2>&1 >/dev/null || man "$*"
}

alias man=man_
--
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  writes:

> I have my global git config pager set to 'cat', but when I do a "git
> help ", it still uses a pager.  This is especially irksome in
> emacs shell buffers, where I am most of the time.  I know I can do a
> M-x man -> git-, but wondered if this was a bug or user
> error.  ("git --no-pager help " 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

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 ", it still uses a pager.  This is especially irksome in
emacs shell buffers, where I am most of the time.  I know I can do a
M-x man -> git-, but wondered if this was a bug or user
error.  ("git --no-pager help " 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: Workflow Help

[Andreas Ericsson]

On 2013-05-21 02:59, Quilkey, Tony wrote:

Hi,

I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.

Our basic workflow will be based around:
http://nvie.com/posts/a-successful-git-branching-model, with a few
exceptions.

We would like to create our release-* branches from the last release
tag. From there, we would like the ability to cherry pick (or take the
complete diff) commits from the develop branch.

So, we are after is:

1) Create topic (feature) branches from develop, and merge back into
develop when complete.

2) Once it is decided we are packaging a release, make a release-*
branch from the previous release tag.

3) Cherry pick/merge/whatever any commits we want from develop into
the new release-* until it is complete.



This will drive you crazy. If you have any sort of tempo on development
and separate your commits into small series, it will be close to
impossible to track all related changes. I know, as some colleagues
tried it not long ago.


A better workflow is to use topic-branches for pretty much everything.
If the branch is mainly a bugfix, although the bug has to be fixed by
refactoring or remodeling something, it gets merged to whatever "maint"
branch you have (in your case I'd imagine that would be "release-X"
something). Then you merge the release-branch into develop and take
the other topics directly into develop.


We do something like this:

* work, work, work (mostly on master)
* cut a release by setting a tag and creating a maint-branch for it
  (actually, it's a beta-release that goes off to QA, but whatever)
* maint branches are 100% test-driven development
* bugfixes (with their test-cases, as well as test-cases for other
  affected areas) go directly to maint (although possibly via a
  topic-branch if the change is bigger than trivial).
* maint is merged to master
* repeat as necessary

It works reasonably well and ensures a high code quality with very
little overhead. Sometimes people commit bugfixes to master by mistake.
In that case, we simply cherry-pick the fix to 'maint' and then merge
maint back to master as usual.

It does require some sort of stability between projects and the libs
shipped by and used by the project though, but assuming you haven't
done things horribly wrong at the design stage, this model should work
reasonably well while avoiding the whole "where are the bugfixes and
in which order do I need to apply them?" issue.

--
Andreas Ericsson   andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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: Workflow Help

[Magnus Bäck]

On Monday, May 20, 2013 at 20:59 EDT,
 "Quilkey, Tony"  wrote:

> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
> 
> Our basic workflow will be based around:
> http://nvie.com/posts/a-successful-git-branching-model, with a few
> exceptions.
> 
> We would like to create our release-* branches from the last release
> tag. From there, we would like the ability to cherry pick (or take the
> complete diff) commits from the develop branch.

It would probably be easier to comment on your proposal if you motivated
why you want to diverge.

> So, we are after is:
> 
> 1) Create topic (feature) branches from develop, and merge back into
> develop when complete.
> 
> 2) Once it is decided we are packaging a release, make a release-*
> branch from the previous release tag.
> 
> 3) Cherry pick/merge/whatever any commits we want from develop into
> the new release-* until it is complete.

The point of having a release branch is typically to slow down the
development pace and reduce risk by only adding changes that you
really need. By starting the branch for release N+1 from the branch
for release N it seems you have three ways forward:

   - Cherrypick a small number of commits from develop. That'll give you
 release N+0.1 rather than N+1.
   - Cherrypick many (if not most) commits from develop. That might give
 you a real release, but with a lot of work. Who should select which
 commits to cherrypick? How do you keep track of dependencies? Why
 would you want to move from a known state (develop, where people
 spend most of their time) to an unknown state?
   - Merge from develop to the release branch. What's the benefit
 compared to cutting the release branch directly from develop?

As another poster has pointed out, with merging instead of cherrypicking
the standard Git tools will be able to do a better job at helping you
track which corrections are made where.

[...]

-- 
Magnus Bäck
ba...@google.com
--
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: Workflow Help

[John Keeping]

On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:
> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
> 
> Our basic workflow will be based around:
> http://nvie.com/posts/a-successful-git-branching-model, with a few
> exceptions.
> 
> We would like to create our release-* branches from the last release
> tag. From there, we would like the ability to cherry pick (or take the
> complete diff) commits from the develop branch.
>
> So, we are after is:
> 
> 1) Create topic (feature) branches from develop, and merge back into
> develop when complete.
> 
> 2) Once it is decided we are packaging a release, make a release-*
> branch from the previous release tag.
> 
> 3) Cherry pick/merge/whatever any commits we want from develop into
> the new release-* until it is complete.
> 
> 4) Merge the new release-* branch into master and tag it.
> 
> Repeat as necessary.
> 
> At the moment I am a little stuck on how exactly we can cherry pick
> stuff from develop into a release-* branch. I'm not even sure this
> approach is exactly what we should be doing.

Having been involved in a couple of projects that use cherry-pick like
this, I strongly advise against doing this.  It makes it much harder
than it needs to be to find out which branches contain a particular
commit.

The workflow described in the URL above does the more sensible thing of
periodically merging the release branch(es) back into master (or
develop).  This is similar to the workflow Junio uses to develop Git
itself, which is described in gitworkflows(7).

The idea is to start your topic branch from the oldest release to which
a bugfix must be applied, then merge it into the appropriate release
branches.  Then you merge this branch upwards into the later release
branches and your development branch.  So your development branch always
contains all release branches (not just similar commits, but the *same*
commits so that each release branch tip is an ancestor of the
development branch's tip).

This means that you can use "git branch --contains" or "git describe
--contains" to answer the question "which release(s) contain this
commit?", whereas with cherry picking there is no easy and reliable way
to do so.

> Our main concern is that at this stage, there is no guarantee that all
> commits within develop can be pulled into a release.

One advantage of starting a bugfix topic branch from the oldest release
it applies to is that you are developing and testing that fix on the
release code.  If it doesn't apply cleanly to the development branch
then you fix the conflict when merging.

Of course you may start a bugfix branch from the wrong place, in which
case you would have to cherry pick the commits back to an older branch,
but this should be a rare occurrence and will sort itself out as you
merge the fix upwards.

> In regards to how we can achieve the above results any input would be
> much appreciated. Or if there are any other better options available,
> I'm all ears.
--
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

Workflow Help

[Quilkey, Tony]

Hi,

I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.

Our basic workflow will be based around:
http://nvie.com/posts/a-successful-git-branching-model, with a few
exceptions.

We would like to create our release-* branches from the last release
tag. From there, we would like the ability to cherry pick (or take the
complete diff) commits from the develop branch.

So, we are after is:

1) Create topic (feature) branches from develop, and merge back into
develop when complete.

2) Once it is decided we are packaging a release, make a release-*
branch from the previous release tag.

3) Cherry pick/merge/whatever any commits we want from develop into
the new release-* until it is complete.

4) Merge the new release-* branch into master and tag it.

Repeat as necessary.

At the moment I am a little stuck on how exactly we can cherry pick
stuff from develop into a release-* branch. I'm not even sure this
approach is exactly what we should be doing.

Our main concern is that at this stage, there is no guarantee that all
commits within develop can be pulled into a release.

In regards to how we can achieve the above results any input would be
much appreciated. Or if there are any other better options available,
I'm all ears.

Thanks,

Tony Quilkey
--
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] Get stash to help rebase.autostash

[Ramkumar Ramachandra]

Hi,

This topic is based on the rebase.autostash topic.  It cleans up a few
things, introduces 'git stash store', and patches rebase to use it.
Should be simple enough.

Thanks.

Ramkumar Ramachandra (6):
  Documentation/stash: correct synopsis for create
  Documentation/stash: document short form -p in synopsis
  stash: simplify option parser for create
  stash: introduce 'git stash store'
  stash: tweak error message in store_stash ()
  rebase: use 'git stash store' to simplify logic

 Documentation/git-stash.txt | 10 --
 git-rebase.sh   |  6 +-
 git-stash.sh| 32 +---
 t/t3903-stash.sh| 20 
 4 files changed, 50 insertions(+), 18 deletions(-)

-- 
1.8.3.rc1.57.g4ac1522

--
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/2] help: add help_unknown_ref

[Vikrant Varma]

On Thursday 09 May 2013 04:19 AM, Junio C Hamano wrote:
> [...] which in turn made me realize that some commands may not even know
> if the user mistyped a ref.  It is not an objection to this patch
> per-se, but a useful future enhancement may be to allow the callers
> call guess_mistyped_ref() directly and let them decide what to do
> when they suspect the string they did not understand is not a
> mistyped ref but something else, i.e. not let help_unknown_ref() die
> unconditionally but allow it to return.  Then the caller can do:
>
>  commit = get_commit_from_string(argv[i]);
>  if (!commit) {
>  ... I do not understand argv[i], but ...
>  ... it may be a mistyped ref ...
>  help_unknown_ref(argv[i], "expected a revision");
>  ... it is not likely to be a typo ...
>  ... perhaps it was meant to be a filename? ...
>  if (file_exists(argv[i])) {
>  ... yes! ...
>  ... do the "file" thing instead ...
>  }
>  }
>

I'm apprehensive about calling guess_mistyped_ref() (or it's equivalent, 
which happens to be guess_refs()) directly, because it doesn't seem like 
a clean enough separation. When the caller thinks it's got a bad 
refname, it should just hand it over to help_unknown_ref, for further 
processing.


If autocorrect is enabled, it can get back a single corrected refname 
(that is what my next patch will include - is it okay to base it on pu?).


If the need ever did arise to get that kind of information from 
help_unknown_ref, it could always be done using callback data?


commit = get_commit_from_string(argv[i]);
if (!commit) {
... maybe mistyped ref, maybe something else ...
struct unknown_ref_cb data;
help_unknown_ref(argv[i], "expected something else",
 &data);
if (data.autocorrect)
commit = get_commit_from_string(
data.corrected_ref);
else if (data.is_file)
... do the file thing instead ...
}

I didn't see the need for this right away.

>> Example:
>>$ git merge foo
>>merge: foo - not something we can merge
>
> That leading "merge: " looks somewhat strange, especially when it
> immediately follows the command line to invoke "merge", making it
> appear to waste space by stating the obvious.
>
> Our messages are generally marked with "error:", "fatal:",
> "warning:", etc. at the beginning.

I agree, it looks strange. However the alternatives seem to be:

1) hard code 'fatal' into the error message
2) print the corrections before using die()
3) create and store the corrections string beforehand, and then call die()

1 and 3 are not elegant, and 2's output seems harder to read. I haven't 
been able to figure out a way to do this well.

--
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/2] help: add help_unknown_ref

[Junio C Hamano]

Vikrant Varma  writes:

> When a ref is not known, currently functions call die() with an
> error message.

The first part read somewhat awkward, so I started rewriting the
above like so:

When the user gives an unknown string to a command that expects
to see a ref, we could be more helpful than just saying "that's
not a ref" and die.

which in turn made me realize that some commands may not even know
if the user mistyped a ref.  It is not an objection to this patch
per-se, but a useful future enhancement may be to allow the callers
call guess_mistyped_ref() directly and let them decide what to do
when they suspect the string they did not understand is not a
mistyped ref but something else, i.e. not let help_unknown_ref() die
unconditionally but allow it to return.  Then the caller can do:

commit = get_commit_from_string(argv[i]);
if (!commit) {
... I do not understand argv[i], but ...
... it may be a mistyped ref ...
help_unknown_ref(argv[i], "expected a revision");
... it is not likely to be a typo ...
... perhaps it was meant to be a filename? ...
if (file_exists(argv[i])) {
... yes! ...
... do the "file" thing instead ...
}
}

> Add helper function help_unknown_ref to take care of displaying an
> error message along with a list of suggested refs the user might
> have meant.

OK.

> Example:
>   $ git merge foo
>   merge: foo - not something we can merge

That leading "merge: " looks somewhat strange, especially when it
immediately follows the command line to invoke "merge", making it
appear to waste space by stating the obvious.

Our messages are generally marked with "error:", "fatal:",
"warning:", etc. at the beginning.

>
>   Did you mean one of these?
>   origin/foo
>   upstream/foo
>
> Signed-off-by: Vikrant Varma 

> ...
> +struct string_list guess_refs(const char *ref)
> +{
> + struct similar_ref_cb ref_cb;
> + struct string_list similar_refs = STRING_LIST_INIT_NODUP;
> +
> + ref_cb.base_ref = ref;
> + ref_cb.similar_refs = &similar_refs;
> + for_each_ref(append_similar_ref, &ref_cb);
> + return similar_refs;
> +}
> +
> +void help_unknown_ref(const char *ref, const char *cmd, const char *error)
> +{
> + int i;
> + struct string_list suggested_refs = guess_refs(ref);
> +
> + fprintf_ln(stderr, _("%s: %s - %s"), cmd, ref, error);
> +
> + if (suggested_refs.nr > 0) {
> + fprintf_ln(stderr,
> +Q_("\nDid you mean this?",
> +   "\nDid you mean one of these?",
> +   suggested_refs.nr));
> + for (i = 0; i < suggested_refs.nr; i++)
> + fprintf(stderr, "\t%s\n", 
> suggested_refs.items[i].string);
> + }
> +
> + string_list_clear(&suggested_refs, 0);
> + exit(1);
> +}

Looks sensible.

> diff --git a/help.h b/help.h
> index 0ae5a12..5003423 100644
> --- a/help.h
> +++ b/help.h
> @@ -27,4 +27,9 @@ 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);
>  
> +/*
> + * This function has been called because ref is not known.
> + * Print a list of refs that the user might have meant, and exit.
> + */

The wording is a bit funny; I'll amend it somehow before queuing.

> +extern void help_unknown_ref(const char *ref, const char *cmd, const char 
> *error);
>  #endif /* HELP_H */
--
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

An individual Learn how to Help make pandora sale?

[backing]

* pandora uk <http://www.pandoracharmsvipsale.co.uk/>  *  produce a great
reward, any trend headline, plus a pleasurable for the vision inclusion in
your assortment. Pandora drops enjoy specific activities and also situations
simply by developing any Pandora diamond jewelry drops. They will can be
found in antithetical indications, plants and also dog imprints, emblems,
zodiac indications, shades and also materials offering an individual
countless options and also products, creating Pandorabeads equally amazing
and also specific. These kinds of drops use the particular common items
regarding day-by-day typical living. It really is your option whether or not
you employ these kinds of Pandorabeads over a wristlet or even a necklace
around your neck. 






*  http://www.pandoracharmsvipsale.co.uk/  *



--
View this message in context: 
http://git.661346.n2.nabble.com/An-individual-Learn-how-to-Help-make-pandora-sale-tp7585097.html
Sent from the git mailing list archive at Nabble.com.
--
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/2] help: add help_unknown_ref

[Vikrant Varma]

When a ref is not known, currently functions call die() with an error message.
Add helper function help_unknown_ref to take care of displaying an error
message along with a list of suggested refs the user might have meant.

Example:
$ git merge foo
merge: foo - not something we can merge

Did you mean one of these?
origin/foo
upstream/foo

Signed-off-by: Vikrant Varma 
---
 help.c |   50 ++
 help.h |5 +
 2 files changed, 55 insertions(+)

diff --git a/help.c b/help.c
index 02ba043..fe5fe67 100644
--- a/help.c
+++ b/help.c
@@ -7,6 +7,7 @@
 #include "string-list.h"
 #include "column.h"
 #include "version.h"
+#include "refs.h"
 
 void add_cmdname(struct cmdnames *cmds, const char *name, int len)
 {
@@ -404,3 +405,52 @@ int cmd_version(int argc, const char **argv, const char 
*prefix)
printf("git version %s\n", git_version_string);
return 0;
 }
+
+struct similar_ref_cb {
+   const char *base_ref;
+   struct string_list *similar_refs;
+};
+
+static int append_similar_ref(const char *refname, const unsigned char *sha1,
+ int flags, void *cb_data)
+{
+   struct similar_ref_cb *cb = (struct similar_ref_cb *)(cb_data);
+   char *branch = strrchr(refname, '/') + 1;
+   /* A remote branch of the same name is deemed similar */
+   if (!prefixcmp(refname, "refs/remotes/") &&
+   !strcmp(branch, cb->base_ref))
+   string_list_append(cb->similar_refs,
+  refname + strlen("refs/remotes/"));
+   return 0;
+}
+
+struct string_list guess_refs(const char *ref)
+{
+   struct similar_ref_cb ref_cb;
+   struct string_list similar_refs = STRING_LIST_INIT_NODUP;
+
+   ref_cb.base_ref = ref;
+   ref_cb.similar_refs = &similar_refs;
+   for_each_ref(append_similar_ref, &ref_cb);
+   return similar_refs;
+}
+
+void help_unknown_ref(const char *ref, const char *cmd, const char *error)
+{
+   int i;
+   struct string_list suggested_refs = guess_refs(ref);
+
+   fprintf_ln(stderr, _("%s: %s - %s"), cmd, ref, error);
+
+   if (suggested_refs.nr > 0) {
+   fprintf_ln(stderr,
+  Q_("\nDid you mean this?",
+ "\nDid you mean one of these?",
+ suggested_refs.nr));
+   for (i = 0; i < suggested_refs.nr; i++)
+   fprintf(stderr, "\t%s\n", 
suggested_refs.items[i].string);
+   }
+
+   string_list_clear(&suggested_refs, 0);
+   exit(1);
+}
diff --git a/help.h b/help.h
index 0ae5a12..5003423 100644
--- a/help.h
+++ b/help.h
@@ -27,4 +27,9 @@ 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);
 
+/*
+ * This function has been called because ref is not known.
+ * Print a list of refs that the user might have meant, and exit.
+ */
+extern void help_unknown_ref(const char *ref, const char *cmd, const char 
*error);
 #endif /* HELP_H */
-- 
1.7.10.4

--
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] help: add help_unknown_ref

[Junio C Hamano]

Vikrant Varma  writes:

> On 02-05-2013 00:05, Junio C Hamano wrote:
>> If you step back a bit, you would notice two things.
>>
>>   (1) Saying 'foo' when the user means 'origin/foo' is hardly the
>>   only (or even the most common) kind of mistake that the code
>>   you need to add to 'git merge' would encounter and could help
>>   the user with.
>
> Yes. I like your suggestion of using levenshtein.c, similar to what's
> been done in help.c:help_unknown_cmd. However, where do you draw the
> line? Do you also suggest 'remotes/origin/foo' for 'remotes/foo'?
> Also, which would you then prioritize for 'foo': 'fob' (this is local)
> or 'origin/foo'? In other words, what kind of mistakes are you looking
> to correct -  typos, or forgetful omissions, or both and something
> more?

This is your itch, so you get to choose what you would propose to
the list and have people tweak it ;-)

I personally think the first version should not use levenshtein _at
all_ (hence not solving my 'git checkout mastr'). I however want to
make sure the code is structured in such a way that allows other
people to build on top later.

> However, making the caller responsible for printing the suggestions
> may not be the best alternative.

That "responsibility" could be encapsulated in a separate helper
function the callers call instead of die().

The lower level machinery to come up with a suggested list of refs,
when the caller suspects that there is a typo in refs, is the same
across different commands, and it is insufficient to have a single
helper function that hardcodes "not something we can _MERGE_", and
copy the function to create many other helpers that do the same
thing but with different error messages.

You would need two layers, one that collects suggested list of refs,
and another that is directly called by the top-level caller that
takes the refname and the die message, and the latter would use the
former.  What I was showing was the lower level one, without the
higher level one that takes die message and a suspicious user input
(the higher level one would be trivial and do not need hand-holding
while designing).

--
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] help: add help_unknown_ref

[Vikrant Varma]

On 02-05-2013 00:05, Junio C Hamano wrote:

If you step back a bit, you would notice two things.

  (1) Saying 'foo' when the user means 'origin/foo' is hardly the
  only (or even the most common) kind of mistake that the code
  you need to add to 'git merge' would encounter and could help
  the user with.


Yes. I like your suggestion of using levenshtein.c, similar to what's 
been done in help.c:help_unknown_cmd. However, where do you draw the 
line? Do you also suggest 'remotes/origin/foo' for 'remotes/foo'? Also, 
which would you then prioritize for 'foo': 'fob' (this is local) or 
'origin/foo'? In other words, what kind of mistakes are you looking to 
correct -  typos, or forgetful omissions, or both and something more?



  (2) "merge" is not the single command that user may make this kind
  of mistake the command could help and use the same helper.
  "git branch myfoo foo" may want to suggest "origin/foo", for
  example.  I just typed "git checkout mater", which could have
  been easily corrected to "git checkout master" with a mechanism
  like this.



Of course, once the suggestion mechanism is in place, it can be used to 
replace unfriendly die()s in every command that takes a ref.




An asterisk sticks to the parameter name, not type

Indent with two HT, not HT followed by a run of SPs.

An overlong line can and should be split

>
> Do not add trailing blank lines.
>

Thanks, will fix this.


When you consider the point (2) above, it becomes clear why this
message does not belong to a helper function with a bland and
generic name "help unknown ref".

This API is misdesigned.  A possible alternative that may be better
reusable would be to have a helper that is used to come up with a
list of suggestions and make the caller responsible for emitting the
error message.



Yes, I think a better name is needed, I was trying to follow along the 
lines of help_unknown_cmd.


However, making the caller responsible for printing the suggestions may 
not be the best alternative. Borrowing from the way help_unknown_cmd 
works, in help_unknown_ref we could:
1) check if autocorrect is on, returning the corrected refname to the 
calling function, otherwise

2) print an error message, a list of suggestions, and exit()

I think this makes for a clean and reusable API, and requires changing 
one line of code in every function that currently calls die().



--
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] help: add help_unknown_ref

[Junio C Hamano]

Vikrant Varma  writes:

> On 02-05-2013 02:02, Ramkumar Ramachandra wrote:
>>> ref_cb.similar_refs has already been defined. The compiler won't let me
>>> assign to it unless I cast first. However, I think compound literals are a
>>> C99/gcc feature. Is this better?
>>>
>>>  struct similar_ref_cb ref_cb = {ref, STRING_LIST_INIT_NODUP};
>>
>> As Johannes pointed out, ref is a variable and that is problematic.
>> Leave the cast on: I didn't notice the compiler warning in my head.
>>
> Is it okay to use a compound literal? It's not supported in C89.

Building on top of what was suggested in the other message, the
helper could be made more reusable by doing something like this:

int suggest_misspelt_ref(const char *ref, struct string_list 
*suggested);

and the caller can do

if (!commit) {
struct string_list suggested = STRING_LIST_INIT;
if (suggest_misspelt_ref(argv[1], &suggested)) {
... Did you mean one of these??? ...
string_list_clear(&suggested);
}
die(_("'%s' is not something we can merge'), argv[1]);
}

So I think this point is moot.  Of course, similar_ref_cb needs to
be updated to keep a pointer to an existing string_list, not an
instance of its own string_list.



--
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] help: add help_unknown_ref

[Vikrant Varma]

On 02-05-2013 02:02, Ramkumar Ramachandra wrote:

ref_cb.similar_refs has already been defined. The compiler won't let me
assign to it unless I cast first. However, I think compound literals are a
C99/gcc feature. Is this better?

 struct similar_ref_cb ref_cb = {ref, STRING_LIST_INIT_NODUP};


As Johannes pointed out, ref is a variable and that is problematic.
Leave the cast on: I didn't notice the compiler warning in my head.


Is it okay to use a compound literal? It's not supported in C89.
--
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] help: add help_unknown_ref

[Ramkumar Ramachandra]

Vikrant Varma wrote:
> I agree with Matthieu, the people who don't want to see this advice never
> will, because they won't make that mistake. Maybe advice is the wrong word,
> corrections might be more appropriate.

Makes sense.

Perhaps it would make sense to hook into help.autocorrect.  I would
definitely like that.

>> I see that there are other structs in our codebase suffixing _cb, to
>> indicate "callback data".  I normally reserve _cb for callback
>> functions.
>
>
> I'm following the convention (builtin/merge.c: struct append_ref_cb). If
> there's a better way to name it, I'll use that.

Fine leaving it as it is.

> ref_cb.similar_refs has already been defined. The compiler won't let me
> assign to it unless I cast first. However, I think compound literals are a
> C99/gcc feature. Is this better?
>
> struct similar_ref_cb ref_cb = {ref, STRING_LIST_INIT_NODUP};

As Johannes pointed out, ref is a variable and that is problematic.
Leave the cast on: I didn't notice the compiler warning in my head.

> Q_ is a pluralization helper that picks one of the two strings based on
> ref_cb.similar_refs.nr. It's used in help.c:help_unknown_cmd for the same
> reason.

Thanks.

> Again, because help_unknown_cmd exited with 1. I've tried to follow the
> convention as laid down there.

Ah, I didn't notice that.

> What's the significance of the error code for
> die()?

When something _really_ bad happens, exit() with 128, without
bothering to go up the callstack.  Return error() is a common idiom to
print an error message immediately, and propagate the return status -1
up the callstack.

> When is it correct to use die(), and when to use error() followed by
> exit(128)?

exit(128) is a bit rare [grep for it yourself].  It's for when you
want to die(), but exit() only after doing an important task in the
caller.
--
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] help: add help_unknown_ref

[Johannes Sixt]

Am 01.05.2013 21:55, schrieb Vikrant Varma:
> On 01-05-2013 17:53, Ramkumar Ramachandra wrote:
>> Vikrant Varma wrote:
>>> +void help_unknown_ref(const char* ref) {
>>> +int i;
>>> +struct similar_ref_cb ref_cb;
>>> +ref_cb.similar_refs = (struct string_list)STRING_LIST_INIT_NODUP;
>>
>> Why are you casting STRING_LIST_INIT_NODUP?
>>
>>> +ref_cb.base_ref = ref;
> 
> 
> ref_cb.similar_refs has already been defined. The compiler won't let me
> assign to it unless I cast first. However, I think compound literals are
> a C99/gcc feature. Is this better?
> 
> struct similar_ref_cb ref_cb = {ref, STRING_LIST_INIT_NODUP};

No. There are compilers that can initialize a struct only with constant
data, but ref is not a constant.

-- Hannes

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