Re: [PATCH v4 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8

[David Aguilar]

On Mon, May 13, 2013 at 6:32 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
 On Mon, May 13, 2013 at 4:23 AM, David Aguilar dav...@gmail.com wrote:
 Mac OS X Mountain Lion prints warnings when building git:

 warning: 'SHA1_Init' is deprecated
 (declared at /usr/include/openssl/sha.h:121)

 Silence the warnings by using the CommonCrytpo SHA-1
 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().

 Add a COMMON_DIGEST_SHA1 option to the Makefile to allow
 choosing this implementation and define it by default on Darwin.

 The approach of adding a Makefile option for each CommonCrypto
 facility does not really scale well. For instance, these days, I
 generally build git against OpenSSL from MacPorts, which gives me a
 warning-free git build since MacPorts/OpenSSL lacks those
 Apple-specific deprecation flags. With this patch series introducing
 several Makefile knobs, people wishing to use MacPorts/OpenSSL will
 have to tweak each knob. These patches already introduce two knobs
 (COMMON_DIGEST_SHA1, COMMON_DIGEST_HMAC). Adding more knobs to silence
 the remaining 29 deprecation warnings will make the build more
 cumbersome for those who prefer OpenSSL. Instead, introducing a single
 knob (such as APPLE_COMMON_CRYPTO) would avoid this problem.

That sounds like a good idea.  In the very least these patches should
be redone to do that.

 More generally, is the approach of trying to figure out CommonCrypto
 replacements for DIGEST, HMAC, and the other 29 warnings worthwhile?
 After all, Apple introduced deprecation warnings due to the
 ABI-instability of OpenSSL, not due to any particular flaw in OpenSSL
 or its API. A more manageable approach might simply be to disable that
 particular warning on Darwin (via CFLAGS or perhaps '#pragma GCC
 diagnostic ignored' for more fine-grained control).

My only fear would be that these deprecation warnings would one day
become errors due to the functions being removed.  I don't know how
else to interpret deprecated.

If we can accomplish the same thing without deprecated APIs (and not
harm other platforms) then that is a good thing.  I doubt we can find
1:1 replacements.  It'll probably have to be fleshed out in compat/.

Warnings in 1 file (imap-send.c) is much better than warnings in 20
files (git grep -l SHA1_Final), which is the itch I'm currently
scratching.  I'll be mindful of making sure that the users can still
plug in their own compliant OpenSSL.
--
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 v9 0/9] interactive git-clean

[Jiang Xin]

Updates since v8:

 * Run interactive git-clean even if in dry_run mode. 

   -if (interactive  !dry_run  del_list.nr  0)
   +if (interactive  del_list.nr  0)
interactive_main_loop();
 
 * Variable menu_list is not static.
   (copy from global del_list, and forget to remove static)

static void print_highlight_menu_stuff(struct menu_stuff *stuff, int 
**chosen)
{
   -static struct string_list menu_list = STRING_LIST_INIT_DUP;
   +struct string_list menu_list = STRING_LIST_INIT_DUP;
struct strbuf menu = STRBUF_INIT;
int i;

 * i18n:

   @@ -567,21 +567,21 @@ static int *list_and_choose(struct menu_opts 
*opts, struct menu_stuff *stuff)
if (opts-header) {
printf_ln(%s%s%s,
  clean_get_color(CLEAN_COLOR_HEADER),
   -  opts-header,
   +  _(opts-header),
  clean_get_color(CLEAN_COLOR_RESET));
}

   ... 
   
if (opts-prompt) {
printf(%s%s%s%s,
   clean_get_color(CLEAN_COLOR_PROMPT),
   -   opts-prompt,
   -   opts-flag  MENU_OPTS_SINGLETON ?   
:  ,
   +   _(opts-prompt),
   +   opts-flags  MENU_OPTS_SINGLETON ?   
:  ,
   clean_get_color(CLEAN_COLOR_RESET));
}


   @@ -721,8 +724,8 @@ static int select_by_numbers_cmd(void)
int i, j;

   -menu_opts.prompt = Select items to delete;
   +menu_opts.prompt = N_(Select items to delete);

   -menu_opts.header = _(*** Commands ***);
   -menu_opts.prompt = What now;
   +menu_opts.header = N_(*** Commands ***);
   +menu_opts.prompt = N_(What now);
  

 * Update documentation for color.interactive and color.interactive.slot,
   because `git clean --interactive` reuses these variables from
   `git-add--interactive`.

color.interactive::
When set to `always`, always use colors for interactive prompts
   -and displays (such as those used by git-add --interactive).
   -When false (or `never`), never.  When set to `true` or `auto`, 
use
   -colors only when the output is to the terminal. Defaults to 
false.
   +and displays (such as those used by git-add --interactive and
   +git-clean --interactive). When false (or `never`), never.
   +When set to `true` or `auto`, use colors only when the output is
   +to the terminal. Defaults to false.

color.interactive.slot::
   -Use customized color for 'git add --interactive'
   -output. `slot` may be `prompt`, `header`, `help` or `error`, 
for
   -four distinct types of normal output from interactive
   -commands.  The values of these variables may be specified as
   -in color.branch.slot.
   +Use customized color for 'git add --interactive' and 'git clean
   +--interactive' output. `slot` may be `prompt`, `header`, 
`help`
   +or `error`, for four distinct types of normal output from
   +interactive commands.  The values of these variables may be
   +specified as in color.branch.slot.
 
 * Update documentation for column.clean, because we only use layout settings.

column.clean::
   -Specify whether to output cleaning files in `git clean -i` in 
columns.
   -See `column.ui` for details.
   +Specify the layout when list items in `git clean -i`, which 
always
   +shows files and directories in columns. See `column.ui` for 
details.

 * Refactor: change variables' names, such as:

   @@ -57,7 +57,7 @@ enum color_clean {
struct menu_opts {
const char *header;
const char *prompt;
   -int flag;
   +int flags;
};
 

   @@ -428,7 +428,7 @@ static int parse_choice(struct menu_stuff 
*menu_stuff,
struct strbuf input,
int **chosen)
{
   -struct strbuf **choice_list, **choice_p;
   +struct strbuf **choice_list, **ptr;
int nr = 0;
int i;

 * Refactor parse_clean_color_slot:

   @@ -80,19 +80,19 @@ struct menu_stuff {
void *stuff;
};

   -static int parse_clean_color_slot(const char *var, int ofs)
   +static int 

[PATCH v9 1/9] git-clean: refactor git-clean into two phases

[Jiang Xin]

Before introducing interactive git-clean, refactor git-clean operations
into two phases:

 * hold cleaning items in del_list,
 * and remove them in a separate loop at the end.

We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and must confirm
before do real cleaning.

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 builtin/clean.c | 103 ++--
 1 file changed, 85 insertions(+), 18 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..ccd4 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,6 +15,7 @@
 #include quote.h
 
 static int force = -1; /* unset */
+static struct string_list del_list = STRING_LIST_INIT_DUP;
 
 static const char *const builtin_clean_usage[] = {
N_(git clean [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--] 
paths...),
@@ -142,18 +143,61 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
return ret;
 }
 
+/*
+ * Give path as relative to prefix.
+ *
+ * This function is a combination of path_relative (in quote.c) and
+ * relative_path (in path.c)
+ */
+static const char *path_relative(const char *in, const char *prefix)
+{
+   static char buf[PATH_MAX + 1];
+   int off, i;
+   int len, prefix_len;
+
+   len = strlen(in);
+   if (prefix)
+   prefix_len = strlen(prefix);
+   else
+   prefix_len = 0;
+
+   off = 0;
+   i = 0;
+   while (i  prefix_len  i  len  prefix[i] == in[i]) {
+   if (prefix[i] == '/')
+   off = i + 1;
+   i++;
+   }
+   in += off;
+   len -= off;
+
+   if (i = prefix_len)
+   return in;
+
+   buf[0] = '\0';
+   while (i  prefix_len) {
+   if (prefix[i] == '/')
+   strcat(buf, ../);
+   i++;
+   }
+   strcat(buf, in);
+
+   return buf;
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
int i, res;
int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0, gone = 1;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
-   struct strbuf directory = STRBUF_INIT;
+   struct strbuf abs_path = STRBUF_INIT;
struct dir_struct dir;
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
struct exclude_list *el;
+   struct string_list_item *item;
const char *qname;
char *seen = NULL;
struct option options[] = {
@@ -223,6 +267,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
int matches = 0;
struct cache_entry *ce;
struct stat st;
+   const char *rel;
 
/*
 * Remove the '/' at the end that directory
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
continue; /* Yup, this one exists unmerged */
}
 
-   /*
-* we might have removed this as part of earlier
-* recursive directory removal, so lstat() here could
-* fail with ENOENT.
-*/
if (lstat(ent-name, st))
continue;
 
@@ -257,33 +297,60 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
}
 
if (S_ISDIR(st.st_mode)) {
-   strbuf_addstr(directory, ent-name);
if (remove_directories || (matches == MATCHED_EXACTLY)) 
{
-   if (remove_dirs(directory, prefix, rm_flags, 
dry_run, quiet, gone))
-   errors++;
-   if (gone  !quiet) {
-   qname = 
quote_path_relative(directory.buf, directory.len, buf, prefix);
-   printf(dry_run ? _(msg_would_remove) : 
_(msg_remove), qname);
-   }
+   rel = path_relative(ent-name, prefix);
+   string_list_append(del_list, rel);
}
-   strbuf_reset(directory);
} else {
if (pathspec  !matches)
continue;
-   res = dry_run ? 0 : unlink(ent-name);
+   rel = path_relative(ent-name, prefix);
+   string_list_append(del_list, rel);
+   }
+   }
+
+   /* TODO: do interactive git-clean here, which will modify del_list */
+
+   for_each_string_list_item(item, del_list) {
+   struct stat st;
+
+   if (prefix) {
+   

[PATCH v9 3/9] git-clean: show items of del_list in columns

[Jiang Xin]

When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.

Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
 Documentation/config.txt |  4 
 builtin/clean.c  | 49 +++-
 2 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53f..e031b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -955,6 +955,10 @@ column.branch::
Specify whether to output branch listing in `git branch` in columns.
See `column.ui` for details.
 
+column.clean::
+   Specify the layout when list items in `git clean -i`, which always
+   shows files and directories in columns. See `column.ui` for details.
+
 column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/builtin/clean.c b/builtin/clean.c
index 127463..d7c68 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -13,10 +13,12 @@
 #include refs.h
 #include string-list.h
 #include quote.h
+#include column.h
 
 static int force = -1; /* unset */
 static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
+static unsigned int colopts;
 
 static const char *const builtin_clean_usage[] = {
N_(git clean [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--] 
paths...),
@@ -31,8 +33,13 @@ static const char *msg_warn_remove_failed = N_(failed to 
remove %s);
 
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
-   if (!strcmp(var, clean.requireforce))
+   if (!prefixcmp(var, column.))
+   return git_column_config(var, value, clean, colopts);
+
+   if (!strcmp(var, clean.requireforce)) {
force = !git_config_bool(var, value);
+   return 0;
+   }
return git_default_config(var, value, cb);
 }
 
@@ -186,21 +193,46 @@ static const char *path_relative(const char *in, const 
char *prefix)
return buf;
 }
 
-static void interactive_main_loop(void)
+static void pretty_print_dels(void)
 {
-   struct strbuf confirm = STRBUF_INIT;
-   struct strbuf buf = STRBUF_INIT;
+   struct string_list list = STRING_LIST_INIT_DUP;
struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
const char *qname;
+   struct column_options copts;
+
+   for_each_string_list_item(item, del_list) {
+   qname = quote_path_relative(item-string, -1, buf, NULL);
+   string_list_append(list, qname);
+   }
+
+   /*
+* always enable column display, we only consult column.*
+* about layout strategy and stuff
+*/
+   colopts = (colopts  ~COL_ENABLE_MASK) | COL_ENABLED;
+   memset(copts, 0, sizeof(copts));
+   copts.indent =   ;
+   copts.padding = 2;
+   print_columns(list, colopts, copts);
+   putchar('\n');
+   strbuf_release(buf);
+   string_list_clear(list, 0);
+}
+
+static void interactive_main_loop(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
 
while (del_list.nr) {
putchar('\n');
-   for_each_string_list_item(item, del_list) {
-   qname = quote_path_relative(item-string, -1, buf, 
NULL);
-   printf(_(msg_would_remove), qname);
-   }
+   printf_ln(Q_(Would remove the following item:,
+Would remove the following items:,
+del_list.nr));
putchar('\n');
 
+   pretty_print_dels();
+
printf(_(Remove [y/n]? ));
if (strbuf_getline(confirm, stdin, '\n') != EOF) {
strbuf_trim(confirm);
@@ -226,7 +258,6 @@ static void interactive_main_loop(void)
}
}
 
-   strbuf_release(buf);
strbuf_release(confirm);
 }
 
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 4/9] git-clean: add colors to interactive git-clean

[Jiang Xin]

Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.

Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
 Documentation/config.txt | 17 +--
 builtin/clean.c  | 73 +++-
 2 files changed, 81 insertions(+), 9 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e031b..83613 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -876,16 +876,17 @@ The values of these variables may be specified as in 
color.branch.slot.
 
 color.interactive::
When set to `always`, always use colors for interactive prompts
-   and displays (such as those used by git-add --interactive).
-   When false (or `never`), never.  When set to `true` or `auto`, use
-   colors only when the output is to the terminal. Defaults to false.
+   and displays (such as those used by git-add --interactive and
+   git-clean --interactive). When false (or `never`), never.
+   When set to `true` or `auto`, use colors only when the output is
+   to the terminal. Defaults to false.
 
 color.interactive.slot::
-   Use customized color for 'git add --interactive'
-   output. `slot` may be `prompt`, `header`, `help` or `error`, for
-   four distinct types of normal output from interactive
-   commands.  The values of these variables may be specified as
-   in color.branch.slot.
+   Use customized color for 'git add --interactive' and 'git clean
+   --interactive' output. `slot` may be `prompt`, `header`, `help`
+   or `error`, for four distinct types of normal output from
+   interactive commands.  The values of these variables may be
+   specified as in color.branch.slot.
 
 color.pager::
A boolean to enable/disable colored output when the pager is in
diff --git a/builtin/clean.c b/builtin/clean.c
index d7c68..5c781 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -14,6 +14,7 @@
 #include string-list.h
 #include quote.h
 #include column.h
+#include color.h
 
 static int force = -1; /* unset */
 static int interactive;
@@ -31,16 +32,82 @@ static const char *msg_skip_git_dir = N_(Skipping 
repository %s\n);
 static const char *msg_would_skip_git_dir = N_(Would skip repository %s\n);
 static const char *msg_warn_remove_failed = N_(failed to remove %s);
 
+static int clean_use_color = -1;
+static char clean_colors[][COLOR_MAXLEN] = {
+   GIT_COLOR_RESET,
+   GIT_COLOR_NORMAL,   /* PLAIN */
+   GIT_COLOR_BOLD_BLUE,/* PROMPT */
+   GIT_COLOR_BOLD, /* HEADER */
+   GIT_COLOR_BOLD_RED, /* HELP */
+   GIT_COLOR_BOLD_RED, /* ERROR */
+};
+enum color_clean {
+   CLEAN_COLOR_RESET = 0,
+   CLEAN_COLOR_PLAIN = 1,
+   CLEAN_COLOR_PROMPT = 2,
+   CLEAN_COLOR_HEADER = 3,
+   CLEAN_COLOR_HELP = 4,
+   CLEAN_COLOR_ERROR = 5,
+};
+
+static int parse_clean_color_slot(const char *var)
+{
+   if (!strcasecmp(var, reset))
+   return CLEAN_COLOR_RESET;
+   if (!strcasecmp(var, plain))
+   return CLEAN_COLOR_PLAIN;
+   if (!strcasecmp(var, prompt))
+   return CLEAN_COLOR_PROMPT;
+   if (!strcasecmp(var, header))
+   return CLEAN_COLOR_HEADER;
+   if (!strcasecmp(var, help))
+   return CLEAN_COLOR_HELP;
+   if (!strcasecmp(var, error))
+   return CLEAN_COLOR_ERROR;
+   return -1;
+}
+
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
if (!prefixcmp(var, column.))
return git_column_config(var, value, clean, colopts);
 
+   /* honors the color.interactive* config variables which also
+  applied in git-add--interactive and git-stash */
+   if (!strcmp(var, color.interactive)) {
+   clean_use_color = git_config_colorbool(var, value);
+   return 0;
+   }
+   if (!prefixcmp(var, color.interactive.)) {
+   int slot = parse_clean_color_slot(var +
+ strlen(color.interactive.));
+   if (slot  0)
+   return 0;
+   if (!value)
+   return config_error_nonbool(var);
+   color_parse(value, var, clean_colors[slot]);
+   return 0;
+   }
+
if (!strcmp(var, clean.requireforce)) {
force = !git_config_bool(var, value);
return 0;
}
-   return git_default_config(var, value, cb);
+
+   /* inspect the color.ui config variable and others */
+   return git_color_default_config(var, value, cb);
+}
+
+static const char *clean_get_color(enum color_clean ix)
+{
+   if (want_color(clean_use_color))
+   return clean_colors[ix];
+   

[PATCH v9 6/9] git-clean: add filter by pattern interactive action

[Jiang Xin]

Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, presses ENTER and back to the confirmation dialog.

Signed-off-by: Jiang Xin worldhello@gmail.com
Suggested-by: Junio C Hamano gits...@pobox.com
---
 builtin/clean.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 7930f..80cf1 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -649,6 +649,72 @@ static int clean_cmd(void)
return MENU_RETURN_NO_LOOP;
 }
 
+static int filter_by_patterns_cmd(void)
+{
+   struct dir_struct dir;
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf **ignore_list;
+   struct string_list_item *item;
+   struct exclude_list *el;
+   int changed = -1, i;
+
+   for (;;) {
+   if (!del_list.nr)
+   break;
+
+   if (changed)
+   pretty_print_dels();
+
+   clean_print_color(CLEAN_COLOR_PROMPT);
+   printf(_(Input ignore patterns ));
+   clean_print_color(CLEAN_COLOR_RESET);
+   if (strbuf_getline(confirm, stdin, '\n') != EOF)
+   strbuf_trim(confirm);
+   else
+   putchar('\n');
+
+   /* quit filter_by_pattern mode if press ENTER or Ctrl-D */
+   if (!confirm.len)
+   break;
+
+   memset(dir, 0, sizeof(dir));
+   el = add_exclude_list(dir, EXC_CMDL, manual exclude);
+   ignore_list = strbuf_split_max(confirm, ' ', 0);
+
+   for (i = 0; ignore_list[i]; i++) {
+   strbuf_trim(ignore_list[i]);
+   if (!ignore_list[i]-len)
+   continue;
+
+   add_exclude(ignore_list[i]-buf, , 0, el, -(i+1));
+   }
+
+   changed = 0;
+   for_each_string_list_item(item, del_list) {
+   int dtype = DT_UNKNOWN;
+
+   if (is_excluded(dir, item-string, dtype)) {
+   *item-string = '\0';
+   changed++;
+   }
+   }
+
+   if (changed) {
+   string_list_remove_empty_items(del_list, 0);
+   } else {
+   clean_print_color(CLEAN_COLOR_ERROR);
+   printf_ln(_(WARNING: Cannot find items matched by: 
%s), confirm.buf);
+   clean_print_color(CLEAN_COLOR_RESET);
+   }
+
+   strbuf_list_free(ignore_list);
+   clear_directory(dir);
+   }
+
+   strbuf_release(confirm);
+   return 0;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(del_list, 0);
@@ -661,6 +727,7 @@ static int help_cmd(void)
clean_print_color(CLEAN_COLOR_HELP);
printf_ln(_(
clean   - start cleaning\n
+   filter by pattern   - exclude items from deletion\n
quit- stop cleaning\n
help- this screen\n
?   - help for prompt selection
@@ -676,6 +743,7 @@ static void interactive_main_loop(void)
struct menu_stuff menu_stuff;
struct menu_item menus[] = {
{'c', clean,  0, clean_cmd},
+   {'f', filter by pattern,  0, 
filter_by_patterns_cmd},
{'q', quit,   0, quit_cmd},
{'h', help,   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 8/9] git-clean: add ask each interactive action

[Jiang Xin]

Add a new action for interactive git-clean: ask each. It's just like
the rm -i command, that the user must confirm one by one for each
file or directory to be cleaned.

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 builtin/clean.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 74fc9..fc68b 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -752,6 +752,40 @@ static int select_by_numbers_cmd(void)
return 0;
 }
 
+static int ask_each_cmd(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct string_list_item *item;
+   const char *qname;
+   int changed = 0, eof = 0;
+
+   for_each_string_list_item(item, del_list) {
+   /* Ctrl-D should stop removing files */
+   if (!eof) {
+   qname = quote_path_relative(item-string, -1, buf, 
NULL);
+   printf(_(remove %s? ), qname);
+   if (strbuf_getline(confirm, stdin, '\n') != EOF) {
+   strbuf_trim(confirm);
+   } else {
+   putchar('\n');
+   eof = 1;
+   }
+   }
+   if (!confirm.len || !strncasecmp(confirm.buf, no, 
confirm.len)) {
+   *item-string = '\0';
+   changed++;
+   }
+   }
+
+   if (changed)
+   string_list_remove_empty_items(del_list, 0);
+
+   strbuf_release(buf);
+   strbuf_release(confirm);
+   return MENU_RETURN_NO_LOOP;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(del_list, 0);
@@ -766,6 +800,7 @@ static int help_cmd(void)
clean   - start cleaning\n
filter by pattern   - exclude items from deletion\n
select by numbers   - select items to be deleted by 
numbers\n
+   ask each- confirm each deletion (like \rm 
-i\)\n
quit- stop cleaning\n
help- this screen\n
?   - help for prompt selection
@@ -783,6 +818,7 @@ static void interactive_main_loop(void)
{'c', clean,  0, clean_cmd},
{'f', filter by pattern,  0, 
filter_by_patterns_cmd},
{'s', select by numbers,  0, 
select_by_numbers_cmd},
+   {'a', ask each,   0, ask_each_cmd},
{'q', quit,   0, quit_cmd},
{'h', help,   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 2/9] git-clean: add support for -i/--interactive

[Jiang Xin]

Show what would be done and the user must confirm before actually
cleaning.

Would remove ...
Would remove ...
Would remove ...

Remove [y/n]?

Press y to start cleaning, and press n if you want to abort.

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 Documentation/git-clean.txt | 10 ++--
 builtin/clean.c | 61 +
 2 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index bdc3a..186e34 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 
 [verse]
-'git clean' [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--] path...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--] path...
 
 DESCRIPTION
 ---
@@ -34,7 +34,13 @@ OPTIONS
 -f::
 --force::
If the Git configuration variable clean.requireForce is not set
-   to false, 'git clean' will refuse to run unless given -f or -n.
+   to false, 'git clean' will refuse to run unless given -f, -n or
+   -i.
+
+-i::
+--interactive::
+   Show what would be done and the user must confirm before actually
+   cleaning.
 
 -n::
 --dry-run::
diff --git a/builtin/clean.c b/builtin/clean.c
index ccd4..127463 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,10 +15,11 @@
 #include quote.h
 
 static int force = -1; /* unset */
+static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
 
 static const char *const builtin_clean_usage[] = {
-   N_(git clean [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--] 
paths...),
+   N_(git clean [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--] 
paths...),
NULL
 };
 
@@ -185,6 +186,50 @@ static const char *path_relative(const char *in, const 
char *prefix)
return buf;
 }
 
+static void interactive_main_loop(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct string_list_item *item;
+   const char *qname;
+
+   while (del_list.nr) {
+   putchar('\n');
+   for_each_string_list_item(item, del_list) {
+   qname = quote_path_relative(item-string, -1, buf, 
NULL);
+   printf(_(msg_would_remove), qname);
+   }
+   putchar('\n');
+
+   printf(_(Remove [y/n]? ));
+   if (strbuf_getline(confirm, stdin, '\n') != EOF) {
+   strbuf_trim(confirm);
+   } else {
+   /* Ctrl-D is the same as quit */
+   string_list_clear(del_list, 0);
+   putchar('\n');
+   printf_ln(Bye.);
+   break;
+   }
+
+   if (confirm.len) {
+   if (!strncasecmp(confirm.buf, yes, confirm.len)) {
+   break;
+   } else if (!strncasecmp(confirm.buf, no, confirm.len) 
||
+  !strncasecmp(confirm.buf, quit, 
confirm.len)) {
+   string_list_clear(del_list, 0);
+   printf_ln(Bye.);
+   break;
+   } else {
+   continue;
+   }
+   }
+   }
+
+   strbuf_release(buf);
+   strbuf_release(confirm);
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
int i, res;
@@ -204,6 +249,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
OPT__QUIET(quiet, N_(do not print names of files removed)),
OPT__DRY_RUN(dry_run, N_(dry run)),
OPT__FORCE(force, N_(force)),
+   OPT_BOOL('i', interactive, interactive, N_(interactive 
cleaning)),
OPT_BOOLEAN('d', NULL, remove_directories,
N_(remove whole directories)),
{ OPTION_CALLBACK, 'e', exclude, exclude_list, N_(pattern),
@@ -230,12 +276,16 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
if (ignored  ignored_only)
die(_(-x and -X cannot be used together));
 
-   if (!dry_run  !force) {
+   if (interactive) {
+   if (!isatty(0) || !isatty(1))
+   die(_(interactive clean can not run without a valid 
tty; 
+ refusing to clean));
+   } else if (!dry_run  !force) {
if (config_set)
-   die(_(clean.requireForce set to true and neither -n 
nor -f given; 
+   die(_(clean.requireForce set to true and neither -i, 
-n nor -f given; 
  refusing to clean));
else
-   die(_(clean.requireForce defaults to true and 

[PATCH v9 9/9] git-clean: add documentation for interactive git-clean

[Jiang Xin]

Add new section Interactive mode for documentation of interactive
git-clean.

Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
 Documentation/git-clean.txt | 65 +++--
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 186e34..5bf76 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -39,8 +39,8 @@ OPTIONS
 
 -i::
 --interactive::
-   Show what would be done and the user must confirm before actually
-   cleaning.
+   Show what would be done and clean files interactively. See
+   ``Interactive mode'' for details.
 
 -n::
 --dry-run::
@@ -69,6 +69,67 @@ OPTIONS
Remove only files ignored by Git.  This may be useful to rebuild
everything from scratch, but keep manually created files.
 
+Interactive mode
+
+When the command enters the interactive mode, it shows the
+files and directories to be cleaned, and goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt What now .  In general, when the prompt ends
+with a single '', you can pick only one of the choices given
+and type return, like this:
+
+
+*** Commands ***
+1: clean2: filter by pattern3: select by numbers
+4: ask each 5: quit 6: help
+What now 1
+
+
+You also could say `c` or `clean` above as long as the choice is unique.
+
+The main command loop has 6 subcommands.
+
+clean::
+
+   Start cleaning files and directories, and then quit.
+
+filter by pattern::
+
+   This shows the files and directories to be deleted and issues an
+   Input ignore patterns prompt. You can input space-seperated
+   patterns to exclude files and directories from deletion.
+   E.g. *.c *.h will excludes files end with .c and .h from
+   deletion. When you are satisfied with the filtered result, press
+   ENTER (empty) back to the main menu.
+
+select by numbers::
+
+   This shows the files and directories to be deleted and issues an
+   Select items to delete prompt. When the prompt ends with double
+   '' like this, you can make more than one selection, concatenated
+   with whitespace or comma.  Also you can say ranges.  E.g. 2-5 7,9
+   to choose 2,3,4,5,7,9 from the list.  If the second number in a
+   range is omitted, all remaining patches are taken.  E.g. 7- to
+   choose 7,8,9 from the list.  You can say '*' to choose everything.
+   Also when you are satisfied with the filtered result, press ENTER
+   (empty) back to the main menu.
+
+ask each::
+
+  This will start to clean, and you must confirm one by one in order
+  to delete items. Please note that this action is not as efficient
+  as the above two actions.
+
+quit::
+
+  This lets you quit without do cleaning.
+
+help::
+
+  Show brief usage of interactive git-clean.
+
 SEE ALSO
 
 linkgit:gitignore[5]
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 7/9] git-clean: add select by numbers interactive action

[Jiang Xin]

Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.

User can input:

 *  1,5-7 : select 1,5,6,7 items to be deleted
 *  * : select all items to be deleted
 *  -*: unselect all, nothing will be deleted
 *: (empty) finish selecting, and return back to main menu

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 builtin/clean.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 80cf1..74fc9 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -715,6 +715,43 @@ static int filter_by_patterns_cmd(void)
return 0;
 }
 
+static int select_by_numbers_cmd(void)
+{
+   struct menu_opts menu_opts;
+   struct menu_stuff menu_stuff;
+   struct string_list_item *items;
+   int *chosen;
+   int i, j;
+
+   menu_opts.header = NULL;
+   menu_opts.prompt = N_(Select items to delete);
+   menu_opts.flags = 0;
+
+   menu_stuff.type = MENU_STUFF_TYPE_STRING_LIST;
+   menu_stuff.stuff = del_list;
+   menu_stuff.nr = del_list.nr;
+
+   chosen = list_and_choose(menu_opts, menu_stuff);
+   items = del_list.items;
+   for(i = 0, j = 0; i  del_list.nr; i++) {
+   if (i  chosen[j]) {
+   *(items[i].string) = '\0';
+   } else if (i == chosen[j]) {
+   /* delete selected item */
+   j++;
+   continue;
+   } else {
+   /* end of chosen (chosen[j] == EOF), won't delete */
+   *(items[i].string) = '\0';
+   }
+   }
+
+   string_list_remove_empty_items(del_list, 0);
+
+   free(chosen);
+   return 0;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(del_list, 0);
@@ -728,6 +765,7 @@ static int help_cmd(void)
printf_ln(_(
clean   - start cleaning\n
filter by pattern   - exclude items from deletion\n
+   select by numbers   - select items to be deleted by 
numbers\n
quit- stop cleaning\n
help- this screen\n
?   - help for prompt selection
@@ -744,6 +782,7 @@ static void interactive_main_loop(void)
struct menu_item menus[] = {
{'c', clean,  0, clean_cmd},
{'f', filter by pattern,  0, 
filter_by_patterns_cmd},
+   {'s', select by numbers,  0, 
select_by_numbers_cmd},
{'q', quit,   0, quit_cmd},
{'h', help,   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 5/9] git-clean: use a git-add-interactive compatible UI

[Jiang Xin]

Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.

Please NOTE:

 * Method `list_and_choose` return an array of integers, and
 * it is up to you to free the allocated memory of the array.
 * The array ends with EOF.
 * If user pressed CTRL-D (i.e. EOF), no selection returned.

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 builtin/clean.c | 449 
 1 file changed, 420 insertions(+), 29 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 5c781..7930f 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -50,6 +50,36 @@ enum color_clean {
CLEAN_COLOR_ERROR = 5,
 };
 
+#define MENU_OPTS_SINGLETON01
+#define MENU_OPTS_IMMEDIATE02
+#define MENU_OPTS_LIST_ONLY04
+
+struct menu_opts {
+   const char *header;
+   const char *prompt;
+   int flags;
+};
+
+#define MENU_RETURN_NO_LOOP10
+
+struct menu_item {
+   char hotkey;
+   char *title;
+   int selected;
+   int (*fn)();
+};
+
+enum menu_stuff_type {
+   MENU_STUFF_TYPE_STRING_LIST = 1,
+   MENU_STUFF_TYPE_MENU_ITEM
+};
+
+struct menu_stuff {
+   enum menu_stuff_type type;
+   int nr;
+   void *stuff;
+};
+
 static int parse_clean_color_slot(const char *var)
 {
if (!strcasecmp(var, reset))
@@ -282,54 +312,415 @@ static void pretty_print_dels(void)
copts.indent =   ;
copts.padding = 2;
print_columns(list, colopts, copts);
-   putchar('\n');
strbuf_release(buf);
string_list_clear(list, 0);
 }
 
-static void interactive_main_loop(void)
+static void pretty_print_menus(struct string_list *menu_list)
+{
+   unsigned int local_colopts = 0;
+   struct column_options copts;
+
+   local_colopts = COL_ENABLED | COL_ROW;
+   memset(copts, 0, sizeof(copts));
+   copts.indent =   ;
+   copts.padding = 2;
+   print_columns(menu_list, local_colopts, copts);
+}
+
+static void prompt_help_cmd(int singleton)
+{
+   clean_print_color(CLEAN_COLOR_HELP);
+   printf_ln(singleton ?
+ _(Prompt help:\n
+   1  - select a numbered item\n
+   foo- select item based on unique prefix\n
+  - (empty) select nothing) :
+ _(Prompt help:\n
+   1  - select a single item\n
+   3-5- select a range of items\n
+   2-3,6-9- select multiple ranges\n
+   foo- select item based on unique prefix\n
+   -...   - unselect specified items\n
+   *  - choose all items\n
+  - (empty) finish selecting));
+   clean_print_color(CLEAN_COLOR_RESET);
+}
+
+/*
+ * display menu stuff with number prefix and hotkey highlight
+ */
+static void print_highlight_menu_stuff(struct menu_stuff *stuff, int **chosen)
+{
+   struct string_list menu_list = STRING_LIST_INIT_DUP;
+   struct strbuf menu = STRBUF_INIT;
+   int i;
+
+   if (MENU_STUFF_TYPE_MENU_ITEM == stuff-type) {
+   struct menu_item *item;
+
+   item = (struct menu_item *)stuff-stuff;
+   for (i = 0; i  stuff-nr; i++, item++) {
+   char *p;
+   int highlighted = 0;
+
+   p = item-title;
+   if ((*chosen)[i]  0)
+   (*chosen)[i] = item-selected ? 1 : 0;
+   strbuf_addf(menu, %s%2d: , (*chosen)[i] ? * :  , 
i+1);
+   for (; *p; p++) {
+   if (!highlighted  *p == item-hotkey) {
+   strbuf_addstr(menu, 
clean_get_color(CLEAN_COLOR_PROMPT));
+   strbuf_addch(menu, *p);
+   strbuf_addstr(menu, 
clean_get_color(CLEAN_COLOR_RESET));
+   highlighted = 1;
+   } else {
+   strbuf_addch(menu, *p);
+   }
+   }
+   string_list_append(menu_list, menu.buf);
+   strbuf_reset(menu);
+   }
+   } else if (MENU_STUFF_TYPE_STRING_LIST == stuff-type) {
+   struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
+   i = 0;
+
+   for_each_string_list_item(item, (struct string_list 
*)stuff-stuff) {
+   if ((*chosen)[i]  0)
+   (*chosen)[i] = 0;
+   strbuf_addf(menu, %s%2d: %s, (*chosen)[i] ? * :  
, ++i, item-string);
+   string_list_append(menu_list, 

Re: [PATCH 0/4] Coverage support revisited

[Thomas Rast]

Jens Lehmann jens.lehm...@web.de writes:

 Am 13.05.2013 23:27, schrieb Thomas Rast:
 Jens asked me at git-merge if coverage support was still available.
 Turns out it is, but there were some weirdnesses.  So this should fix
 them.  It is relly slow as you still have to run the tests one by
 one; despite claims in the wild that it is multiprocess- safe but
 thread-unsafe, I am in fact observing the opposite behavior pretty
 clearly.  (As before, it switches to sequential tests automatically,
 so you have to edit the Makefile if you want to try with parallel
 tests.)

 Thx! That might explain why the coverage run I tried today didn't
 work (I saw bogus test failures).

Indeed it does.  I should have mentioned it in the cover letter; it's
fixed by this series but if you set DEFAULT_TEST_TARGET=prove like
everyone else, it ignored the (existing) force-to-sequential rule.

 unpack-trees.c: verify_clean_submodule

 This is the one I was after. While discussing my recursive update
 code with Peff on Saturday we wondered if that function would ever
 be called. I'll check if the tests are missing some relevant cases,
 if that function can be removed or some refactoring is necessary.

 Hmm, while function coverage is already extremely useful me thinks
 lcov support would be really nice. We'd have line and branch coverage,
 which help me a lot in finding dead code and missing tests at $DAYJOB
 ... will look into that when I have the recursive update ready.

Actually if you run it, it generates submodule.c.gcov as an intermediate
step to the uncovered-functions list.  Of course you can also use any
other tool that can read gcov; the results are cleaned before the run,
not after, so they will remain in place.

Originally I hacked together an uncovered-functions list because that
list was so long that looking at things in even more detail seemed
extremely pointless.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] checkout: add --ignore-skip-worktree-bits in sparse checkout mode

[Müller Kirill]

Thank you, this looks nice. What needs to be done that this will
eventually reach the git in my favorite distribution? Which version of
Git will this be?


Cheers

Kirill


On Sat, 2013-04-13 at 09:12 +1000, Nguyễn Thái Ngọc Duy wrote:
 git checkout -- paths is usually used to restore all modified
 files in paths. In sparse checkout mode, this command is overloaded
 with another meaning: to add back all files in paths that are
 excluded by sparse patterns.
 
 As the former makes more sense for day-to-day use. Switch it to the
 default and the latter enabled with --ignore-skip-worktree-bits.

Re: [PATCH v3] checkout: add --ignore-skip-worktree-bits in sparse checkout mode

[Duy Nguyen]

On Tue, May 14, 2013 at 4:27 PM, Müller  Kirill
kirill.muel...@ivt.baug.ethz.ch wrote:
 Thank you, this looks nice. What needs to be done that this will
 eventually reach the git in my favorite distribution? Which version of
 Git will this be?

It'll be in the upcoming 1.8.3.
--
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

make git ignore the timestamp embedded in PDFs

[Andreas Leha]

Hi all,

how can I make git ignore the time stamp(s) in a PDF.  Two PDFs that
differ only in these time stamps should be considered identical.

Here is an example:
,
|  pdfinfo some.pdf
| Title:  R Graphics Output
| Creator:R
| Producer:   R 2.15.1
| CreationDate:   Thu Jan 24 13:43:31 2013 ==  these entries
| ModDate:Thu Jan 24 13:43:31 2013 ==  should be ignored
| Tagged: no
| Pages:  1
| Encrypted:  no
| Page size:  504 x 504 pts
| File size:  54138 bytes
| Optimized:  no
| PDF version:1.4
`


What I tried is a filter:
,[ ~/.gitconfig ]
| [filter pdfresetdate]
| clean = pdfresetdate
`

With this filter script:
,[ pdfresetdate ]
| #!/bin/bash
|
| FILEASARG=true
| if [ $# == 0 ]; then
| FILEASARG=false
| fi
|
| if $FILEASARG ; then
| FILENAME=$1
| else
| FILENAME=`mktemp`
| cat /dev/stdin  ${FILENAME}
| fi
|
| TMPFILE=`mktemp`
| TMPFILE2=`mktemp`
|
| ## dump the pdf metadata to a file and replace the dates
| pdftk $FILENAME dump_data | sed -e '{N;s/Date\nInfoValue: 
D:.*/Date\nInfoValue: D:19790101072619/}'  $TMPFILE
|
| ## update the pdf metadata
| pdftk $FILENAME update_info $TMPFILE output $TMPFILE2
|
| ## overwrite the original pdf
| mv -f $TMPFILE2 $FILENAME
|
| ## clean up
| rm -f $TMPFILE
| rm -f $TMPFILE2
| if [ -n $FILEASARG ] ; then
| cat $FILENAME
| fi
`


This 'works' as far as the committed pdf indeed has the date reset to my
default value.

However, when I re-checkout the files, they are marked modified by git.

So, my question is:  How can I make git *completely* ignore the embedded
date in the PDF?

Many thanks in advance for any help!

Regards,
Andreas


PS:
I had posted this question (without much success) here:
http://stackoverflow.com/questions/16058187/make-git-ignore-the-date-in-pdf-files
and with no answer on the git-users mailing list:
https://groups.google.com/forum/#!topic/git-users/KqtecNa3cOc

--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

The documentation of -S and -G is very sketchy.  Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.

References:
52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
f506b8e (git log/diff: add -Gregexp that greps in the patch text)

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 I spent some time reading the code and history to figure out what -S
 and -G really do.  I hope I've done justice.

 Documentation/diff-options.txt | 35 +++---
 Documentation/gitdiffcore.txt  | 43 +++---
 2 files changed, 52 insertions(+), 26 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 104579d..765abc5 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -383,14 +383,35 @@ ifndef::git-format-patch[]
that matches other criteria, nothing is selected.
 
 -Sstring::
-   Look for differences that introduce or remove an instance of
-   string. Note that this is different than the string simply
-   appearing in diff output; see the 'pickaxe' entry in
-   linkgit:gitdiffcore[7] for more details.
+   Look for commits where the specified string was added or
+   removed.  More precisely, find commits that change the number
+   of occurrences of the specified string.
++
+It is often useful when you're looking for an exact string (like a
+function prototype), and want to know the history of that string since
+it first came into being.
 
 -Gregex::
-   Look for differences whose added or removed line matches
-   the given regex.
+   Grep through the patch text of commits for added/removed lines
+   that match regex.  `--pickaxe-regex` is implied in this
+   mode.
++
+To illustrate the difference between `-Sregex --pickaxe-regex` and
+`-Gregex`, consider a commit with the following diff in the same
+file:
++
+
++return !regexec(regexp, two-ptr, 1, regmatch, 0);
+...
+-hit = !regexec(regexp, mf2.ptr, 1, regmatch, 0);
+
++
+While `git log -Gregexec\(regexp` will show this commit, `git log
+-Sregexec\(regexp --pickaxe-regex` will not (because the number of
+occurrences of that string didn't change).
++
+See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
+information.
 
 --pickaxe-all::
When `-S` or `-G` finds a change, show all the changes in that
@@ -399,7 +420,7 @@ ifndef::git-format-patch[]
 
 --pickaxe-regex::
Make the string not a plain string but an extended POSIX
-   regex to match.
+   regex to match.  Implied when using `-G`.
 endif::git-format-patch[]
 
 -Oorderfile::
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 568d757..39b9c51 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -222,25 +222,30 @@ version prefixed with '+'.
 diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
 -
 
-This transformation is used to find filepairs that represent
-changes that touch a specified string, and is controlled by the
--S option and the `--pickaxe-all` option to the 'git diff-*'
-commands.
-
-When diffcore-pickaxe is in use, it checks if there are
-filepairs whose result side and whose origin side have
-different number of specified string.  Such a filepair represents
-the string appeared in this changeset.  It also checks for the
-opposite case that loses the specified string.
-
-When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves
-only such filepairs that touch the specified string in its
-output.  When `--pickaxe-all` is used, diffcore-pickaxe leaves all
-filepairs intact if there is such a filepair, or makes the
-output empty otherwise.  The latter behaviour is designed to
-make reviewing of the changes in the context of the whole
-changeset easier.
-
+There are two kinds of pickaxe: the S kind (corresponding to 'git log
+-S') and the G kind (corresponding to 'git log -G').
+
+The S kind detects filepairs whose result side and origin side
+have different number of occurrences of specified string.  While
+rename detection works as usual, 'git log -S' cannot omit commits
+where a the small string being looked for is moved verbatim from one
+file to another (since the number of occurrences of that string
+changed in each of those two filepairs). The implementation
+essentially runs a count, and is significantly cheaper than the G
+kind.
+
+The G kind detects filepairs whose patch text has an added or a
+deleted line that matches the given regexp.  This means that it can
+detect in-file (or what rename-detection considers the same file)
+moves.  The implementation of 'git log -G' runs diff twice and greps,
+and this can be quite expensive.
+
+A diffcore-pickaxe option worth mentioning: `--pickaxe-all`.  When not
+in effect, diffcore-pickaxe leaves only such 

[PATCH] diffcore-pickaxe: make error messages more consistent

[Ramkumar Ramachandra]

Currently, diffcore-pickaxe reports two distinct errors for the same
user error:

$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference

$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference

Since the error has nothing to do with log-grep, change the -G error
message to match the -S error message.

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 Sorry I couldn't do more.  diffcore-pickaxe.c isn't at all easy to
 hack on, because there are so few tests guarding it.

 diffcore-pickaxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 63722f8..d69a7a2 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -122,7 +122,7 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
char errbuf[1024];
regerror(err, regex, errbuf, 1024);
regfree(regex);
-   die(invalid log-grep regex: %s, errbuf);
+   die(invalid pickaxe regex: %s, errbuf);
}
 
pickaxe(diff_queued_diff, o, regex, NULL, diff_grep);
-- 
1.8.3.rc1.61.g2cacfff

--
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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Johan Herland]

On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano gits...@pobox.com wrote:
 Junio C Hamano gits...@pobox.com writes:
 Johan Herland jo...@herland.net writes:
 Obviously, I named it '%1' since it expands into the _first_ component
 of the (slash-separated) shorthand.

 OK, I can buy something like

   %*
 refs/%*
 refs/heads/%*
 ...
 refs/remotes/%*/HEAD
 refs/remotes/%1/%2
 refs/peers/%1/heads/%2

 that is, for a pattern that has %*, we feed the end-user string as a
 whole, and for a pattern that has %1 thru %N, we find an appropriate
 way to chop the end-user string into N pieces (e.g. nick/name would
 be split into %1 = nick, %2 = name, while foo/bar/baz might have two
 possibilities, %1, %2 = foo, bar/baz or foo/bar, baz).  The
 earlier ones on the above list can even be written with their %*
 substituted with %1 if we go that route.

 Just to make sure.

 Please do not let two possibilities stop you.  As I said in the
 nearby thread, I do not necessarily insist that we must try all N
 possibilities.  We find an appropriate way could be just we
 always chop at the first slash, and %1 is what comes before it, %2
 is what comes after it.

 That will close the possibility for us to use %1 thru %N (N is
 limited to 2), but it still is We have %1 and we have %2, both fall
 into the same 'path components, numbered from left to right'
 category, and justifies the use of %1 (one, not el).

 So still no objection to %1 from me.

I think I like refs/peers/%1/heads/%* better than
refs/peers/%1/heads/%2, since the latter sort of makes me wonder
whether the 3rd, 4th, etc. components would be discarded. That said,
having %* mean the rest of the shorthand means that we must adjust
the expansion of %* for every preceding %N, which prevents us from
simplifying the code by using strbuf_expand_dict_cb() with a static
dictionary [1].

I am not sure why we would want refs/remotes/%1/%2 instead of
refs/remote/%*. Maybe I've been staring at this for too long, but I
find the latter shorter and more descriptive and the %1/%2 notation
needlessly cumbersome, especially if it's also supposed to match
foo/bar/baz

When it comes to multi-level remote names, I guess I could drop the
patch that disallows them, and still just have %1 only map to the
first component (i.e. foo/bar/baz would always be interpreted as %1
= foo, and never %1 = foo/bar). This would mean that the
foo/bar/baz shorthand notation would simply not work against
remote-tracking branch baz from remote foo/bar, but we might say
that's ok, because (a) multi-level remote names are so rare, and (b)
the simple workaround of explicitly saying
refs/peers/foo/bar/heads/baz would always be available in any case.


...Johan


[1]: Maybe we could use '%N+' to mean everything starting from
component #N? Then we could construct the following dictionary the
shorthand foo/bar/baz:

  * - foo/bar/baz
  1 - foo
  1+ - foo/bar/baz
  2 - bar
  2+ - bar/baz
etc.

But I really think this is overkill. Avoiding having to write our own
expansion helper is not _that_ important.

-- 
Johan Herland, jo...@herland.net
www.herland.net
--
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---

What happens with and without this patch to an existing user from
1.8.2 days, when she does what?

A sample answer (to show the level of descriptiveness, not the
content, I am epecting) might go something like Because the
organization is different, it will barf whenever she tries to
incrementally update from the other side. By removing the old one
1.8.3 contrib/ does not understand, at least we can unstuck her; she
ends up reimporting the whole history, though.

Trying to see if this is a 1.8.3 fast-track material.

  contrib/remote-helpers/git-remote-bzr | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/contrib/remote-helpers/git-remote-bzr 
 b/contrib/remote-helpers/git-remote-bzr
 index 3e452af..b295dd4 100755
 --- a/contrib/remote-helpers/git-remote-bzr
 +++ b/contrib/remote-helpers/git-remote-bzr
 @@ -830,6 +830,13 @@ def get_repo(url, alias):
  clone_path = os.path.join(dirname, 'clone')
  if not os.path.exists(clone_path):
  os.mkdir(clone_path)
 +else:
 +# check and remove old organization
 +try:
 +bdir = bzrlib.bzrdir.BzrDir.open(clone_path)
 +bdir.destroy_repository()
 +except bzrlib.errors.NotBranchError:
 +pass
  
  try:
  repo = origin.open_repository()
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

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

  -Sstring::
 - Look for differences that introduce or remove an instance of
 - string. Note that this is different than the string simply
 - appearing in diff output; see the 'pickaxe' entry in
 - linkgit:gitdiffcore[7] for more details.
 + Look for commits where the specified string was added or
 + removed.  More precisely, find commits that change the number
 + of occurrences of the specified string.

Any time you say This means that, More precisely, etc. please
check if you can rewrite it to lose everything before them (i.e. a
vague sentence that needs to be clarified may not have to be there
at all).

 ++
 +It is often useful when you're looking for an exact string (like a
 +function prototype), and want to know the history of that string since
 +it first came into being.

I think you should remind that the most useful case (and indeed the
intended one) is for an exact string to be a multi-line block of
text.  People often get a (wrong) impression from the word string
that it is meant to be used with a single-liner.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 The documentation of -S and -G is very sketchy.  Completely rewrite the
 sections in Documentation/diff-options.txt and
 Documentation/gitdiffcore.txt.

 References:
 52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
 f506b8e (git log/diff: add -Gregexp that greps in the patch text)

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  I spent some time reading the code and history to figure out what -S
  and -G really do.  I hope I've done justice.

  Documentation/diff-options.txt | 35 +++---
  Documentation/gitdiffcore.txt  | 43 
 +++---
  2 files changed, 52 insertions(+), 26 deletions(-)

 diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
 index 104579d..765abc5 100644
 --- a/Documentation/diff-options.txt
 +++ b/Documentation/diff-options.txt
 @@ -383,14 +383,35 @@ ifndef::git-format-patch[]
 that matches other criteria, nothing is selected.

  -Sstring::
 -   Look for differences that introduce or remove an instance of
 -   string. Note that this is different than the string simply
 -   appearing in diff output; see the 'pickaxe' entry in
 -   linkgit:gitdiffcore[7] for more details.
 +   Look for commits where the specified string was added or
 +   removed.  More precisely, find commits that change the number
 +   of occurrences of the specified string.
 ++
 +It is often useful when you're looking for an exact string (like a
 +function prototype), and want to know the history of that string since
 +it first came into being.

  -Gregex::

It looks like you have deleted the -S and -G references here.  Am I
reading this right?

 -   Look for differences whose added or removed line matches
 -   the given regex.
 +   Grep through the patch text of commits for added/removed lines
 +   that match regex.  `--pickaxe-regex` is implied in this
 +   mode.
 ++
 +To illustrate the difference between `-Sregex --pickaxe-regex` and
 +`-Gregex`, consider a commit with the following diff in the same
 +file:
 ++
 +
 ++return !regexec(regexp, two-ptr, 1, regmatch, 0);
 +...
 +-hit = !regexec(regexp, mf2.ptr, 1, regmatch, 0);
 +
 ++
 +While `git log -Gregexec\(regexp` will show this commit, `git log
 +-Sregexec\(regexp --pickaxe-regex` will not (because the number of
 +occurrences of that string didn't change).

References to git-log seem out of place to me here in git-diffcore.  I
know it's only an example, but it seems that Git normally describes
these 'reference selectors' more generically.  The generic description
may be more confusing to new users, but this patch is not the place to
consider whether it should change.

 ++
 +See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
 +information.

  --pickaxe-all::
 When `-S` or `-G` finds a change, show all the changes in that
 @@ -399,7 +420,7 @@ ifndef::git-format-patch[]

  --pickaxe-regex::
 Make the string not a plain string but an extended POSIX
 -   regex to match.
 +   regex to match.  Implied when using `-G`.
  endif::git-format-patch[]

  -Oorderfile::
 diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
 index 568d757..39b9c51 100644
 --- a/Documentation/gitdiffcore.txt
 +++ b/Documentation/gitdiffcore.txt
 @@ -222,25 +222,30 @@ version prefixed with '+'.
  diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
  -

 -This transformation is used to find filepairs that represent
 -changes that touch a specified string, and is controlled by the
 --S option and the `--pickaxe-all` option to the 'git diff-*'
 -commands.
 -
 -When diffcore-pickaxe is in use, it checks if there are
 -filepairs whose result side and whose origin side have
 -different number of specified string.  Such a filepair represents
 -the string appeared in this changeset.  It also checks for the
 -opposite case that loses the specified string.
 -
 -When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves
 -only such filepairs that touch the specified string in its
 -output.  When `--pickaxe-all` is used, diffcore-pickaxe leaves all
 -filepairs intact if there is such a filepair, or makes the
 -output empty otherwise.  The latter behaviour is designed to
 -make reviewing of the changes in the context of the whole
 -changeset easier.
 -
 +There are two kinds of pickaxe: the S kind (corresponding to 'git log
 +-S') and the G kind (corresponding to 'git log -G').

While the switches are called -S and -G, I do not think it is helpful
to name the two pickaxe options as the S kind and the G kind.

 +
 +The S kind detects filepairs whose result side and origin side
 +have different number of occurrences of specified string.  While
 +rename detection works as usual, 'git log -S' cannot omit 

Re: [PATCH] diffcore-pickaxe: make error messages more consistent

[Junio C Hamano]

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

 Currently, diffcore-pickaxe reports two distinct errors for the same
 user error:

 $ git log --pickaxe-regex -S'\1'
 fatal: invalid pickaxe regex: Invalid back reference

 $ git log -G'\1' # --pickaxe-regex is implied
 fatal: invalid log-grep regex: Invalid back reference

 Since the error has nothing to do with log-grep, change the -G error
 message to match the -S error message.

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Sorry I couldn't do more.  diffcore-pickaxe.c isn't at all easy to
  hack on, because there are so few tests guarding it.

  diffcore-pickaxe.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
 index 63722f8..d69a7a2 100644
 --- a/diffcore-pickaxe.c
 +++ b/diffcore-pickaxe.c
 @@ -122,7 +122,7 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
   char errbuf[1024];
   regerror(err, regex, errbuf, 1024);
   regfree(regex);
 - die(invalid log-grep regex: %s, errbuf);
 + die(invalid pickaxe regex: %s, errbuf);
   }
  
   pickaxe(diff_queued_diff, o, regex, NULL, diff_grep);

I am debating myself if it is truly easier to explain for users that
-G is a different variant of pickaxe.

It happens to be implemented in the same source file as pickaxe, but
they do logically quite different things.  -G does not even have a
reason to pay attention to --pickaxe-regexp (it is grep in the log
-p).

I suspect that it might avoid unnecessary confusion to explain them
as totally separate operations, and not labelling this error with
pickaxe regex.  I dunno.

--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 1:44 PM, Phil Hord phil.h...@gmail.com wrote:
 On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
 artag...@gmail.com wrote:

  -Sstring::
 -   Look for differences that introduce or remove an instance of
 -   string. Note that this is different than the string simply
 -   appearing in diff output; see the 'pickaxe' entry in
 -   linkgit:gitdiffcore[7] for more details.
 +   Look for commits where the specified string was added or
 +   removed.  More precisely, find commits that change the number
 +   of occurrences of the specified string.
 ++
 +It is often useful when you're looking for an exact string (like a
 +function prototype), and want to know the history of that string since
 +it first came into being.

  -Gregex::

 It looks like you have deleted the -S and -G references here.  Am I
 reading this right?

Doy!  Yes, I was reading it wrong.  Sorry for the noise there.

Phil
--
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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Junio C Hamano]

Johan Herland jo...@herland.net writes:

 I think I like refs/peers/%1/heads/%* better than
 refs/peers/%1/heads/%2, since the latter sort of makes me wonder
 whether the 3rd, 4th, etc. components would be discarded.

Makes sense.

 I am not sure why we would want refs/remotes/%1/%2 instead of
 refs/remote/%*.

The former way makes it easier to see what refs/peers/%1/heads/%2
means, I think, but otherwise aren't they equivalent?  I do not see
a strong reason to favor one over the other.

 remote-tracking branch baz from remote foo/bar, but we might say
 that's ok, because (a) multi-level remote names are so rare, and (b)
 the simple workaround of explicitly saying
 refs/peers/foo/bar/heads/baz would always be available in any case.

Sounds sensible.

And if you limit things that way, %1 again starts to make sense,
as you are representing the first path component with it.

--
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: AW: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

Hi all,

I tried to merge these different glossaries together (based on git de.po)
as a new wiki page [1]. You can see the diff against the current git de.po
glossary at [2]. I've also created a branch in my repository which only contains
the wiki page as a text file. This allows comments on each line of a commit,
which perhaps can be used for discussions (see [3]) and/or pull-requests?!
If we really want to use one glossary, I'm also happy with other solutions or
repositories.

The new wiki page is in WIP state and it turns out that there aren't so many
changes to the current one as I expected. I want to give a few comments on
the most important changes:

- tree = Baum
+ tree = Baum, Baum-Objekt, Tree-Objekt

Baum is already fine. Depending on the message context we could use
Baum-Objekt, but not necessarily.

- submodule = Unterprojekt
+ submodule = Submodul (suggested by JL) (before it was Unterprojekt)

I'm fine with that.

- ancestor = Vorfahre
+ ancestor = Vorfahre, Vorgänger, Vorgänger-Commit

Vorgänger sounds a bit better for me.

- repository = Projektarchiv
- bare repository = bloßes Projektarchiv
+ repository = Projektarchiv, (or just Repository?)
+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)

I'm not sure about using Repository. I think Projektarchiv is
actually good enough.

- committer = Eintragender
- tagger = Markierer
+ committer = Eintragender (or Committer, Commit-Ersteller)
+ tagger = Markierer (or Tagger, Tag-Ersteller)
...[each usage of commit and tag]...

This goes to the question if we should translate Commit and Tag.
I think we shouldn't since everyone who uses/learn Git or come from
other SCMs know what it means.

+ revision = Revision (use Commit instead (see dfb4410 (glossary: a
revision is just a commit))

So just Commit.

+ branch = Zweig (or Branch)

I think Zweig is already fine.

+ stage/index (noun) = Bereitstellung (Staging-Area, Index)
+ stage/index (verb) = stagen, für einen Commit vormerken, zur Staging
Area hinzufügen, dem Index hinzufügen
+ unstage (verb) = unstagen, aus Staging Area entfernen/nehmen, aus
Index entfernen/nehmen

I think we should replace Bereitstellung and bereitstellen. für
einen/den Commit vormerken is
nice when stage is used as a verb. When stage is used as a noun,
we have to decide between
Index and Staging Area (and Cache?) I'd prefer Index.

+ merge = Zusammenführung (Merge)

We currently translate the noun of merge as Zusammenführung and
the verb as zusammenführen.
I'd change it so der Merge and mergen.

The diff in [2] shows a couple of more changes but they're all based
on the things I've mentioned here.

[1]
https://github.com/ralfth/git-po-de/wiki/Glossary-new-WIP
[2]
https://github.com/ralfth/git-po-de/wiki/_compare/25baaa323929949283a0b920c1ef66dc16288d0b...12f08b8973bd4b7ea55779f6eb5ad3a86bac13d8
[3]
https://github.com/ralfth/git-po-de/commit/28852f8ea33ac6a9dbf7e3b17dfa00ddd4e7ecb5

Thanks,
Ralf

2013/5/13 Jan Engelhardt jeng...@inai.de:

 On Monday 2013-05-13 20:57, Ralph Haußmann wrote:

There is a glossary for the pro-git book (see [2]) but it is not up-to-date
and it is also mixed. Therefor I would like to avoid using this glossary.
I like the idea of a shared wiki (git de.po and pro-git).
I suggest a single page as overview and single pages for
complicated terms. Maybe we can use our GitHub wiki (see also [3]).

[2] https://github.com/progit/progit/blob/master/de/NOTES
[3] https://github.com/progit-de/progit/wiki/Glossar

 This is how I envision a good glossary

 http://inai.de/files/git-glossary.txt

 Maybe the Benevolent Dictator model might be better suited
 instead of a wiki? (Think of the edit wars.)
--
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] diffcore-pickaxe: make error messages more consistent

[Ramkumar Ramachandra]

Junio C Hamano wrote:
 I am debating myself if it is truly easier to explain for users that
 -G is a different variant of pickaxe.

Hm, I think it is the correct approach because readers of diffcore are
probably going to look at the source: it's not exactly an end-user
manpage.  I've not explained it as G king versus S kind in the
diff-options documentation.

Or are you just talking about the error message?  That's simple:
--pickaxe-regex is what triggers this off, and we've made it clear
that it applies to both commands (-G implicitly; see doc).
--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
 Any time you say This means that, More precisely, etc. please
 check if you can rewrite it to lose everything before them (i.e. a
 vague sentence that needs to be clarified may not have to be there
 at all).

Right.  I thought both are necessary in this case: the first sentence
gives easy information to a first-timer.  For someone who has played
with it a bit, and wants to know more: the second line.

 ++
 +It is often useful when you're looking for an exact string (like a
 +function prototype), and want to know the history of that string since
 +it first came into being.

 I think you should remind that the most useful case (and indeed the
 intended one) is for an exact string to be a multi-line block of
 text.  People often get a (wrong) impression from the word string
 that it is meant to be used with a single-liner.

Yes, I've been meaning to discuss that.  I've been having some trouble
with multi-line strings: zsh doesn't insert a TAB in the next line.
The workaround I have is to write a shell script and execute that.
How do you do it?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
 And others, please spend time on testing the 1.8.3-rc2 to make sure
 what we are going to ship is free of embarrassing regressions.

 The whole purpose of this series is to avoid regressions, that's why I
 sent them for 1.8.3.

We agreed to make an exception to let remote-bzr updates go in even
after v1.8.3-rc1, because it is too young and you can afford to
check that the updated code will give only gains to its userbase
that matters without hurting them by checking with Emacs and other
projects.

I do not recall us doing a similar exception for remote-hg.  Did we?

If we didn't, then a 10-patch series at this point in the cycle is
way too late for me to be comfortable taking.

We merged the 21-patch remote-hg series from you on Apr 21st, a week
before -rc0, and it has been 3 weeks.  Back then you thought it made
things better without regression, and I expected that loose ends
could be fixed by -rc1 with enough time to cook them in 'next'
(meaning tying such loose ends would be just the matter of a couple
of trivial patches at most).  But now you are saying they regress
things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
order not to hurt existing users?

What is going on?

People make mistakes and the initial submission being buggy is *not*
a problem per-se, but what quality assurance do the 10-patch and/or
the follow up 47-patch series have over these 21 patches to assure
us that they do not introduce more problems, when we are this close
to the final, way less than the 3 weeks we had?

The best we could do to avoid regressions (if there are reported
ones) is to revert specific changes that cause the regression that
are already in v1.8.3-rc2.  Which one(s) should we be reverting, and
do you have a regression report that says the commit(s) in question
breaks things for a specific project, and reverting it(them) makes
things work again?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

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

 ...  But now you are saying they regress
 things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
 order not to hurt existing users?

 What is going on?

Ahh, OK, I miscounted.  The 10 were supposed to replace 6 and then 47
in turn are supposed to replace the whole thing, while these are
still *not* in 'next'.

OK, will replace fc/remote-hg that is currently on 'pu' with the
latest (v4 */47).
--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Phil Hord wrote:
 References to git-log seem out of place to me here in git-diffcore.  I
 know it's only an example, but it seems that Git normally describes
 these 'reference selectors' more generically.  The generic description
 may be more confusing to new users, but this patch is not the place to
 consider whether it should change.

It's not for new users at all.  The most useful application of -S and
-G is in log.  The translation from a log -G to a diffcore -G is not
obvious at all, and warrants an explanation.

Oh, and for the user.  No user is going to type out `man gitdiffcore`
out of the blue: she's most probably led there from log, and we're
connecting the dots for her.

 While the switches are called -S and -G, I do not think it is helpful
 to name the two pickaxe options as the S kind and the G kind.

How do you describe something precisely without loss of meaning?  You
stop abstracting unnecessarily.  Read the sources: you will literally
see DIFF_PICKAXE_KIND_G there.

 +
 +The S kind detects filepairs whose result side and origin side
 +have different number of occurrences of specified string.  While
 +rename detection works as usual, 'git log -S' cannot omit commits

 The cannot omit feels like a confusing double-negative.  How about
 includes instead?

Intended.  Omission is expected.

 Is it worth mentioning that something in the documentation is worth
 mentioning?

You don't have to nitpick style.  We can allow this much creative
freedom in documentation.

 +in effect, diffcore-pickaxe leaves only such filepairs that touch the
 +specified string in its output.  When in effect, diffcore-pickaxe
 +leaves all filepairs intact if there is such a filepair, or makes the
 +output empty otherwise.  The latter behavior is designed to make
 +reviewing of the changes in the context of the whole changeset easier.

 I find this description (from the original code, not from this commit)
 somewhat confusing.  It is written from the implementer's POV.

I explained the entire -S and -G thing in terms of filepairs (and yes,
that's implementation detail).  Why would I want to explain this in
any other terms?

 Does
 this seem clearer to you?
 [...]

From diff-options.txt (the more end-user side):

When -S or -G finds a change, show all the changes in that changeset,
not just the files that contain the change in string.

Not clear enough?
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

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

 Junio C Hamano wrote:
 Any time you say This means that, More precisely, etc. please
 check if you can rewrite it to lose everything before them (i.e. a
 vague sentence that needs to be clarified may not have to be there
 at all).

 Right.  I thought both are necessary in this case: the first sentence
 gives easy information to a first-timer.  For someone who has played
 with it a bit, and wants to know more: the second line.

 ++
 +It is often useful when you're looking for an exact string (like a
 +function prototype), and want to know the history of that string since
 +it first came into being.

 I think you should remind that the most useful case (and indeed the
 intended one) is for an exact string to be a multi-line block of
 text.  People often get a (wrong) impression from the word string
 that it is meant to be used with a single-liner.

 Yes, I've been meaning to discuss that.  I've been having some trouble
 with multi-line strings: zsh doesn't insert a TAB in the next line.
 The workaround I have is to write a shell script and execute that.
 How do you do it?

I do not use zsh but with bash+readline the old tradition lnext can
be used (see stty -a output and it typically is set to ^V), i.e.
\C-v followed by \C-i should give you a literal HT.

--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Phil Hord phil.h...@gmail.com writes:

 Normally the pickaxe options limit the diff output to those files which
 contained the changes being searched; that is, those files which
 had modifications including the search string.  With the --pickaxe-all
 option, the diff of the entire commit will be shown including files
 which did not have modifications including the search string.  This
 is designed to make it easier to review the changes in the context
 of the whole commit.

I find this very readable, even though diff output might be
somewhat misleading (it is not output for the end user, but is
passing to the next stage in the pipeline).

--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
 I do not use zsh but with bash+readline the old tradition lnext can
 be used (see stty -a output and it typically is set to ^V), i.e.
 \C-v followed by \C-i should give you a literal HT.

Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
Still doesn't solve my problem though: I don't type out structs; I
paste them the X clipboard (Emacs).  And that doesn't work either on
bash or zsh.

What can we do to improve the interface?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 And others, please spend time on testing the 1.8.3-rc2 to make sure
 what we are going to ship is free of embarrassing regressions.

 If we want folks to test something, it should be the patches I
 prepared for 'next' which I just sent.

Yeah, but that is for the release _after_ 1.8.3; I'd rather see
folks help to make sure we have a solid 1.8.3 relaese.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

 What can we do to improve the interface?

Write a better shell?  Teach git gui blame to blame on arbitrary
regions instead of single lines?  I'm not sure what you're asking,
mostly because I'm not sure who we is.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

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

 +The S kind detects filepairs whose result side and origin side
 +have different number of occurrences of specified string.  While
 +rename detection works as usual, 'git log -S' cannot omit commits

 The cannot omit feels like a confusing double-negative.  How about
 includes instead?

 Intended.  Omission is expected.

I think what makes this paragraph unnecessarily hard to read is the
While rename works.

With that, you are implying if you rename a file as a whole without
changing the block of text you identify with the -S parameter, then
such a change is not interesting as far as pickaxe is concerned.
while that statement is logically correct, normal people are not
that generous to read that much between your lines.

I think that is one of the reasons why If you moved a string from
file A to file B, log -S will flag that change as worth inspecting
does not seem to logically follow and made Phil find your
description confusing.

Finding such a change indeed is a feature [*1*]; we need to flag
such a change as worth inspecting to find where the code came from
in order to dig deeper, so at least this cannot omit should be
does not omit.


[Footnote]

*1* I suspect that your confusion may stem from not understanding
what pickaxe was invented for. It is _not_ about finding the
final answer, but is about stopping at a commit that is worth
investigating further.  

It may help to read
http://article.gmane.org/gmane.comp.version-control.git/217 and
then its follow-up http://gitster.livejournal.com/35628.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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 2:44 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 Phil Hord wrote:
 References to git-log seem out of place to me here in git-diffcore.  I
 know it's only an example, but it seems that Git normally describes
 these 'reference selectors' more generically.  The generic description
 may be more confusing to new users, but this patch is not the place to
 consider whether it should change.

 It's not for new users at all.  The most useful application of -S and
 -G is in log.  The translation from a log -G to a diffcore -G is not
 obvious at all, and warrants an explanation.

 Oh, and for the user.  No user is going to type out `man gitdiffcore`
 out of the blue: she's most probably led there from log, and we're
 connecting the dots for her.

She may have been led here by some other help topic, too.  Maybe the
git log examples belong in the git-log documentation.

 While the switches are called -S and -G, I do not think it is helpful
 to name the two pickaxe options as the S kind and the G kind.

 How do you describe something precisely without loss of meaning?  You
 stop abstracting unnecessarily.  Read the sources: you will literally
 see DIFF_PICKAXE_KIND_G there.

S and G are abstractions.

DIFF_PICKAXE_KIND_G is an implementer's distinction.

I agree this is a tricky subject.  When writing technical
documentation you must be precise and clear.  It is easy to forget
both.  It is common to forget to be either clear or precise.  It is
very difficult to be both clear and precise.

So, my suggestion is to use some meaningful names for the action of -S
and -G.  Relating these names to -S and -G in a clear way is likely to
be difficult.

 +
 +The S kind detects filepairs whose result side and origin side
 +have different number of occurrences of specified string.  While
 +rename detection works as usual, 'git log -S' cannot omit commits

 The cannot omit feels like a confusing double-negative.  How about
 includes instead?

 Intended.  Omission is expected.

This is precision at the expense of clarity.  Omission is not expected
for the user who wants to ask this question:  Where is that commit
that added 'foo'?  To Git she wants to ask Show me the commit that
added or removed 'foo'.  You and I both know that Git does this in
reverse.  Git translates this question into Show all the commits, but
hide the ones which do not add or remove 'foo'.

And so we say Git 'cannot omit' commits



 Is it worth mentioning that something in the documentation is worth
 mentioning?

 You don't have to nitpick style.  We can allow this much creative
 freedom in documentation.

I think I do.  The concepts in here are complicated enough without
loading the language with excess verbiage.  I am chronically afflicted
with this disease where I am always adding extra decorations to my
sentences.  I work hard to combat that, especially when dealing with
technical writings.  This makes it easy for me to recognize in other
technical writing.

I didn't look closely, but these unnecessary introductory clause
appeared to be the only change in this paragraph.  I do not think it
adds anything, which is why I mentioned it.

I could have been more clear and less flippant about it, though.  I'm
sorry if my manner was offensive. This is another chronic problem I
seem to have.


 +in effect, diffcore-pickaxe leaves only such filepairs that touch the
 +specified string in its output.  When in effect, diffcore-pickaxe
 +leaves all filepairs intact if there is such a filepair, or makes the
 +output empty otherwise.  The latter behavior is designed to make
 +reviewing of the changes in the context of the whole changeset easier.

 I find this description (from the original code, not from this commit)
 somewhat confusing.  It is written from the implementer's POV.

 I explained the entire -S and -G thing in terms of filepairs (and yes,
 that's implementation detail).  Why would I want to explain this in
 any other terms?

Clarity.

What is a 'filepair' when I am getting a short-log?  Internally there
was a diff, and the diff involves pairs of files.  But it's a tedious
detail to the user which might send her off needlessly trying to
understand the meaning of the term.

But you are right; gitdiffcore.txt is about precision and
implementation.  The goal is to address the technical user who is
trying to understand these operations in general, not just for log.
'filepairs' is a useful concept to lean on.

The clearer description probably belongs in git-log.

 Does
 this seem clearer to you?
 [...]

 From diff-options.txt (the more end-user side):

 When -S or -G finds a change, show all the changes in that changeset,
 not just the files that contain the change in string.

 Not clear enough?

Yes, it was clear enough to me in git-log.  Perhaps it is not worth
mentioning here.

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

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
 Write a better shell?

Shell, editor.  Both are very hard problems, and the successful
projects last many years (emacs, zsh are over 20 years old).

 Teach git gui blame to blame on arbitrary
 regions instead of single lines?

Or in my case: get magit to do log -S.

Should we mention in the -S documentation that temporary shell script
is the way to get multi-line input?
--
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] diffcore-pickaxe doc: document -S and -G properly

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

 Should we mention in the -S documentation that temporary shell script
 is the way to get multi-line input?

No, because for almost everyone it isn't.

An example in the EXAMPLES section including an aside that you might
have to hit ^V to enter a tab could be useful, though.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

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

 Junio C Hamano wrote:
 I do not use zsh but with bash+readline the old tradition lnext can
 be used (see stty -a output and it typically is set to ^V), i.e.
 \C-v followed by \C-i should give you a literal HT.

 Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
 Still doesn't solve my problem though: I don't type out structs; I
 paste them the X clipboard (Emacs).  And that doesn't work either on
 bash or zsh.

 What can we do to improve the interface?

Heh, I seem to have just found a volunteer to finish the Linus's
dream by following up on http://gitster.livejournal.com/35628.html
(see section #5; I do not do GUI, neither Linus, so this has been a
four-year old dream).
--
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: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Torsten Bögershausen]

On 2013-05-09 19.18, Ramsay Jones wrote:
 Torsten Bögershausen wrote:
 On 2013-05-04 01.14, Junio C Hamano wrote:

  Cygwin portability; both were reviewed by Jonathan, and the tip one
  seems to want a bit further explanation.  Needs positive report
  from Cygwin 1.7 users who have been on 1.7 to make sure it does not
  regress for them.

 I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.

 Running the test suite under cygwin doesn't seem to work any more (?):

 Scenario 1:
 The PC is running alone, and goes into the screen saver.
 Pressing CTRL-ALT-DEL didn't get any effect.

 Scenario 2:
 The PC didn't react any more, when the test suite was run in background.
 In 3 or 4 cases the PC needed to be reboot hardly.

 Using the commits before and after this change makes the test suite hang 
 as well at some point, then it hangs somewhere at TC 3000--4000.

 Scenario 4:
 The I disabled the screensaver, upgdated cygwin,
  and went back to an older commit:
 The latest run from commit 52d63e70, April 28,
 hangs in TC 5500, ok 26 clone shallow object count.

 I can see 2 times 
 git.exe pull --depth 4 ..A 

 Scenario 5:
 The run of today 1.8.3-rc1, hangs in t5510,
 some git.exe are running fetch. (or pull)


 It seems as if some process/exes are not terminated
 in the way it should be.

 I will try on a different machine,
 comments are wellcome
 
 Hmm, I'm a little puzzled, but not shocked. ;-)
 
 Somebody, I forget who, had already tested Jonathan's patch
 on cygwin 1.7 successfully and my follow up patch should be
 a no-op on cygwin 1.7; so I'm puzzled! (The high risk should
 have been on cygwin 1.5).
 
 I'm not shocked because running the test-suite on cygwin has
 been a bit of a magical mystery tour for quite some time.
 
 In about 2007, I could not run the test-suite for about six
 to nine months; it would randomly wedge my laptop solid - I had
 to pull the power-cord out in order to re-boot. (I suspect that
 commit 9cb18f56fde may have cured that particular problem, but
 don't quote me on that - I didn't investigate at the time.)
 
 I have noticed that running the tests with 'prove' is more likely
 to prove successful, so my config.mak looks like:
 
 $ cat config.mak
 NO_SVN_TESTS=1
 GIT_TEST_OPTS=--no-color
 NO_GETTEXT=1
 DEFAULT_TEST_TARGET=prove
 GIT_PROVE_OPTS='--timer'
 $
 
 I currently run the tests like so:
 
 $ time $(GIT_SKIP_TESTS='t0061.3 t0070.3 t4130 t9010 t9300' make test \
 test-outp13 21)
 
 real172m25.311s
 user132m15.133s
 sys 66m43.122s
 $
 
 The t0061.3 and t0070.3 failures don't require much discussion. The t4130
 failure is an intermittent racy git issue that has been on my TODO list
 for several years. t9300 also fails intermittently. However, t9010 fails
 every time for me, hanging the test suite (although ^C interrupts it just
 fine).
 
 I have a fix for t9010 that looks like:
 
 diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
 index b7eed24..4d01e3b 100755
 --- a/t/t9010-svn-fe.sh
 +++ b/t/t9010-svn-fe.sh
 @@ -22,10 +22,9 @@ try_dump () {
 maybe_fail_fi=${3:+test_$3} 
 
 {
 -   $maybe_fail_svnfe test-svn-fe $input stream 3backflow 
 
 -   } 
 -   $maybe_fail_fi git fast-import --cat-blob-fd=3 stream 3backflow 
 
 -   wait $!
 +   $maybe_fail_svnfe test-svn-fe $input 3backflow
 +   } |
 +   $maybe_fail_fi git fast-import --cat-blob-fd=3 3backflow
  }
 
  properties () {
 
 but I have not tested this patch enough to be happy to submit it (I have
 some suspicions that it would still fail intermittently, just like t9300).
 
 Also, commit 7bc0911d (test-lib: Fix say_color () not to interpret \a\b\c
 in the message, 11-10-2012) caused several random test failures. (don't ask
 me why). So, before each test run, I have to apply the following:
 
 diff --git a/t/test-lib.sh b/t/test-lib.sh
 index f50f834..ed32b7f 100644
 --- a/t/test-lib.sh
 +++ b/t/test-lib.sh
 @@ -230,7 +230,7 @@ else
 say_color() {
 test -z $1  test -n $quiet  return
 shift
 -   printf %s\n $*
 +   echo -E $*
 }
  fi
 
 which effectively reverts that commit.
 
 So, as I said, a magical mystery tour. :-D
 
 ATB,
 Ramsay Jones
 
 
First of all,
the patch we are talking about does not any regrssions at my side.

Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

Turning the screen saver off in Win XP helps that the machine reacts,
and using process explorer showed that the hanging is happening
in test cases doing git fetch (or git pull) from a local repository.
What I can see is one git-fetch.exe together with git-upload-pack.exe

From my understanding is the upload-pack a forked exe from the main git,
and they should talk to each 

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
 I think what makes this paragraph unnecessarily hard to read is the
 While rename works.

 With that, you are implying if you rename a file as a whole without
 changing the block of text you identify with the -S parameter, then
 such a change is not interesting as far as pickaxe is concerned.
 while that statement is logically correct, normal people are not
 that generous to read that much between your lines.

Yes, I'm exactly implying that.  But I don't want to lose meaning: in
the previous sentence, I talk about filepairs.  I want to point out
that rename detection working at the filepair level is a perfectly
normal thing.

 I think that is one of the reasons why If you moved a string from
 file A to file B, log -S will flag that change as worth inspecting
 does not seem to logically follow and made Phil find your
 description confusing.

Sure, we can elaborate a bit more.

 Finding such a change indeed is a feature [*1*]; we need to flag
 such a change as worth inspecting to find where the code came from
 in order to dig deeper, so at least this cannot omit should be
 does not omit.

What I was trying to say is that it's an accidental feature: the
reason this feature exists is because diffcore is tied to filepairs
(and rename detection works at the filepair level).  You may argue
that there's nothing wrong with this design, but consider what happens
if you rebase on top of a big code move: it's completely broken.  If
git were a true content tracker, and file boundaries really did not
matter, isn't this feature actually a deficiency?

Ofcourse, the user doesn't need to know all this, and does not omit
is a good suggestion.
--
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: make git ignore the timestamp embedded in PDFs

[Johannes Sixt]

Am 14.05.2013 15:17, schrieb Andreas Leha:
 Hi all,
 
 how can I make git ignore the time stamp(s) in a PDF.  Two PDFs that
 differ only in these time stamps should be considered identical.
 ...
 What I tried is a filter:
 ,[ ~/.gitconfig ]
 | [filter pdfresetdate]
 | clean = pdfresetdate
 `
 
 This 'works' as far as the committed pdf indeed has the date reset to my
 default value.
 
 However, when I re-checkout the files, they are marked modified by git.

I'm using cleaned files every now and then, but not on Linux. I have
never observed this behavior recently.

If you 'git add' the file, does it keep its modified state? Does 'git
diff' tell a difference?

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

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

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

 What I was trying to say is that it's an accidental feature

There is nothing accidental about it.  It was a very conscious
design decision.

When a commit moves a file wholesale without affecting the block of
code you are interested in, you know that whole block came from the
file in the old tree at pre-rename location without looking at
anywhere else.  That is why renamed but pickaxe-uninteresting
filepairs are dropped.

When a commit moves (some lines of) the block of code you are
interested in from one file to another, it may have been a single
instance moving to another place, but it may well have been multiple
copies consolidated into one (the new copy, pickaxe digging from
future to past may see disappearing).  That is a significant event
worth digging into further by first stopping there and then
inspecting the whole change with --pickaxe-all to see what changes
that are similar to the change in question exist in the other parts
(notice the multiple) of the tree.

If you do not understand it, then you really should re-read
$gmane/217 and then its explanation I wrote 4 years ago (both of
which I already gave you URLs to in this thread).

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/10] remote-hg: fixes and cleanups

[Felipe Contreras]

On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
 And others, please spend time on testing the 1.8.3-rc2 to make sure
 what we are going to ship is free of embarrassing regressions.

 The whole purpose of this series is to avoid regressions, that's why I
 sent them for 1.8.3.

 We agreed to make an exception to let remote-bzr updates go in even
 after v1.8.3-rc1, because it is too young and you can afford to
 check that the updated code will give only gains to its userbase
 that matters without hurting them by checking with Emacs and other
 projects.

 I do not recall us doing a similar exception for remote-hg.  Did we?

The exception was for massive changes, theses are not massive changes,
they are no-brainer fixes that would possibly fix regressions.

 If we didn't, then a 10-patch series at this point in the cycle is
 way too late for me to be comfortable taking.

Well, don't blame me if users hit regressions then.

 We merged the 21-patch remote-hg series from you on Apr 21st, a week
 before -rc0, and it has been 3 weeks.  Back then you thought it made
 things better without regression, and I expected that loose ends
 could be fixed by -rc1 with enough time to cook them in 'next'
 (meaning tying such loose ends would be just the matter of a couple
 of trivial patches at most).  But now you are saying they regress
 things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
 order not to hurt existing users?

 What is going on?

No, I sent *four* patches for 'master', which I eventually increased
to ten, because the increased ones are all simple cleanups.

And the fixes are obvious and can't possibly introduce regressions,
specially since the important change re-introduces the same behavior
we had in v1.8.2.

The 47 patches I sent are for 'next', and are clearly marked as so. I
included the same 10 fixes I sent for 'master', because they never
landed on master.

 People make mistakes and the initial submission being buggy is *not*
 a problem per-se, but what quality assurance do the 10-patch and/or
 the follow up 47-patch series have over these 21 patches to assure
 us that they do not introduce more problems, when we are this close
 to the final, way less than the 3 weeks we had?

Read the patches and you would see.

 The best we could do to avoid regressions (if there are reported
 ones) is to revert specific changes that cause the regression that
 are already in v1.8.3-rc2.  Which one(s) should we be reverting, and
 do you have a regression report that says the commit(s) in question
 breaks things for a specific project, and reverting it(them) makes
 things work again?

I am going to go one by one to show you the patches make sense for 'master'.

-- 
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
 When a commit moves a file wholesale without affecting the block of
 code you are interested in, you know that whole block came from the
 file in the old tree at pre-rename location without looking at
 anywhere else.  That is why renamed but pickaxe-uninteresting
 filepairs are dropped.

 When a commit moves (some lines of) the block of code you are
 interested in from one file to another, it may have been a single
 instance moving to another place, but it may well have been multiple
 copies consolidated into one (the new copy, pickaxe digging from
 future to past may see disappearing).  That is a significant event
 worth digging into further by first stopping there and then
 inspecting the whole change with --pickaxe-all to see what changes
 that are similar to the change in question exist in the other parts
 (notice the multiple) of the tree.

Makes sense.  I wasn't looking at it from a macro perspective.

Yeah, I constantly re-read 217 and your follow-up.
--
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---

 What happens with and without this patch to an existing user from
 1.8.2 days, when she does what?

I already explained it would prevent the new shared repository
organization from working, so the old organization would be used; the
repositories won't be shared.

 A sample answer (to show the level of descriptiveness, not the
 content, I am epecting) might go something like Because the
 organization is different, it will barf whenever she tries to
 incrementally update from the other side. By removing the old one
 1.8.3 contrib/ does not understand, at least we can unstuck her; she
 ends up reimporting the whole history, though.

Bazaar won't barf, the repositories will be duplicated, so the shared
feature won't work.

-- 
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 v3 00/10] remote-hg: fixes and cleanups

[Felipe Contreras]

On Tue, May 14, 2013 at 1:59 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 And others, please spend time on testing the 1.8.3-rc2 to make sure
 what we are going to ship is free of embarrassing regressions.

 If we want folks to test something, it should be the patches I
 prepared for 'next' which I just sent.

 Yeah, but that is for the release _after_ 1.8.3; I'd rather see
 folks help to make sure we have a solid 1.8.3 relaese.

That's the intention of the ten patches I sent for 1.8.3. But you said
you are not going to put them in 'master', but in 'next', so I sent
the ones I think should go into next.

So now you have the patches that I think should go into 'master' (10),
and the ones for 'next' (47, including the previous unmerged 10).

-- 
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 v3 01/10] remote-hg: trivial cleanups

[Felipe Contreras]

This is a trivial cleanup, cannot cause regressions.

Felipe Contreras wrote:
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 2 +-
  contrib/remote-helpers/test-hg-hg-git.sh | 2 --
  2 files changed, 1 insertion(+), 3 deletions(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 96ad30d..d33c7ba 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -538,7 +538,7 @@ def list_head(repo, cur):
  g_head = (head, node)
  
  def do_list(parser):
 -global branches, bmarks, mode, track_branches
 +global branches, bmarks, track_branches
  
  repo = parser.repo
  for bmark, node in bookmarks.listbookmarks(repo).iteritems():
 diff --git a/contrib/remote-helpers/test-hg-hg-git.sh 
 b/contrib/remote-helpers/test-hg-hg-git.sh
 index 8440341..0c36573 100755
 --- a/contrib/remote-helpers/test-hg-hg-git.sh
 +++ b/contrib/remote-helpers/test-hg-hg-git.sh
 @@ -455,8 +455,6 @@ test_expect_success 'hg author' '
   git_log gitrepo-$x  git-log-$x
   done 
  
 - test_cmp git-log-hg git-log-git 
 -
   test_cmp hg-log-hg hg-log-git 
   test_cmp git-log-hg git-log-git
  '
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 02/10] remote-hg: get rid of unused exception checks

[Felipe Contreras]

This is removing an exception check and since that exception is thrown by
check_output() but not Popen(), this doesn't change anything.

Felipe Contreras wrote:
 We are not calling check_output() anymore.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 24 +---
  1 file changed, 9 insertions(+), 15 deletions(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index d33c7ba..9d6940b 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -327,11 +327,8 @@ def get_repo(url, alias):
  myui.setconfig('ui', 'interactive', 'off')
  myui.fout = sys.stderr
  
 -try:
 -if get_config('remote-hg.insecure') == 'true\n':
 -myui.setconfig('web', 'cacerts', '')
 -except subprocess.CalledProcessError:
 -pass
 +if get_config('remote-hg.insecure') == 'true\n':
 +myui.setconfig('web', 'cacerts', '')
  
  try:
  mod = extensions.load(myui, 'hgext.schemes', None)
 @@ -910,16 +907,13 @@ def main(args):
  track_branches = True
  force_push = True
  
 -try:
 -if get_config('remote-hg.hg-git-compat') == 'true\n':
 -hg_git_compat = True
 -track_branches = False
 -if get_config('remote-hg.track-branches') == 'false\n':
 -track_branches = False
 -if get_config('remote-hg.force-push') == 'false\n':
 -force_push = False
 -except subprocess.CalledProcessError:
 -pass
 +if get_config('remote-hg.hg-git-compat') == 'true\n':
 +hg_git_compat = True
 +track_branches = False
 +if get_config('remote-hg.track-branches') == 'false\n':
 +track_branches = False
 +if get_config('remote-hg.force-push') == 'false\n':
 +force_push = False
  
  if hg_git_compat:
  mode = 'hg'
 -- 
 1.8.3.rc1.579.g184e698

-- 
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 v3 03/10] remote-hg: enable track-branches in hg-git mode

[Felipe Contreras]

No regression here either, we simply give more power to the user.

Felipe Contreras wrote:
 The user can turn this off.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 1 -
  contrib/remote-helpers/test-hg-hg-git.sh | 1 +
  2 files changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 9d6940b..de3a96e 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -909,7 +909,6 @@ def main(args):
  
  if get_config('remote-hg.hg-git-compat') == 'true\n':
  hg_git_compat = True
 -track_branches = False
  if get_config('remote-hg.track-branches') == 'false\n':
  track_branches = False
  if get_config('remote-hg.force-push') == 'false\n':
 diff --git a/contrib/remote-helpers/test-hg-hg-git.sh 
 b/contrib/remote-helpers/test-hg-hg-git.sh
 index 0c36573..7f579c8 100755
 --- a/contrib/remote-helpers/test-hg-hg-git.sh
 +++ b/contrib/remote-helpers/test-hg-hg-git.sh
 @@ -102,6 +102,7 @@ setup () {
   )  $HOME/.hgrc 
   git config --global receive.denycurrentbranch warn
   git config --global remote-hg.hg-git-compat true
 + git config --global remote-hg.track-branches false
  
   HGEDITOR=/usr/bin/true
  
 -- 
 1.8.3.rc1.579.g184e698

-- 
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 v3 04/10] remote-hg: add new get_config_bool() helper

[Felipe Contreras]

This is simply refactoring code, functionally they are the same.

Felipe Contreras wrote:
 No functional changes.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 24 +---
  1 file changed, 13 insertions(+), 11 deletions(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index de3a96e..4a5c72f 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -87,6 +87,15 @@ def get_config(config):
  output, _ = process.communicate()
  return output
  
 +def get_config_bool(config, default=False):
 +value = get_config(config).rstrip('\n')
 +if value == true:
 +return True
 +elif value == false:
 +return False
 +else:
 +return default
 +
  class Marks:
  
  def __init__(self, path):
 @@ -327,7 +336,7 @@ def get_repo(url, alias):
  myui.setconfig('ui', 'interactive', 'off')
  myui.fout = sys.stderr
  
 -if get_config('remote-hg.insecure') == 'true\n':
 +if get_config_bool('remote-hg.insecure'):
  myui.setconfig('web', 'cacerts', '')
  
  try:
 @@ -903,16 +912,9 @@ def main(args):
  url = args[2]
  peer = None
  
 -hg_git_compat = False
 -track_branches = True
 -force_push = True
 -
 -if get_config('remote-hg.hg-git-compat') == 'true\n':
 -hg_git_compat = True
 -if get_config('remote-hg.track-branches') == 'false\n':
 -track_branches = False
 -if get_config('remote-hg.force-push') == 'false\n':
 -force_push = False
 +hg_git_compat = get_config_bool('remote-hg.hg-git-compat')
 +track_branches = get_config_bool('remote-hg.track-branches', True)
 +force_push = get_config_bool('remote-hg.force-push', True)
  
  if hg_git_compat:
  mode = 'hg'
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 05/10] remote-hg: fix new branch creation

[Felipe Contreras]

This is the first fix, but it's obvious this is what we want: if a user creates
a new branch with git:

 % git checkout -b branches/devel

And then pushes this branch

 % git push origin branches/devel

(which is the way to push new mercurial branches)

We obviously want to create a branch, but the command would fail, and the fix
is simple: tell the push that we might create new branches.

This only matters when foce_push=False.

Can't possibly introduce regressions, unless you think of the ability to push
new branches as a regression.

Felipe Contreras wrote:
 When force_push is disabled, we need to turn the argument to True.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 4a5c72f..3cf9b4c 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -856,7 +856,7 @@ def do_export(parser):
  continue
  
  if peer:
 -parser.repo.push(peer, force=force_push)
 +parser.repo.push(peer, force=force_push, newbranch=True)
  
  # handle bookmarks
  for bmark, node in p_bmarks:
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 06/10] remote-hg: disable forced push by default

[Felipe Contreras]

And here is the important fix. We are essentially reverting back to the old
v1.8.2 behavior, to minimize the possibility of regressions, but in a way the
user can configure.

The cleanups before made it so this patch eas easy and simple.

And the fix before this makes it so the new default force_push=False still is
able to push new branches, so we don't disable other v1.8.3 features.

Felipe Contreras wrote:
 In certain situations we might end up pushing garbage revisions (e.g. in
 a rebase), and the patches to deal with that haven't been merged yet.
 
 So let's disable forced pushes by default.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 3cf9b4c..53412dd 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -914,7 +914,7 @@ def main(args):
  
  hg_git_compat = get_config_bool('remote-hg.hg-git-compat')
  track_branches = get_config_bool('remote-hg.track-branches', True)
 -force_push = get_config_bool('remote-hg.force-push', True)
 +force_push = get_config_bool('remote-hg.force-push')
  
  if hg_git_compat:
  mode = 'hg'
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 07/10] remote-hg: don't push fake 'master' bookmark

[Felipe Contreras]

We obviously don't want to push our fake 'master' bookmark to the remote. This
is an obvious good change.

Felipe Contreras wrote:
 We skip it locally, but not for the remote, so let's do so.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 53412dd..beb864b 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -873,7 +873,8 @@ def do_export(parser):
  
  if bmark == 'master' and 'master' not in parser.repo._bookmarks:
  # fake bookmark
 -pass
 +print ok %s % ref
 +continue
  elif bookmarks.pushbookmark(parser.repo, bmark, old, new):
  # updated locally
  pass
 -- 
 1.8.3.rc1.579.g184e698

-- 
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 v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

Without this fix, the user would never ever see new bookmarks, only the ones
that (s)he initially cloned.

Felipe Contreras wrote:
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index beb864b..dc276af 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -363,6 +363,9 @@ def get_repo(url, alias):
  die('Repository error')
  repo.pull(peer, heads=None, force=True)
  
 +rb = peer.listkeys('bookmarks')
 +bookmarks.updatefromremote(myui, repo, rb, url)
 +
  return repo
  
  def rev_to_mark(rev):
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 09/10] remote-hg: test: be a little more quiet

[Felipe Contreras]

No-brainer; improve one test.

Felipe Contreras wrote:
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/test-hg.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/contrib/remote-helpers/test-hg.sh 
 b/contrib/remote-helpers/test-hg.sh
 index 8de2aa7..f8d1f9e 100755
 --- a/contrib/remote-helpers/test-hg.sh
 +++ b/contrib/remote-helpers/test-hg.sh
 @@ -109,10 +109,10 @@ test_expect_success 'update bookmark' '
(
git clone hg::$PWD/hgrepo gitrepo 
cd gitrepo 
 -  git checkout devel 
 +  git checkout --quiet devel 
echo devel  content 
git commit -a -m devel 
 -  git push
 +  git push --quiet
) 
  
hg -R hgrepo bookmarks | egrep devel[  ]+3:
 -- 
 1.8.3.rc1.579.g184e698



-- 
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 v3 10/10] remote-hg: trivial reorganization

[Felipe Contreras]

Another no-brainer; simply shuffling some code.

Felipe Contreras wrote:
 We only need to get the remote dict once.
 
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index dc276af..96bed8d 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -860,6 +860,7 @@ def do_export(parser):
  
  if peer:
  parser.repo.push(peer, force=force_push, newbranch=True)
 +remote_bmarks = peer.listkeys('bookmarks')
  
  # handle bookmarks
  for bmark, node in p_bmarks:
 @@ -886,8 +887,7 @@ def do_export(parser):
  continue
  
  if peer:
 -rb = peer.listkeys('bookmarks')
 -old = rb.get(bmark, '')
 +old = remote_bmarks.get(bmark, '')
  if not peer.pushkey('bookmarks', bmark, old, new):
  print error %s % ref
  continue
 -- 
 1.8.3.rc1.579.g184e698

-- 
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---

 What happens with and without this patch to an existing user from
 1.8.2 days, when she does what?

 I already explained it would prevent the new shared repository
 organization from working, so the old organization would be used; the
 repositories won't be shared.

 A sample answer (to show the level of descriptiveness, not the
 content, I am epecting) might go something like Because the
 organization is different, it will barf whenever she tries to
 incrementally update from the other side. By removing the old one
 1.8.3 contrib/ does not understand, at least we can unstuck her; she
 ends up reimporting the whole history, though.

 Bazaar won't barf, the repositories will be duplicated, so the shared
 feature won't work.

But by removing the old incarnation, you are getting rid of the copy
for which the shared feature will not work, so with patch, won't
work is no longer an issue.  Is the user making a trade-off by
using Git with this patch?  What is she losing by removal, if
anything?
--
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---

 What happens with and without this patch to an existing user from
 1.8.2 days, when she does what?

 I already explained it would prevent the new shared repository
 organization from working, so the old organization would be used; the
 repositories won't be shared.

 A sample answer (to show the level of descriptiveness, not the
 content, I am epecting) might go something like Because the
 organization is different, it will barf whenever she tries to
 incrementally update from the other side. By removing the old one
 1.8.3 contrib/ does not understand, at least we can unstuck her; she
 ends up reimporting the whole history, though.

 Bazaar won't barf, the repositories will be duplicated, so the shared
 feature won't work.

 But by removing the old incarnation, you are getting rid of the copy
 for which the shared feature will not work, so with patch, won't
 work is no longer an issue.  Is the user making a trade-off by
 using Git with this patch?  What is she losing by removal, if
 anything?

No. The way repositories work in bazaar is tricky:

Suppose you have a directory like this:

+* first/second/foo
+* first/second/bar

Both the branch and the repository are on the same directory (hence
+*). We have two branches, and two independent repositories.

And then you have a shared repo:

+ first/
* first/second/foo
* first/second/bar

Now we have a single repository shared between two branches.

But:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar

If there's another repository in-between, neither 'foo' nor 'bar' can
reach 'first', so they are stuck with the repository in 'second',
which is not a shared repository, so they must create their own
repositories, but even if they could use 'second', there still would
be a problem:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar
+* first/third
+* first/third/foo
+* first/third/bar

We want 'second' and 'third' to share to object tree, but we can't.

This patch would remove the old repository ('second' and 'third') so
we have exactly what we want:

+ first/
* first/second/foo
* first/second/bar
* first/third/foo
* first/third/bar

A single bzr repository shared by all the branches and all the repos.

In reality it probably wouldn't be a big deal, because in v1.8.2 users
couldn't clone true bzr repos, but there are some bazaar repos with a
single branch they could clone, and there would be a single duplicated
repo, like this:

+ first/
+* first/second/foo
+* first/third/foo

-- 
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---

 What happens with and without this patch to an existing user from
 1.8.2 days, when she does what?

 I already explained it would prevent the new shared repository
 organization from working, so the old organization would be used; the
 repositories won't be shared.

 A sample answer (to show the level of descriptiveness, not the
 content, I am epecting) might go something like Because the
 organization is different, it will barf whenever she tries to
 incrementally update from the other side. By removing the old one
 1.8.3 contrib/ does not understand, at least we can unstuck her; she
 ends up reimporting the whole history, though.

 Bazaar won't barf, the repositories will be duplicated, so the shared
 feature won't work.

 But by removing the old incarnation, you are getting rid of the copy
 for which the shared feature will not work, so with patch, won't
 work is no longer an issue.  Is the user making a trade-off by
 using Git with this patch?  What is she losing by removal, if
 anything?

 No. The way repositories work in bazaar is tricky:

 Suppose you have a directory like this:

 +* first/second/foo
 +* first/second/bar

 Both the branch and the repository are on the same directory (hence
 +*). We have two branches, and two independent repositories.

 And then you have a shared repo:

 + first/
 * first/second/foo
 * first/second/bar

 Now we have a single repository shared between two branches.

 But:

 + first/
 +* first/second
 +* first/second/foo
 +* first/second/bar

 If there's another repository in-between, neither 'foo' nor 'bar' can
 reach 'first', so they are stuck with the repository in 'second',
 which is not a shared repository, so they must create their own
 repositories, but even if they could use 'second', there still would
 be a problem:

 + first/
 +* first/second
 +* first/second/foo
 +* first/second/bar
 +* first/third
 +* first/third/foo
 +* first/third/bar

 We want 'second' and 'third' to share to object tree, but we can't.

 This patch would remove the old repository ('second' and 'third') so
 we have exactly what we want:

 + first/
 * first/second/foo
 * first/second/bar
 * first/third/foo
 * first/third/bar

 A single bzr repository shared by all the branches and all the repos.

 In reality it probably wouldn't be a big deal, because in v1.8.2 users
 couldn't clone true bzr repos, but there are some bazaar repos with a
 single branch they could clone, and there would be a single duplicated
 repo, like this:

 + first/
 +* first/second/foo
 +* first/third/foo

I forgot to mention the main objective of the shared repo feature:

+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
* first/sixth/foo

Since in bazaar branches are repositories, we want to make it possible
for remote-bzr users to create a single remote per branch as easily as
possible (without having to duplicate huge clones).

But as I said, without this patch, they wouldn't be able to use that
feature if they cloned with v1.8.2.

-- 
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 33/47] remote-hg: add test for new bookmark special

[Eric Sunshine]

On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 From the point of view of Mercurial, this creates a new branch head, and
 requires a forced push.

 Ideally, whoever, we would want it to work just like in git; new

Did you mean s/whoever/however/ ?

 branches can be pushed without problems.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.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: [PATCH 16/47] remote-hg: load all extensions

[Eric Sunshine]

On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 The user might have then configured differently, plus, all of them will

Did you mean s/then/them/ ?

 be loaded anyway later on.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.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: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 2:57 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 Junio C Hamano wrote:
 I do not use zsh but with bash+readline the old tradition lnext can
 be used (see stty -a output and it typically is set to ^V), i.e.
 \C-v followed by \C-i should give you a literal HT.

 Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
 Still doesn't solve my problem though: I don't type out structs; I
 paste them the X clipboard (Emacs).  And that doesn't work either on
 bash or zsh.

 What can we do to improve the interface?

Don't use tabs in your code?

P
--
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 I forgot to mention the main objective of the shared repo feature:

 + first/
 * first/second/foo
 * first/third/foo
 * first/fourth/foo
 * first/fifth/foo
 * first/sixth/foo

 Since in bazaar branches are repositories, we want to make it possible
 for remote-bzr users to create a single remote per branch as easily as
 possible (without having to duplicate huge clones).

 But as I said, without this patch, they wouldn't be able to use that
 feature if they cloned with v1.8.2.

So we nuke that and have them clone from scratch?  I am not saying
that is bad.  I just want us to be honest about the implications
when including it in the ReleaseNotes.
--
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 I forgot to mention the main objective of the shared repo feature:

 + first/
 * first/second/foo
 * first/third/foo
 * first/fourth/foo
 * first/fifth/foo
 * first/sixth/foo

 Since in bazaar branches are repositories, we want to make it possible
 for remote-bzr users to create a single remote per branch as easily as
 possible (without having to duplicate huge clones).

 But as I said, without this patch, they wouldn't be able to use that
 feature if they cloned with v1.8.2.

 So we nuke that and have them clone from scratch?  I am not saying
 that is bad.  I just want us to be honest about the implications
 when including it in the ReleaseNotes.

The user won't have to do a thing, it happens behind the curtain.

And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
serves is to block the new feature.

-- 
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 v3 09/10] remote-hg: test: be a little more quiet

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 No-brainer; improve one test.

In general, unless we are taking the output from commands to a file
and grepping in it, we prefer not to have --quiet (unless you are
testing the --quiet feature of the command, of course).  Running the
tests without -v option will not show them and when running with
-v to debug the tests, the extra output will help to figure out
which step failed.

 Felipe Contreras wrote:
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/test-hg.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/contrib/remote-helpers/test-hg.sh 
 b/contrib/remote-helpers/test-hg.sh
 index 8de2aa7..f8d1f9e 100755
 --- a/contrib/remote-helpers/test-hg.sh
 +++ b/contrib/remote-helpers/test-hg.sh
 @@ -109,10 +109,10 @@ test_expect_success 'update bookmark' '
(
git clone hg::$PWD/hgrepo gitrepo 
cd gitrepo 
 -  git checkout devel 
 +  git checkout --quiet devel 
echo devel  content 
git commit -a -m devel 
 -  git push
 +  git push --quiet
) 
  
hg -R hgrepo bookmarks | egrep devel[ ]+3:
 -- 
 1.8.3.rc1.579.g184e698
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 09/10] remote-hg: test: be a little more quiet

[Felipe Contreras]

On Tue, May 14, 2013 at 4:40 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 No-brainer; improve one test.

 In general, unless we are taking the output from commands to a file
 and grepping in it, we prefer not to have --quiet (unless you are
 testing the --quiet feature of the command, of course).  Running the
 tests without -v option will not show them and when running with
 -v to debug the tests, the extra output will help to figure out
 which step failed.

Yeah, but I spent a long time looking at the output of these tests and
grew tired of all the irrelevant noise. In fact, I'm even tempted to
set push.default because of that annoying message all over them. Maybe
the --quiet for the push shouldn't be there, but the --quiet for
checkout definitely. Either way, I don't see much value in changing
this patch at this point.

-- 
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 v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 Without this fix, the user would never ever see new bookmarks, only the ones
 that (s)he initially cloned.

Now, think again and realize how long it took you (the original
author) to discover issues and come up with these fixes and
explanation since the series was merged before -rc0.

Are we giving the users enough time to discover and complain issues
that these 10 patches may introduce before the final release?  You
can see these patches are so trivially correct is not a valid
argument. The original patches would also have been looked correct
when they were sent to the list. Things take time and actual use by
the users to mature.

Having said that, the impression I am getting is that whatever we
pushed out in 1.8.2 and 1.8.3-rc0 was far from ready for real use,
and with your explanations (by the way, I found that many of them
deserve to be in the log message), the end result of applying these
patches, up to 8/10, will still not be as it is very likely that you
and users will discover issues at a similar rate, but at least it
will be much closer to be ready than they currently are.

In other words, it still seems to be in something is better than
nothing, newer is better than older stage before stabilization.

And that is to be expected for a contrib/ material; nothing for us
to be ashamed of.  So I changed my mind.  As long as it is clearly
marked as still experimental, possibly with rough edges, I think
it is better to ship 1.8.3 with these 8 patches than without.

I am unhappy with 3/10, though.  It is spreading existing mistake by
adding another configuration variable with dash in its name, which
goes against the recommended practice, and making it more cumbersome
to eventually fix them, because we would need to break end user's
configuration.

Things like 1/10 and 2/10 that can be characterized as:

 This is a trivial cleanup, cannot cause regressions.

may probably be a good clean-up to build the next development cycle
on top, but are not at all urgent for it to deserve to be included
in the upcoming release.  But it seems that 3-8 textually depend on
at least 2, so I'll queue the first eight for 1.8.3 and exclude the
rest for now.  If these are identical to the early part of the
47-patch series (I didn't check; they are for the next cycle), it
would make the next cycle shorter by 8 patches.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.

That is the answer I was trying to extract out of you (I take the hg
is a typo for bzr in the above, though).
--
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

Fwd: git cvsimport implications

[Eugene Sajine]

Hi,

We are using git cvsimport heavily but mostly the projects are not
using branches that much. We are also migrating our repos only once,
so there is  no commits to CVS repo and no incremental imports allowed
after the migration. we have migrated more than a thousand projects
already.

we use the simplest way (from the CVS checkout folder)

$ git cvsimport -C /path/to/new/git/repo

Just recently it was brought to my attention that we can have problems
with that tool. So my question is if anybody could advise which
scenarios are safe to use this tool for, and what is not recommended?

What if there are a lot of branches in the CVS repo? Is it guaranteed
to be broken after import?

Do i understand correctly that it might put some files into a branch,
that were not originally in this branch in CVS? In which cases it
might happen (i'm sorry i didn't quite get the issues in the man
pages for cvsimport)?

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: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

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

 Felipe Contreras felipe.contre...@gmail.com writes:

 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.

 That is the answer I was trying to extract out of you (I take the hg
 is a typo for bzr in the above, though).

Just to double check, I understand that the justification for
removal is this:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
-repository, which is not used any more.
+repository. It is not used by 1.8.3, and did not host any useful
+information in the code in 1.8.2.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Without this fix, the user would never ever see new bookmarks, only the ones
 that (s)he initially cloned.

 Now, think again and realize how long it took you (the original
 author) to discover issues and come up with these fixes and
 explanation since the series was merged before -rc0.

This issue has *always* been there, it's not a regression.

 Are we giving the users enough time to discover and complain issues
 that these 10 patches may introduce before the final release?

Yes, because the time needed is *zero*.

 You
 can see these patches are so trivially correct is not a valid
 argument. The original patches would also have been looked correct
 when they were sent to the list. Things take time and actual use by
 the users to mature.

There was no original patches that introduced this regression, because
it's not a regression.

When I say these are trivially correct, I mean it; the regressions you
talk about were on patches that were marked as *not* trivially
correct, and potentially dangerous.

 Having said that, the impression I am getting is that whatever we
 pushed out in 1.8.2 and 1.8.3-rc0 was far from ready for real use,
 and with your explanations (by the way, I found that many of them
 deserve to be in the log message), the end result of applying these
 patches, up to 8/10, will still not be as it is very likely that you
 and users will discover issues at a similar rate, but at least it
 will be much closer to be ready than they currently are.

Define ready. It's probably more ready than any other bridge tool out there.

 In other words, it still seems to be in something is better than
 nothing, newer is better than older stage before stabilization.

remote-hg is already stable, this patch has nothing to do with
stabilization, neither do any of the 47 patches I sent to the list.

 And that is to be expected for a contrib/ material; nothing for us
 to be ashamed of.  So I changed my mind.  As long as it is clearly
 marked as still experimental, possibly with rough edges, I think
 it is better to ship 1.8.3 with these 8 patches than without.

 I am unhappy with 3/10, though.  It is spreading existing mistake by
 adding another configuration variable with dash in its name, which
 goes against the recommended practice, and making it more cumbersome
 to eventually fix them, because we would need to break end user's
 configuration.

It's not adding any configuration; remote-hg.track-branches is already
present, even in v1.8.2.

 Things like 1/10 and 2/10 that can be characterized as:

 This is a trivial cleanup, cannot cause regressions.

 may probably be a good clean-up to build the next development cycle
 on top, but are not at all urgent for it to deserve to be included
 in the upcoming release.  But it seems that 3-8 textually depend on
 at least 2, so I'll queue the first eight for 1.8.3 and exclude the
 rest for now.  If these are identical to the early part of the
 47-patch series (I didn't check; they are for the next cycle), it
 would make the next cycle shorter by 8 patches.

Indeed, they are exactly the same as the first 10 patches of the
47-patch series.

I think this makes sense.

-- 
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
 Junio C Hamano gits...@pobox.com writes:

 Felipe Contreras felipe.contre...@gmail.com writes:

 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.

 That is the answer I was trying to extract out of you (I take the hg
 is a typo for bzr in the above, though).

 Just to double check, I understand that the justification for
 removal is this:

  If a clone exists with the old organization (v1.8.2) it will prevent the
  new shared repository organization from working, so let's remove this
 -repository, which is not used any more.
 +repository. It is not used by 1.8.3, and did not host any useful
 +information in the code in 1.8.2.

That is not true. It did host useful information in 1.8.2, if we apply
this and the user tries to pull with remote-bzr from 1.8.2, it would
need to be cloned again.

-- 
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 1/4] t5510: start tracking-ref tests from a known state

[Eric Sunshine]

On Sat, May 11, 2013 at 12:14 PM, Jeff King p...@peff.net wrote:
 We have three sequential tests for for whether tracking refs

s/for for/for/
[or]
s/for for/for checking/

 are updated by various fetches and pulls; the first two
 should not update the ref, and the third should. Each test
 depends on the state left by the test before.

 This is fragile (a failing early test will confuse later
 tests), and means we cannot add more should update tests
 after the third one.

 Let's instead save the initial state before these tests, and
 then reset to a known state before running each test.

 Signed-off-by: Jeff King p...@peff.net
--
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: Fwd: git cvsimport implications

[Junio C Hamano]

Eugene Sajine eugu...@gmail.com writes:

 What if there are a lot of branches in the CVS repo? Is it guaranteed
 to be broken after import?

Even though CVS repository can record branches in individual ,v
files, reconstructing per branch history and where the branch
happened in each changeset cannot be determined with any
certainty.  The best you can get is a heuristic result.

I do not think anybody can give such a guarantee.  The best you can
do is to convert it and validate if the result matches what you
think has happened in the CVS history.
--
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
 Junio C Hamano gits...@pobox.com writes:

 Felipe Contreras felipe.contre...@gmail.com writes:

 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.

 That is the answer I was trying to extract out of you (I take the hg
 is a typo for bzr in the above, though).

 Just to double check, I understand that the justification for
 removal is this:

  If a clone exists with the old organization (v1.8.2) it will prevent the
  new shared repository organization from working, so let's remove this
 -repository, which is not used any more.
 +repository. It is not used by 1.8.3, and did not host any useful
 +information in the code in 1.8.2.

 That is not true. It did host useful information in 1.8.2, if we apply
 this and the user tries to pull with remote-bzr from 1.8.2, it would
 need to be cloned again.

So the answer to my original question:

So we nuke that and have them clone from scratch?

is now Yes, unfortunately, but it happens automatically inside
remote-bzr and the users won't have to do anything extra?

That is the kind of honest description I wanted to see.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Without this fix, the user would never ever see new bookmarks, only the 
 ones
 that (s)he initially cloned.

 Now, think again and realize how long it took you (the original
 author) to discover issues and come up with these fixes and
 explanation since the series was merged before -rc0.

 This issue has *always* been there, it's not a regression.

 Then why are you rushing it?  -rc is a regression-fix-only period.

I'm not rushing this patch, I'm rushing the regression fix. I added
the cleanup patches because they help the fix, and I added this patch
because it's obviously good.

 Define ready. It's probably more ready than any other bridge
 tool out there.

 Anything that needs oh, we need to push these ten patches to avoid
 regressions at the last minute is not mature enough to be relied
 upon by end users for everyday use.  That is what I meant.

Only a single patch is needed to fix the regression and I sent that
patch standalone in v2 of this series, but you didn't pick it, so I
sent the cleanups as well.

 But now you are saying these are not regression fixes, in which case
 they have to wait because the users have known about the limitations
 that existed for a long time and learned to live with them.  That is
 a sign of mature (not not ready) software.

No, they don't have to wait. And we don't have to mindlessly apply
guidelines as dogma.

The reason for the only regression period is to avoid more
regressions. If you show me how any of the fixes I sent in this series
could potentially cause a regression, I would agree with you, even if
remote, the possibility would be there, therefore the patch wouldn't
be material for 1.8.3.

But the fact of the matter is that the possibility is not there, we
are not decreasing the possibility of regressions, we are simply
removing a feature users could enjoy for no gain at all.

 You cannot be both.  Which is it?

I marked the patch that fix a regression as such, I marked the patches
that are obvious fixes with no possibility of regressions as such, and
I marked the trivial cleanups with no possibility of regressions as
such.

-- 
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: [msysGit] Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Philip Oakley]

sorry about the MUA mangling - reply at end.
- Original Message - 
From: Torsten Bögershausen tbo...@web.de

To: Ramsay Jones ram...@ramsay1.demon.co.uk
Cc: Torsten Bögershausen tbo...@web.de; Junio C Hamano
gits...@pobox.com; git@vger.kernel.org; mleved...@gmail.com;
Jonathan Nieder jrnie...@gmail.com; j...@kdbg.org; msysGit
msys...@googlegroups.com
Sent: Tuesday, May 14, 2013 8:37 PM
Subject: [msysGit] Re: Problems with Windows, Was: What's cooking in
git.git (May 2013, #01; Fri, 3)


On 2013-05-09 19.18, Ramsay Jones wrote:

Torsten Bögershausen wrote:

On 2013-05-04 01.14, Junio C Hamano wrote:


 Cygwin portability; both were reviewed by Jonathan, and the tip one
 seems to want a bit further explanation.  Needs positive report
 from Cygwin 1.7 users who have been on 1.7 to make sure it does not
 regress for them.


I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.

Running the test suite under cygwin doesn't seem to work any more
(?):

Scenario 1:
The PC is running alone, and goes into the screen saver.
Pressing CTRL-ALT-DEL didn't get any effect.

Scenario 2:
The PC didn't react any more, when the test suite was run in
background.
In 3 or 4 cases the PC needed to be reboot hardly.

Using the commits before and after this change makes the test suite
hang
as well at some point, then it hangs somewhere at TC 3000--4000.

Scenario 4:
The I disabled the screensaver, upgdated cygwin,
 and went back to an older commit:
The latest run from commit 52d63e70, April 28,
hangs in TC 5500, ok 26 clone shallow object count.

I can see 2 times
git.exe pull --depth 4 ..A

Scenario 5:
The run of today 1.8.3-rc1, hangs in t5510,
some git.exe are running fetch. (or pull)


It seems as if some process/exes are not terminated
in the way it should be.

I will try on a different machine,
comments are wellcome


Hmm, I'm a little puzzled, but not shocked. ;-)

Somebody, I forget who, had already tested Jonathan's patch
on cygwin 1.7 successfully and my follow up patch should be
a no-op on cygwin 1.7; so I'm puzzled! (The high risk should
have been on cygwin 1.5).

I'm not shocked because running the test-suite on cygwin has
been a bit of a magical mystery tour for quite some time.

In about 2007, I could not run the test-suite for about six
to nine months; it would randomly wedge my laptop solid - I had
to pull the power-cord out in order to re-boot. (I suspect that
commit 9cb18f56fde may have cured that particular problem, but
don't quote me on that - I didn't investigate at the time.)

I have noticed that running the tests with 'prove' is more likely
to prove successful, so my config.mak looks like:

$ cat config.mak
NO_SVN_TESTS=1
GIT_TEST_OPTS=--no-color
NO_GETTEXT=1
DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS='--timer'
$

I currently run the tests like so:

$ time $(GIT_SKIP_TESTS='t0061.3 t0070.3 t4130 t9010 t9300' make
test \
test-outp13 21)

real172m25.311s
user132m15.133s
sys 66m43.122s
$

The t0061.3 and t0070.3 failures don't require much discussion. The
t4130
failure is an intermittent racy git issue that has been on my TODO
list
for several years. t9300 also fails intermittently. However, t9010
fails
every time for me, hanging the test suite (although ^C interrupts it
just
fine).

I have a fix for t9010 that looks like:

diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
index b7eed24..4d01e3b 100755
--- a/t/t9010-svn-fe.sh
+++ b/t/t9010-svn-fe.sh
@@ -22,10 +22,9 @@ try_dump () {
maybe_fail_fi=${3:+test_$3} 

{
-   $maybe_fail_svnfe test-svn-fe $input stream
3backflow 
-   } 
-   $maybe_fail_fi git fast-import --cat-blob-fd=3 stream
3backflow 
-   wait $!
+   $maybe_fail_svnfe test-svn-fe $input 3backflow
+   } |
+   $maybe_fail_fi git fast-import --cat-blob-fd=3 3backflow
 }

 properties () {

but I have not tested this patch enough to be happy to submit it (I
have
some suspicions that it would still fail intermittently, just like
t9300).

Also, commit 7bc0911d (test-lib: Fix say_color () not to interpret
\a\b\c
in the message, 11-10-2012) caused several random test failures.
(don't ask
me why). So, before each test run, I have to apply the following:

diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..ed32b7f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -230,7 +230,7 @@ else
say_color() {
test -z $1  test -n $quiet  return
shift
-   printf %s\n $*
+   echo -E $*
}
 fi

which effectively reverts that commit.

So, as I said, a magical mystery tour. :-D

ATB,
Ramsay Jones



First of all,
the patch we are talking about does not any regrssions at my side.

Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

Turning 

Re: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
 Junio C Hamano gits...@pobox.com writes:

 Felipe Contreras felipe.contre...@gmail.com writes:

 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.

 That is the answer I was trying to extract out of you (I take the hg
 is a typo for bzr in the above, though).

 Just to double check, I understand that the justification for
 removal is this:

  If a clone exists with the old organization (v1.8.2) it will prevent 
 the
  new shared repository organization from working, so let's remove this
 -repository, which is not used any more.
 +repository. It is not used by 1.8.3, and did not host any useful
 +information in the code in 1.8.2.

 That is not true. It did host useful information in 1.8.2, if we apply
 this and the user tries to pull with remote-bzr from 1.8.2, it would
 need to be cloned again.

 So the answer to my original question:

 So we nuke that and have them clone from scratch?

No, as I already explained the cloning from scratch is already
happening with or without this patch.

All this change does is remove a repository that is not used any more
in order to allow a feature that was already introduced, and that's
exactly what the commit message says. It doesn't cause any other
change.

-- 
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 v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 The reason for the only regression period is to avoid more
 regressions. If you show me how any of the fixes I sent in this series
 could potentially cause a regression,

I already said that You can see these patches are so trivially
correct is not a valid argument. The original patches would also
have been looked correct when they were sent to the list. Things
take time and actual use by the users to mature.

 You cannot be both.  Which is it?

 I marked the patch that fix a regression as such, I marked the patches
 that are obvious fixes with no possibility of regressions as such, and
 I marked the trivial cleanups with no possibility of regressions as
 such.

I think you mean 6/10 by the patch that fix a regression, but if
that is the case, please send only the regression fix that cleanly
apply to the tip of 'master', without any other dependencies, with a
proper description of what breaks and how it fixes.

We know you can do better than certain and might.

 In certain situations we might end up pushing garbage revisions (e.g. in
 a rebase), and the patches to deal with that haven't been merged yet.
 
 So let's disable forced pushes by default.

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 v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 5:49 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 The reason for the only regression period is to avoid more
 regressions. If you show me how any of the fixes I sent in this series
 could potentially cause a regression,

 I already said that You can see these patches are so trivially
 correct is not a valid argument.

You can say so, it doesn't make it so.

 The original patches would also
 have been looked correct when they were sent to the list.

No, they didn't look correct, and I made it clear when I sent the
patches to be *tested*.

 Things
 take time and actual use by the users to mature.

Some things, not all things. That's a hasty generalization fallacy.

 You cannot be both.  Which is it?

 I marked the patch that fix a regression as such, I marked the patches
 that are obvious fixes with no possibility of regressions as such, and
 I marked the trivial cleanups with no possibility of regressions as
 such.

 I think you mean 6/10 by the patch that fix a regression, but if
 that is the case, please send only the regression fix that cleanly
 apply to the tip of 'master', without any other dependencies, with a
 proper description of what breaks and how it fixes.

I did that for v2, but you didn't merge that.

 We know you can do better than certain and might.

 In certain situations we might end up pushing garbage revisions (e.g. in
 a rebase), and the patches to deal with that haven't been merged yet.

 So let's disable forced pushes by default.

I have done more than enough. I'm not going to write tests for this,
and I'm not going to find out for sure. There is a *potential* that
there's a regression, and that's reason enough to apply this patch as
it is.

I have done way more than my fair share already. I'm 98% certain that
this patch series as it is would not introduce a regression for
v1.8.3, and that's good enough for me. If anybody has any problem with
that, they can pick this series and do whatever they want with them.

If I'm supposed to be the owner of contrib/remote-helpers, it
certainly doesn't feel that way. If I am the owner, but you are
worried, why don't you let me make the decision, and if something
blows in v1.8.3, you can tell me; see? you are not ready to have the
full maintainership of this. After all, this is in the contrib area,
so if there's a time for a possible future maintainer of a core part
of git to make mistakes, it would be now. But of course, this would
*not* happen, because the patches are obviously correct and I stand by
that claim.

As things currently stand, v1.8.3 *might* introduce a regression.

-- 
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: [RFC/PATCH] branch: show me the hot branches

[Phil Hord]

On Mon, May 13, 2013 at 4:02 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 Uses commit-date to sort displayed refs.

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---

I dig it.

I imagine it with --date-order and whatnot.  But I might like it even
better if it were reverse-sorted.  Maybe it needs -rt for that. ;-)

Phil
--
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 v9 0/9] interactive git-clean

[Junio C Hamano]

Except for one nit in 1/9, the series seems to be nicely done.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 ... After all, this is in the contrib area,
 so if there's a time for a possible future maintainer of a core part
 of git to make mistakes, it would be now.

That sounds reasonable.

Incidentally, before I had to stop working in order to respond to
your endless arguments, I already queued the 8 patches to 'master'
(also remote-bzr one is in below that).

I had no time checking other topics in flight nor merging the result
up to 'next' and 'pu' yet, and it will take a while for the result
to be published, but we'll see these in 1.8.3.
--
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: [RFC/PATCH] branch: show me the hot branches

[Junio C Hamano]

Phil Hord phil.h...@gmail.com writes:

 I imagine it with --date-order and whatnot.

Perhaps modeled after this one.

git for-each-ref \
--format='%(refname:short) %(subject)'
--sort='-committerdate' refs/heads/

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 6:32 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 ... After all, this is in the contrib area,
 so if there's a time for a possible future maintainer of a core part
 of git to make mistakes, it would be now.

 That sounds reasonable.

 Incidentally, before I had to stop working in order to respond to
 your endless arguments, I already queued the 8 patches to 'master'
 (also remote-bzr one is in below that).

Cool. But FTR, the endless arguments come from both sides.

 I had no time checking other topics in flight nor merging the result
 up to 'next' and 'pu' yet, and it will take a while for the result
 to be published, but we'll see these in 1.8.3.

Well, the priority is 1.8.3.

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: [RFC/PATCH] branch: show me the hot branches

[Duy Nguyen]

On Tue, May 14, 2013 at 3:02 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 Uses commit-date to sort displayed refs.

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Just had this idea and wrote it down in five minutes.  The
  implementation is only meant to be indicative.

  Isn't this awesome?

I tried a more generic approach a while ago.

http://thread.gmane.org/gmane.comp.version-control.git/188705
--
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

Re: [PATCH v9 1/9] git-clean: refactor git-clean into two phases

[Jiang Xin]

2013/5/15 Junio C Hamano gits...@pobox.com:
 @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
 *prefix)
   continue; /* Yup, this one exists unmerged */
   }

 - /*
 -  * we might have removed this as part of earlier
 -  * recursive directory removal, so lstat() here could
 -  * fail with ENOENT.
 -  */
   if (lstat(ent-name, st))
   continue;

 I am guessing that the reason why you removed the comment is because
 during this phase there is no way we might have removed.  But if
 that is the case, does it still make sense to run lstat() and ignore
 errors from the call?


Run lstat() here is necessary, because we need to check whether
ent-name points to a file or a directory. If ent points to a directory,
only add to del_list when user provides '-x' option to git-clean.

if (S_ISDIR(st.st_mode)) {
if (remove_directories || (matches ==
MATCHED_EXACTLY)) {
rel = path_relative(ent-name, prefix);
string_list_append(del_list, rel);
}
} ...


When start to do cleaning, there is a duplicate lstat() call, and the removed
comments above are moved here.

/*
 * we might have removed this as part of earlier
 * recursive directory removal, so lstat() here could
 * fail with ENOENT.
 */
if (lstat(abs_path.buf, st))
continue;

if (S_ISDIR(st.st_mode)) {
if (remove_dirs(abs_path, prefix, rm_flags,
dry_run, quiet, gone))
errors++;
if (gone  !quiet) {
qname =
quote_path_relative(item-string, -1, buf, NULL);
printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
}
}

But I am not clear how earlier recursive directory removal could
make lstat() failure here. If it is not the case, maybe we can test a
directory by ent-name (ends with '/' or '\\' ?).

-- 
Jiang Xin
--
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 resend 0/2] git-svn: improve documentation of multiple fetch lines

[Eric Wong]

Jonathan Nieder jrnie...@gmail.com wrote:
 I last sent these patches as an RFC a year and a half or so ago[1].
 Nathan seemed to like them and they still seem valid, so thought
 I'd resubmit. :)

Thanks, both applied.  Sorry for forgetting :x
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-svn: introduce --parents parameter for commands branch and tag

[Eric Wong]

Tobias Schulte tobias.schu...@gliderpilot.de wrote:
 This parameter is equivalent to the parameter --parents on svn cp commands
 and is useful for non-standard repository layouts.

This looks useful.  A few minor cosmetic issues.

 +++ b/Documentation/git-svn.txt
 @@ -298,6 +298,11 @@ where name is the name of the SVN repository as 
 specified by the -R option to
   git config --get-all svn-remote.name.commiturl
  +
  
 +--parents;;
 + Create parent folders. This parameter is equivalent to the parameter 
 + --parents on svn cp commands and is useful for non-standard repository 
 + layouts.

Trailing whitespace.

 +sub mk_parent_dirs {
 + my $ctx = shift;
 + my $parent = shift;

I prefer declaring multiple variables from arguments as:

my ($ctx, $parent) = @_;

 + $parent =~ s/\/[^\/]*$//;

You can avoid leaning toothpick syndrome (escaping '/') by specifying
alternate delimiters:

$parent =~ s{/[^/]*$}{};

ref: perlop(1)

 + if (!eval{$ctx-ls($parent, 'HEAD', 0)}) {
 + mk_parent_dirs($ctx, $parent);
 + print Creating parent folder ${parent} ...\n;
 + $ctx-mkdir($parent)
 + unless $_dry_run;

The newline is confusing, I prefer:

$ctx-mkdir($parent) unless $_dry_run;

Howeve :

if (!$_dry_run) {
$ctx-mkdir($parent);
}

May be preferred, too (especially for the non-Perl-fluent)

 +++ b/t/t9167-git-svn-cmd-branch-subproject.sh

 +test_expect_success 'initialize svnrepo' '
 +mkdir import 
 +(
 +(cd import 
 +mkdir -p trunk/project branches tags 
 +(cd trunk/project 
 +echo foo  foo
 +) 

Tabs for all indentation, and indent consistently for subshells:

mkdir import 
(
cd import 
mkdir .. 
(
cd .. 
..
)
)

We use subshells + cd like this so it's easier to read/maintain.

Thanks again, looking forward to applying v2.
--
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: Segmentation fault with latest git (070c57df)

[sam]

Hi,

Has there been any further progress on this. I just encountered a SEGV with
a git apply. This is the latest git version running on Ubuntu 13.04

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION=Ubuntu 13.04

uname -a
Linux sam-mac 3.8.0-20-generic #31-Ubuntu SMP Mon May 6 17:03:32 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

git --version
git version 1.8.2.2


samueldoyle@sam-MacBookPro:~/Projects/VMware/perforce_repos/esx50u3ps$ sudo
gdb /usr/bin/git core
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/git...(no debugging symbols found)...done.
[New LWP 28634]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.

warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x7fff94d1a000
Core was generated by `git apply --verbose --check --ignore-whitespace
--directory=/home/sam/P'.
Program terminated with signal 11, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31  ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt 10
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1  0x7f06ba7c28c6 in __GI___strdup (s=0x0) at strdup.c:41
#2  0x004f4449 in ?? ()
#3  0x0040eab0 in ?? ()
#4  0x0040f6f5 in ?? ()
#5  0x00405a88 in ?? ()
#6  0x00404ee2 in ?? ()
#7  0x7f06ba75aea5 in __libc_start_main (main=0x404e30, argc=7,
ubp_av=0x7fff94c3bd08, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x7fff94c3bcf8) at libc-start.c:260
#8  0x00405329 in ?? ()


A quick search turned up this post that appears to provide the cause:
http://stackoverflow.com/questions/3608931/why-is-this-program-segfaulting



--
View this message in context: 
http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585906.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

Re: Segmentation fault with latest git (070c57df)

[sam]

Hmmm nabble embed didn't provide much value there :)

http://pastebin.com/RC8mUPF3



--
View this message in context: 
http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585907.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

git grep --no-index doesn't do what it says on the tin?

[Nazri Ramliy]

Hi,

From git help grep:

  --no-index
   Search files in the current directory that is not managed by Git.

   --untracked
   In addition to searching in the tracked files in the working tree,
   search also in untracked files.

From the description above I would think that git grep --no-index
and git grep --untracked would behave differently, but it seems like
their behavior is the same:

$ cd ~/src/git
$ echo superman  git.c
$ echo superman  foo.txt
$ git grep --no-index superman
foo.txt:1:superman
git.c:588:superman
$ git grep --untracked superman
foo.txt:1:superman
git.c:588:superman

I would expect the following behavior for git grep --no-index:

$ git grep --no-index superman
foo.txt:1:superman
$

That is, it won't search inside files that are managed by git.

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