Git development
 help / color / mirror / Atom feed
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Junio C Hamano @ 2013-01-06 23:13 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Nguyễn Thái Ngọc Duy, git, Jens Lehmann,
	Heiko Voigt, Manlio Perillo, W. Trevor King
In-Reply-To: <20130106101948.GD10956@elie.Belkin>

Jonathan Nieder <jrnieder@gmail.com> writes:

> Nguyễn Thái Ngọc Duy wrote:
>
>> --separate-git-dir was added to clone with the repository away from
>> standard position <worktree>/.git. It does not make sense to use it
>> without creating working directory.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> The patch correctly implements the above.  The description leaves out
> detail.  I'd say something like
>
> 	The --separate-git-dir option was introduced to make it simple
> 	to put the git directory somewhere outside the worktree, for
> 	example when cloning a repository for use as a submodule.
>
> 	It was not intended for use when creating a bare repository.
> 	In that case there is no worktree and it is more natural to
> 	directly clone the repository and create a .git file as
> 	separate steps:
>
> 		git clone --bare /path/to/repo.git bar.git
> 		printf 'gitdir: bar.git\n' >foo.git
>
> 	Unfortunately we forgot to forbid the --bare
> 	--separate-git-dir combination.  In practice, we know no one
> 	could be using --bare with --separate-git-dir because it is
> 	broken in the following way: <explanation here>.  So it is
> 	safe to make good on our mistake and forbid the combination,
> 	making the command easier to explain.
>
> I don't know what would go in the <explanation here> blank above,
> though.  Is it possible that some people are relying on this option
> combination?

I do not necessarily think we must say "it happens not to work
already for such and such reasons, lucky us!", but it is indeed a
good idea to think things through, justifying why this cannot be a
regression, and record the fact that we did that thinking, in the
log message.

Thanks.

^ permalink raw reply

* Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
From: Adam Spiers @ 2013-01-06 23:17 UTC (permalink / raw)
  To: git list
In-Reply-To: <20130106225311.GB6552@pacific.linksys.moosehall>

On Sun, Jan 06, 2013 at 10:53:11PM +0000, Adam Spiers wrote:
> That's a valid point.  However, the ary[0] part which assumes external
> knowledge of the internal implementation can trivially be avoided by
> squashing this patch onto the commit we are discussing:

[snipped]

> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index 0ca9d8e..0406adc 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -420,10 +420,11 @@ static int option_parse_z(const struct option *opt,
>  static int option_parse_exclude(const struct option *opt,
>  				const char *arg, int unset)
>  {
> -	struct exclude_list_group *group = opt->value;
> +	struct string_list *exclude_list = opt->value;
>  
>  	exc_given = 1;
> -	add_exclude(arg, "", 0, &group->el[0]);
> +	string_list_append(exclude_list, arg);
> +	fprintf(stderr, "append %s\n", arg);

Whoops :-)

[snipped]

> @@ -524,9 +527,13 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
>  	if (read_cache() < 0)
>  		die("index file corrupt");
>  
> -	add_exclude_list(&dir, EXC_CMDL);
>  	argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
>  			ls_files_usage, 0);
> +	el = add_exclude_list(&dir, EXC_CMDL);
> +	for (i = 0; i < exclude_list.nr; i++) {
> +		fprintf(stderr, "adding exclude: %s\n", exclude_list.items[i].string);

Excluding those two fprintf() calls, of course :-)

I've removed them, and pushed to my github fork a new version of v4
with the fixed version of this patch inserted in the appropriate place
(and labelled with a "[SQUASH]" prefix):

    git://github.com/aspiers/git.git
    https://github.com/aspiers/git/commits/check-ignore

Since I sent v4 earlier today, to avoid spamming this list, I won't
resend the whole series yet - not until we have made some progress in
reviewing v4.

^ permalink raw reply

* Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
From: Junio C Hamano @ 2013-01-06 23:19 UTC (permalink / raw)
  To: Adam Spiers; +Cc: git list
In-Reply-To: <20130106225311.GB6552@pacific.linksys.moosehall>

Adam Spiers <git@adamspiers.org> writes:

> That's a valid point.  However, the ary[0] part which assumes external
> knowledge of the internal implementation can trivially be avoided by
> squashing this patch onto the commit we are discussing:
>
> diff --git a/builtin/clean.c b/builtin/clean.c
> index dd89737..6e21ca6 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -45,6 +45,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>  	static const char **pathspec;
>  	struct strbuf buf = STRBUF_INIT;
>  	struct string_list exclude_list = STRING_LIST_INIT_NODUP;
> +	struct exclude_list *el;
>  	const char *qname;
>  	char *seen = NULL;
>  	struct option options[] = {
> @@ -97,10 +98,9 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>  	if (!ignored)
>  		setup_standard_excludes(&dir);
>  
> -	add_exclude_list(&dir, EXC_CMDL);
> +	el = add_exclude_list(&dir, EXC_CMDL);
>  	for (i = 0; i < exclude_list.nr; i++)
> -		add_exclude(exclude_list.items[i].string, "", 0,
> -			    &dir.exclude_list_group[EXC_CMDL].el[0]);
> +		add_exclude(exclude_list.items[i].string, "", 0, el);
>  
>  	pathspec = get_pathspec(prefix, argv);
>
>
> and by adopting the same approach for ls-files.c:

That is _much_ more readable and easier to explain in the API
documentation, I think.

Thanks.

^ permalink raw reply

* Re: [PATCH] docs: manpage XML depends on asciidoc.conf
From: Junio C Hamano @ 2013-01-06 23:19 UTC (permalink / raw)
  To: John Keeping; +Cc: Jonathan Nieder, git, Sergey Vlasov, Thomas Ackermann
In-Reply-To: <20130106123326.GF6440@serenity.lan>

Thanks.

^ permalink raw reply

* [PATCH v4] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2013-01-06 23:16 UTC (permalink / raw)
  To: git; +Cc: Zoltan Klinger

(1) Only print out the names of the files and directories that got
    actually deleted.
(2) Show warning message for ignored untracked git repositories

Consider the following repo layout:

  test.git/
    |-- tracked_dir/
    |     |-- some_tracked_file
    |     |-- some_untracked_file
    |-- tracked_file
    |-- untracked_file
    |-- untracked_foo/
    |     |-- bar/
    |     |     |-- bar.txt
    |     |-- emptydir/
    |     |-- frotz.git/
    |           |-- frotz.tx
    |-- untracked_some.git/
          |-- some.txt

Suppose the user issues 'git clean -fd' from the test.git directory.

When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.

  $ git clean -fd
  Removing tracked_dir/some_untracked_file
  Removing untracked_file
  Removing untracked_foo/
  Removing untracked_some.git/

The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.

This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.

Improve the way the deleted directories are reported back to
the user:
  (1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
      to run in both dry_run and delete modes with the delete logic as
      follows:
        (a) Check if the current directory to be deleted is an untracked
            git repository. If it is and --force --force option is not set
            do not touch this directory, print ignore message, set dir_gone
            flag to false for the caller and return.
        (b) Otherwise for each item in current directory:
              (i)   If current directory cannot be accessed, print warning,
                    set dir_gone flag to false and return.
              (ii)  If the item is a subdirectory recurse into it,
                    check for the returned value of the dir_gone flag.
                    If the subdirectory is gone, add the name of the deleted
                    directory to a list of successfully removed items 'dels'.
                    Else set the dir_gone flag as the current directory
                    cannot be removed because we have at least one subdirectory
                    hanging around.
              (iii) If it is a file try to remove it. If success add the
                    file name to the 'dels' list, else print error and set
                    dir_gone flag to false.
        (c) After we finished deleting all items in the current directory and
            the dir_gone flag is still true, remove the directory itself.
            If failed set the dir_gone flag to false.

        (d) If the current directory cannot be deleted because the dir_gone flag
            has been set to false, print out all the successfully deleted items
            for this directory from the 'dels' list.
        (e) We're done with the current directory, return.

  (2) Modify the cmd_clean() function to:
        (a) call the recursive delete function 'remove_dirs()' for each
            topmost directory it wants to remove
        (b) check for the returned value of dir_gone flag. If it's true
            print the name of the directory as being removed.

Consider the output of the improved version:

  $ git clean -fd
  Removing tracked_dir/some_untracked_file
  Removing untracked_file
  warning: ignoring untracked git repository untracked_foo/frotz.git
  Removing untracked_foo/bar
  Removing untracked_foo/emptydir
  warning: ignoring untracked git repository untracked_some.git/

Now it displays only the file and directory names that got actually
deleted and shows warnings about ignored untracked git repositories.

Reported-by: Soren Brinkmann <soren.brinkmann@xilinx.com>

Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
---
 builtin/clean.c |  158 +++++++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 129 insertions(+), 29 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..1714546 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -10,6 +10,7 @@
 #include "cache.h"
 #include "dir.h"
 #include "parse-options.h"
+#include "refs.h"
 #include "string-list.h"
 #include "quote.h"
 
@@ -20,6 +21,12 @@ static const char *const builtin_clean_usage[] = {
 	NULL
 };
 
+static const char *msg_remove = N_("Removing %s\n");
+static const char *msg_would_remove = N_("Would remove %s\n");
+static const char *msg_would_ignore_git_dir = N_("Would ignore untracked git repository %s\n");
+static const char *msg_warn_ignore_git_dir = N_("ignoring untracked git repository %s");
+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"))
@@ -34,11 +41,116 @@ static int exclude_cb(const struct option *opt, const char *arg, int unset)
 	return 0;
 }
 
+static int remove_dirs(struct strbuf *path, const char *prefix, int force_flag,
+		int dry_run, int quiet, int *dir_gone)
+{
+	DIR *dir;
+	struct strbuf quoted = STRBUF_INIT;
+	struct dirent *e;
+	int res = 0, ret = 0, gone = 1, original_len = path->len, len, i;
+	unsigned char submodule_head[20];
+	struct string_list dels = STRING_LIST_INIT_DUP;
+
+	*dir_gone = 1;
+
+	if ((force_flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
+	    !resolve_gitlink_ref(path->buf, "HEAD", submodule_head)) {
+		if (dry_run && !quiet) {
+			quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+			printf(_(msg_would_ignore_git_dir), quoted.buf);
+		} else if (!dry_run) {
+			quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+			warning(_(msg_warn_ignore_git_dir), quoted.buf);
+		}
+
+		*dir_gone = 0;
+		return 0;
+	}
+
+	dir = opendir(path->buf);
+	if (!dir) {
+		/* an empty dir could be removed even if it is unreadble */
+		res = dry_run ? 0 : rmdir(path->buf);
+		if (res) {
+			quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+			warning(_(msg_warn_remove_failed), quoted.buf);
+			*dir_gone = 0;
+		}
+		return res;
+	}
+
+	if (path->buf[original_len - 1] != '/')
+		strbuf_addch(path, '/');
+
+	len = path->len;
+	while ((e = readdir(dir)) != NULL) {
+		struct stat st;
+		if (is_dot_or_dotdot(e->d_name))
+			continue;
+
+		strbuf_setlen(path, len);
+		strbuf_addstr(path, e->d_name);
+		if (lstat(path->buf, &st))
+			; /* fall thru */
+		else if (S_ISDIR(st.st_mode)) {
+			if (remove_dirs(path, prefix, force_flag, dry_run, quiet, &gone))
+				ret = 1;
+			if (gone) {
+				quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+				string_list_append(&dels, quoted.buf);
+			}
+			else
+				*dir_gone = 0;
+			continue;
+		} else {
+			res = dry_run ? 0 : unlink(path->buf);
+			if (!res) {
+				quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+				string_list_append(&dels, quoted.buf);
+			}
+			else {
+				quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+				warning(_(msg_warn_remove_failed), quoted.buf);
+				*dir_gone = 0;
+				ret = 1;
+			}
+			continue;
+		}
+
+		/* path too long, stat fails, or non-directory still exists */
+		*dir_gone = 0;
+		ret = 1;
+		break;
+	}
+	closedir(dir);
+
+	strbuf_setlen(path, original_len);
+
+	if (*dir_gone) {
+		res = dry_run ? 0 : rmdir(path->buf);
+		if (!res)
+			*dir_gone = 1;
+		else {
+			quote_path_relative(path->buf, strlen(path->buf), &quoted, prefix);
+			warning(_(msg_warn_remove_failed), quoted.buf);
+			*dir_gone = 0;
+			ret = 1;
+		}
+	}
+
+	if (!*dir_gone && !quiet) {
+		for (i = 0; i < dels.nr; i++)
+			printf(dry_run ?  _(msg_would_remove) : _(msg_remove), dels.items[i].string);
+	}
+	string_list_clear(&dels, 0);
+	return ret;
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
-	int i;
-	int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
-	int ignored_only = 0, config_set = 0, errors = 0;
+	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 dir_struct dir;
@@ -49,7 +161,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 	char *seen = NULL;
 	struct option options[] = {
 		OPT__QUIET(&quiet, N_("do not print names of files removed")),
-		OPT__DRY_RUN(&show_only, N_("dry run")),
+		OPT__DRY_RUN(&dry_run, N_("dry run")),
 		OPT__FORCE(&force, N_("force")),
 		OPT_BOOLEAN('d', NULL, &remove_directories,
 				N_("remove whole directories")),
@@ -77,7 +189,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 	if (ignored && ignored_only)
 		die(_("-x and -X cannot be used together"));
 
-	if (!show_only && !force) {
+	if (!dry_run && !force) {
 		if (config_set)
 			die(_("clean.requireForce set to true and neither -n nor -f given; "
 				  "refusing to clean"));
@@ -149,38 +261,26 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 
 		if (S_ISDIR(st.st_mode)) {
 			strbuf_addstr(&directory, ent->name);
-			qname = quote_path_relative(directory.buf, directory.len, &buf, prefix);
-			if (show_only && (remove_directories ||
-			    (matches == MATCHED_EXACTLY))) {
-				printf(_("Would remove %s\n"), qname);
-			} else if (remove_directories ||
-				   (matches == MATCHED_EXACTLY)) {
-				if (!quiet)
-					printf(_("Removing %s\n"), qname);
-				if (remove_dir_recursively(&directory,
-							   rm_flags) != 0) {
-					warning(_("failed to remove %s"), qname);
+			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);
 				}
-			} else if (show_only) {
-				printf(_("Would not remove %s\n"), qname);
-			} else {
-				printf(_("Not removing %s\n"), qname);
 			}
 			strbuf_reset(&directory);
 		} else {
 			if (pathspec && !matches)
 				continue;
-			qname = quote_path_relative(ent->name, -1, &buf, prefix);
-			if (show_only) {
-				printf(_("Would remove %s\n"), qname);
-				continue;
-			} else if (!quiet) {
-				printf(_("Removing %s\n"), qname);
-			}
-			if (unlink(ent->name) != 0) {
-				warning(_("failed to remove %s"), qname);
+			res = dry_run ? 0 : unlink(ent->name);
+			if (res) {
+				qname = quote_path_relative(ent->name, -1, &buf, prefix);
+				warning(_(msg_warn_remove_failed), qname);
 				errors++;
+			} else if (!quiet) {
+				qname = quote_path_relative(ent->name, -1, &buf, prefix);
+				printf(dry_run ? _(msg_would_remove) : _(msg_remove), qname);
 			}
 		}
 	}
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH v4] git-clean: Display more accurate delete messages
From: Jonathan Nieder @ 2013-01-06 23:40 UTC (permalink / raw)
  To: Zoltan Klinger; +Cc: git, Soren Brinkmann, Jens Lehmann, Peter Collingbourne
In-Reply-To: <1357514219-16102-1-git-send-email-zoltan.klinger@gmail.com>

Zoltan Klinger wrote:

>   $ git clean -fd
>   Removing tracked_dir/some_untracked_file
>   Removing untracked_file
>   Removing untracked_foo/
>   Removing untracked_some.git/
>
> The message displayed to the user is slightly misleading. The foo/
> directory has not been removed because of foo/frotz.git still exists.
> On the other hand the subdirectories 'bar' and 'emptydir' have been
> deleted but they're not mentioned anywhere. Also, untracked_some.git
> has not been removed either.
[...]
> Consider the output of the improved version:
>
>   $ git clean -fd
>   Removing tracked_dir/some_untracked_file
>   Removing untracked_file
>   warning: ignoring untracked git repository untracked_foo/frotz.git
>   Removing untracked_foo/bar
>   Removing untracked_foo/emptydir
>   warning: ignoring untracked git repository untracked_some.git/

Thanks, this looks like a nice improvement.

I wonder whether it's possible to make the output more consistent,
as in:

	Removing tracked_dir/some_untracked_file
	Removing untracked_file
	Skipping repository untracked_foo/frotz.git
	Removing untracked_foo/bar
	Removing untracked_foo/emptydir
	Skipping repository untracked_some.git

or similar.  What do you think?

Thanks,
Jonathan

^ permalink raw reply

* Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-07  0:36 UTC (permalink / raw)
  To: Git

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Today I had to move my first submodule, and I discovered that Git's
support for this is pretty limited.  There have been a few patch
series attempting to address this [1,2], but none of them seems to
have pushed through into master (although I can't put my finger on a
reason for why).  There are also some SO postings discussing this
[3,4].  It would be nice if `git mv` worked out of the box on
submodules.  Failing that, there could be a `git submodule mv` command
that casts the appropriate spell.  Failing that, there could be a
recipe in Documentation/git-submodule.txt.  Here's the best I could
come up with for a `git-submodule-mv.sh`:

  #!/bin/sh
  # usage: git-submodule-mv.sh OLD NEW
  OLD=$(realpath --relative-to . "$1")
  NEW=$(realpath --relative-to . "$2")
  SHA=$(git ls-files -s "$OLD" | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|')
  NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' "$OLD" |
    sed -e 's|^submodule.||' -e "s|.path $OLD\$||")
  GITDIR=$(realpath --relative-to "$NEW" .git/modules/"$NAME")
  git config -f .gitmodules submodule."$NAME".path "$NEW"
  git config -f .git/modules/"$NAME"/config core.worktree "../../../$NEW"
  git rm --cached "$OLD"
  mv "$OLD" "$NEW"
  echo "gitdir: $GITDIR" > "$NEW/.git"
  git update-index --add --cacheinfo 160000 "$SHA" "$NEW"

This only works from the repository root directory, and I'm sure makes
a number of poor assumptions (e.g. old-style submodules that don't use
`gitdir` links are not supported).  It does work for some simple test
cases.  The tricky parts (e.g. path -> name conversion) are already
worked out more robustly git-submodule.sh, so adding a new cmd_mv
shouldn't be very difficult.

Could something like this live somewhere in Git, or are we waiting for
a more integrated solution?

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.comp.version-control.git/88720
[2]: http://thread.gmane.org/gmane.comp.version-control.git/143250
[4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git
[3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 03/21] pathspec: make sure the prefix part is wildcard-clean
From: Duy Nguyen @ 2013-01-07  1:10 UTC (permalink / raw)
  To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1357453268-12543-4-git-send-email-pclouds@gmail.com>

On Sun, Jan 6, 2013 at 1:20 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> --- a/setup.c
> +++ b/setup.c
> @@ -250,6 +250,8 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
>         *raw = item->match;
>         item->len = strlen(item->match);
>         item->nowildcard_len = simple_length(item->match);
> +       if (item->nowildcard_len < prefixlen)
> +               item->nowildcard_len = prefixlen;
>         return magic;
>  }

This is wrong (so much for the last-minute patch). Prefix length
depends on actual pathspec (e.g. abc, ../abc and ../../abc use
different prefix length). This patch should be discarded (it does not
have any real impacts anyway).
-- 
Duy

^ permalink raw reply

* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Duy Nguyen @ 2013-01-07  1:18 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Jonathan Nieder, git, Jens Lehmann, Heiko Voigt, Manlio Perillo,
	W. Trevor King
In-Reply-To: <7v6239nbw0.fsf@alter.siamese.dyndns.org>

On Mon, Jan 7, 2013 at 6:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I don't know what would go in the <explanation here> blank above,
>> though.  Is it possible that some people are relying on this option
>> combination?
>
> I do not necessarily think we must say "it happens not to work
> already for such and such reasons, lucky us!", but it is indeed a
> good idea to think things through, justifying why this cannot be a
> regression, and record the fact that we did that thinking, in the
> log message.
>
> Thanks.

I wanted to give a day or two or think about the <explanation here>.
Does "Thanks." mean you have picked up the patch and adjusted the
commit message appropriately, or should I go with my original plan and
resend it later with "explanantion there"?
-- 
Duy

^ permalink raw reply

* Re: Moving (renaming) submodules, recipe/script
From: Jonathan Nieder @ 2013-01-07  1:39 UTC (permalink / raw)
  To: W. Trevor King; +Cc: Git, Jens Lehmann, Peter Collingbourne
In-Reply-To: <20130107003603.GA25698@odin.tremily.us>

(just cc-ing Jens and Peter, who might be interested)

W. Trevor King wrote:

> Today I had to move my first submodule, and I discovered that Git's
> support for this is pretty limited.  There have been a few patch
> series attempting to address this [1,2], but none of them seems to
> have pushed through into master (although I can't put my finger on a
> reason for why).  There are also some SO postings discussing this
> [3,4].  It would be nice if `git mv` worked out of the box on
> submodules.  Failing that, there could be a `git submodule mv` command
> that casts the appropriate spell.  Failing that, there could be a
> recipe in Documentation/git-submodule.txt.  Here's the best I could
> come up with for a `git-submodule-mv.sh`:
>
>   #!/bin/sh
>   # usage: git-submodule-mv.sh OLD NEW
>   OLD=$(realpath --relative-to . "$1")
>   NEW=$(realpath --relative-to . "$2")
>   SHA=$(git ls-files -s "$OLD" | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|')
>   NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' "$OLD" |
>     sed -e 's|^submodule.||' -e "s|.path $OLD\$||")
>   GITDIR=$(realpath --relative-to "$NEW" .git/modules/"$NAME")
>   git config -f .gitmodules submodule."$NAME".path "$NEW"
>   git config -f .git/modules/"$NAME"/config core.worktree "../../../$NEW"
>   git rm --cached "$OLD"
>   mv "$OLD" "$NEW"
>   echo "gitdir: $GITDIR" > "$NEW/.git"
>   git update-index --add --cacheinfo 160000 "$SHA" "$NEW"
>
> This only works from the repository root directory, and I'm sure makes
> a number of poor assumptions (e.g. old-style submodules that don't use
> `gitdir` links are not supported).  It does work for some simple test
> cases.  The tricky parts (e.g. path -> name conversion) are already
> worked out more robustly git-submodule.sh, so adding a new cmd_mv
> shouldn't be very difficult.
>
> Could something like this live somewhere in Git, or are we waiting for
> a more integrated solution?
>
> Cheers,
> Trevor
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720
> [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250
> [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git
> [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository

^ permalink raw reply

* Re: Suggested improvements to the git-p4 documentation (branch-related)
From: Olivier Delalleau @ 2013-01-07  2:00 UTC (permalink / raw)
  To: Pete Wyckoff; +Cc: git
In-Reply-To: <20130105212517.GA30315@padd.com>

2013/1/5 Pete Wyckoff <pw@padd.com>:
> shish@keba.be wrote on Thu, 03 Jan 2013 15:58 -0500:
>> While struggling to get git-p4 to work properly with branches, I
>> thought the documentation on http://git-scm.com/docs/git-p4 could use
>> some improvements:
>
> Thanks, I definitely appreciate the constructive comments here.
>
>> 1. At the end of the "Branch detection" section, the following
>> commands are provided (for when you want to explicitly provide branch
>> mappings to git-p4):
>>
>> git config git-p4.branchList main:branch1
>> git p4 clone --detect-branches //depot@all
>>
>> The second command should end with a dot (".") because the first
>> command only works if you are already in a git-initialized folder.
>> Thus I would also suggest to add "git init" as first command to type.
>
> That is confusing.  I'll make it this:
>
>     git init depot
>     cd depot
>     git config git-p4.branchList main:branch1
>     git p4 clone --detect-branches //depot@all .

Sounds good, thanks.

>
>> 2. Even though having a "main" branch is standard in Perforce, it
>> would be worth mentioning what happens when you don't: there is a
>> message "Could not detect main branch. No checkout/master branch
>> created" output by the "git p4 clone" command. However, it will still
>> work if you manually set the master branch ("git checkout -b master
>> remotes/p4/my_custom_main_branch").
>
> This feels like a bug to me, and indeed I had an old patch series
> that planned to fix it.  Let me knock that into shape, instead of
> changing the documentation.  It will automatically do the
> checkout step you did.

Sounds good as well.

>
>> 3. I don't know what I missed for that one, but I haven't been able to
>> get the example for the --branch option to work. It says that after
>> "git init", we can import a p4 branch with:
>>
>> git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
>>
>> However, after doing this, followed by "git checkout -b proj2
>> remotes/p4/proj2", I am unable to properly use "git p4 sync" or "git
>> p4 submit" from this branch, as git complains about a missing
>> refs/remotes/p4/master.
>
> Yes, also annoying.  I have a failing test case for this, but
> haven't fixed it yet.  The idea is that "git p4 sync --branch=proj2"
> will sync refs/remotes/p4/proj2.  If there is no p4/master, and
> you don't specify --branch, it will fail with a more useful error
> message.

Good too!

> For submit, there is code that walks from your current branch
> back in history until it finds a commit on a known p4 remote
> branch.  This is sort of like the merge-base calculation in git,
> but restricted to a linear history.  I haven't tested that
> recently, but will add a test and fix it if needed too.
>
>
> Please do feel welcome to to rearrange or expand the
> documentation so it makes more sense, if you are so inspired.

I'm afraid I'm not familiar enough with git documentation to dig into
it myself, but anyway that's about what I had for now. I'll send more
comments to the mailing list if I have more suggestions in the future.

Thanks for a great tool! :)

-=- Olivier

^ permalink raw reply

* [PATCH] git-send-email: treat field names as case-independent
From: Nickolai Zeldovich @ 2013-01-07  1:34 UTC (permalink / raw)
  To: gitster; +Cc: Nickolai Zeldovich, git

Field names like To:, Cc:, etc should be treated as case-independent;
use a case-insensitive regexp to match them as such.  Previously,
git-send-email would send email messages with a lowercase "cc:" line in
the body without actually sending a copy of the message to that address.

Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
---
 git-send-email.perl |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 94c7f76..be809e5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1285,10 +1285,10 @@ foreach my $t (@files) {
 		}
 
 		if (defined $input_format && $input_format eq 'mbox') {
-			if (/^Subject:\s+(.*)$/) {
+			if (/^Subject:\s+(.*)$/i) {
 				$subject = $1;
 			}
-			elsif (/^From:\s+(.*)$/) {
+			elsif (/^From:\s+(.*)$/i) {
 				($author, $author_encoding) = unquote_rfc2047($1);
 				next if $suppress_cc{'author'};
 				next if $suppress_cc{'self'} and $author eq $sender;
@@ -1296,14 +1296,14 @@ foreach my $t (@files) {
 					$1, $_) unless $quiet;
 				push @cc, $1;
 			}
-			elsif (/^To:\s+(.*)$/) {
+			elsif (/^To:\s+(.*)$/i) {
 				foreach my $addr (parse_address_line($1)) {
 					printf("(mbox) Adding to: %s from line '%s'\n",
 						$addr, $_) unless $quiet;
 					push @to, $addr;
 				}
 			}
-			elsif (/^Cc:\s+(.*)$/) {
+			elsif (/^Cc:\s+(.*)$/i) {
 				foreach my $addr (parse_address_line($1)) {
 					if (unquote_rfc2047($addr) eq $sender) {
 						next if ($suppress_cc{'self'});
@@ -1325,7 +1325,7 @@ foreach my $t (@files) {
 			elsif (/^Message-Id: (.*)/i) {
 				$message_id = $1;
 			}
-			elsif (!/^Date:\s/ && /^[-A-Za-z]+:\s+\S/) {
+			elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) {
 				push @xh, $_;
 			}
 
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Junio C Hamano @ 2013-01-07  2:04 UTC (permalink / raw)
  To: Duy Nguyen
  Cc: Jonathan Nieder, git, Jens Lehmann, Heiko Voigt, Manlio Perillo,
	W. Trevor King
In-Reply-To: <CACsJy8A6soMEJ3FXY8MyeERAGN483M2UjqRS4muzzD6uj1QWow@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> On Mon, Jan 7, 2013 at 6:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> I don't know what would go in the <explanation here> blank above,
>>> though.  Is it possible that some people are relying on this option
>>> combination?
>>
>> I do not necessarily think we must say "it happens not to work
>> already for such and such reasons, lucky us!", but it is indeed a
>> good idea to think things through, justifying why this cannot be a
>> regression, and record the fact that we did that thinking, in the
>> log message.
>>
>> Thanks.
>
> I wanted to give a day or two or think about the <explanation here>.
> Does "Thanks." mean you have picked up the patch and adjusted the
> commit message appropriately, or should I go with my original plan and
> resend it later with "explanantion there"?

The latter, "Thanks for a review".  I may have picked it up in 'pu',
but that merely means, as usual, that I wanted to add a reminder in
What's cooking to expect a reroll, and nothing more.

Thanks.

^ permalink raw reply

* git push --force to update tag
From: 乙酸鋰 @ 2013-01-07  2:23 UTC (permalink / raw)
  To: git

about git 1.8.2

 * "git push" now requires "-f" to update a tag, even if it is a
   fast-forward, as tags are meant to be fixed points.

Does the server side validate this? Do we need to upgrade git on
server side to support this?

^ permalink raw reply

* What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07  2:42 UTC (permalink / raw)
  To: git

What's cooking in git.git (Jan 2013, #03; Sun, 6)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The tip of 'next' will be rewound and rebuilt shortly, kicking a
couple of topics back to 'pu' and reordering the remainder as
needed.

As usual, this cycle is expected to last for 8 to 10 weeks.  To
ensure the quality of the end result, let's merge topics in flight
earlier than previous cycles to 'next' and fix issues in-tree.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* cr/push-force-tag-update (2012-12-03) 10 commits
  (merged to 'next' on 2012-12-04 at af2e3a9)
 + push: allow already-exists advice to be disabled
 + push: rename config variable for more general use
 + push: cleanup push rules comment
 + push: clarify rejection of update to non-commit-ish
 + push: require force for annotated tags
 + push: require force for refs under refs/tags/
 + push: flag updates that require force
 + push: keep track of "update" state separately
 + push: add advice for rejected tag reference
 + push: return reject reasons as a bitset

 Require "-f" for push to update a tag, even if it is a fast-forward.


* fc/fast-export-fixes (2012-12-03) 15 commits
  (merged to 'next' on 2012-12-03 at f9df523)
 + fast-export: make sure updated refs get updated
 + fast-export: don't handle uninteresting refs
 + fast-export: fix comparison in tests
 + fast-export: trivial cleanup
 + remote-testgit: implement the "done" feature manually
 + remote-testgit: report success after an import
 + remote-testgit: exercise more features
 + remote-testgit: cleanup tests
 + remote-testgit: remove irrelevant test
 + remote-testgit: remove non-local functionality
 + Add new simplified git-remote-testgit
 + Rename git-remote-testgit to git-remote-testpy
 + remote-helpers: fix failure message
 + remote-testgit: fix direction of marks
 + fast-export: avoid importing blob marks

 Various updates to fast-export used in the context of the remote
 helper interface.


* ja/directory-attrs (2012-12-17) 1 commit
  (merged to 'next' on 2012-12-17 at ced8e73)
 + Add directory pattern matching to attributes

 The attribute mechanism didn't allow limiting attributes to be
 applied to only a single directory itself with "path/" like the
 exclude mechanism does.


* jc/fetch-ignore-symref (2012-12-11) 1 commit
  (merged to 'next' on 2012-12-17 at 370e2c8)
 + fetch: ignore wildcarded refspecs that update local symbolic refs

 Avoid false error from an attempt to update local symbolic ref via
 fetch.


* jc/format-color-auto (2012-12-17) 2 commits
  (merged to 'next' on 2012-12-18 at 5aaac94)
 + log --format: teach %C(auto,black) to respect color config
 + t6006: clean up whitespace

 Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
 not color its output when writing to a non-terminal.


* jk/complete-commit-c (2012-12-15) 1 commit
  (merged to 'next' on 2012-12-18 at 75b5f21)
 + completion: complete refs for "git commit -c"

 Complete "git commmit -c foo<TAB>" into a refname that begins with
 "foo".


* jk/error-const-return (2012-12-15) 2 commits
  (merged to 'next' on 2012-12-22 at bf2b1cd)
 + silence some -Wuninitialized false positives
 + make error()'s constant return value more visible

 Help compilers' flow analysis by making it more explicit that
 error() always returns -1, to reduce false "variable used
 uninitialized" warnings.  Looks somewhat ugly but not too much.


* jk/fsck-dot-in-trees (2012-11-28) 2 commits
  (merged to 'next' on 2012-11-28 at 519dabc)
 + fsck: warn about ".git" in trees
 + fsck: warn about '.' and '..' in trees


* jk/mailmap-from-blob (2012-12-13) 5 commits
  (merged to 'next' on 2012-12-17 at 14b7cdc)
 + mailmap: default mailmap.blob in bare repositories
 + mailmap: fix some documentation loose-ends for mailmap.blob
 + mailmap: clean up read_mailmap error handling
 + mailmap: support reading mailmap from blobs
 + mailmap: refactor mailmap parsing for non-file sources

 Allow us to read, and default to read, mailmap files from the tip
 of the history in bare repositories.  This will help running tools
 like shortlog in server settings.


* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
  (merged to 'next' on 2012-12-03 at d677090)
 + wrap_in_html(): process message in bulk rather than line-by-line
 + wrap_in_html(): use strbuf_addstr_xml_quoted()
 + imap-send: change msg_data from storing (ptr, len) to storing strbuf
 + imap-send: correctly report errors reading from stdin
 + imap-send: store all_msgs as a strbuf
 + lf_to_crlf(): NUL-terminate msg_data::data
 + xml_entities(): use function strbuf_addstr_xml_quoted()
 + Add new function strbuf_add_xml_quoted()

 Update imap-send to reuse xml quoting code from http-push codepath,
 clean up some code, and fix a small bug.


* nd/pathspec-wildcard (2012-11-26) 4 commits
  (merged to 'next' on 2012-12-03 at eca0fcb)
 + tree_entry_interesting: do basedir compare on wildcard patterns when possible
 + pathspec: apply "*.c" optimization from exclude
 + pathspec: do exact comparison on the leading non-wildcard part
 + pathspec: save the non-wildcard length part

 Optimize matching paths with common forms of pathspecs that contain
 wildcard characters.


* wk/submodule-update-remote (2012-12-19) 3 commits
  (merged to 'next' on 2012-12-22 at 7ddf897)
 + submodule add: If --branch is given, record it in .gitmodules
 + submodule update: add --remote for submodule's upstream changes
 + submodule: add get_submodule_config helper funtion

 The beginning of 'integrate with the tip of the remote branch, not
 the commit recorded in the superproject gitlink' support.

--------------------------------------------------
[New Topics]

* jk/pathspec-literal (2013-01-06) 1 commit
 - t6130-pathspec-noglob: Windows does not allow a file named "f*"

 Will merge to 'next' and 'master' as a quick "oops" fix.


* as/dir-c-cleanup (2012-12-28) 10 commits
 - dir.c: rename free_excludes() to clear_exclude_list()
 - dir.c: refactor is_path_excluded()
 - dir.c: refactor is_excluded()
 - dir.c: refactor is_excluded_from_list()
 - dir.c: rename excluded() to is_excluded()
 - dir.c: rename excluded_from_list() to is_excluded_from_list()
 - dir.c: rename path_excluded() to is_path_excluded()
 - dir.c: rename cryptic 'which' variable to more consistent name
 - Improve documentation and comments regarding directory traversal API
 - api-directory-listing.txt: update to match code
 (this branch is used by as/check-ignore.)

 Separated an earlier and more solidly done bits from the other
 topic.

 Will merge to 'next'.


* jk/config-uname (2013-01-03) 1 commit
 - Makefile: hoist uname autodetection to config.mak.uname

 Move the bits to set fallback default based on the platform from
 the main Makefile to a separate file, so that it can be included in
 Makefiles in subdirectories.

 Will merge to 'next'.


* jc/push-2.0-default-to-simple (2013-01-04) 10 commits
 - push: switch default from "matching" to "simple"
 - t9401: do not assume the "matching" push is the default
 - t9400: do not assume the "matching" push is the default
 - t7406: do not assume the "matching" push is the default
 - t5531: do not assume the "matching" push is the default
 - t5519: do not assume the "matching" push is the default
 - t5517: do not assume the "matching" push is the default
 - t5516: do not assume the "matching" push is the default
 - t5505: do not assume the "matching" push is the default
 - t5404: do not assume the "matching" push is the default

 Will merge to 'next' and cook there until Git 2.0.


* jk/maint-fast-import-doc-dedup-done (2013-01-05) 1 commit
 - git-fast-import(1): remove duplicate "--done" option

 Will merge to 'next' and 'master' as a quick "oops" fix.

 The "logical order" reorganization can come after that is done and
 can cook longer in 'next'.


* jk/unify-exit-code-by-receiving-signal (2013-01-06) 1 commit
 - run-command: encode signal death as a positive integer

 The internal logic had to deal with two representations of a death
 of a child process by a signal.

 Will merge to 'next'.


* jl/interrupt-clone-remove-separate-git-dir (2013-01-05) 1 commit
 - clone: support atomic operation with --separate-git-dir

 When "git clone --separate-git-dir" is interrupted, we failed to
 remove the real location we created the repository.

 Will merge to 'next'.


* rs/leave-base-name-in-name-field-of-tar (2013-01-05) 1 commit
 - archive-tar: split long paths more carefully

 Improve compatibility with implementations of "tar" that do not
 like empty name field in header (with the additional prefix field
 holding everything).

 Will merge to 'next'.


* as/api-allocation-doc (2013-01-06) 1 commit
 - api-allocation-growing.txt: encourage better variable naming

 Will merge to 'next'.


* jc/comment-cygwin-win32api-in-makefile (2013-01-06) 1 commit
 - Makefile: add comment on CYGWIN_V15_WIN32API

 Will merge to 'next'.


* jn/xml-depends-on-asciidoc-conf (2013-01-06) 1 commit
 - docs: manpage XML depends on asciidoc.conf

 Will merge to 'next'.


* nd/clone-no-separate-git-dir-with-bare (2013-01-06) 1 commit
 - clone: forbid --bare --separate-git-dir <dir>

 Expecting a reroll.
 $gmane/212863


* nd/parse-pathspec (2013-01-06) 21 commits
 - Convert more init_pathspec() to parse_pathspec()
 - Convert add_files_to_cache to take struct pathspec
 - Convert {read,fill}_directory to take struct pathspec
 - Convert refresh_index to take struct pathspec
 - Convert report_path_error to take struct pathspec
 - checkout: convert read_tree_some to take struct pathspec
 - Convert unmerge_cache to take struct pathspec
 - Convert read_cache_preload() to take struct pathspec
 - add: convert to use parse_pathspec
 - archive: convert to use parse_pathspec
 - ls-files: convert to use parse_pathspec
 - rm: convert to use parse_pathspec
 - checkout: convert to use parse_pathspec
 - rerere: convert to use parse_pathspec
 - status: convert to use parse_pathspec
 - commit: convert to use parse_pathspec
 - clean: convert to use parse_pathspec
 - Export parse_pathspec() and convert some get_pathspec() calls
 - pathspec: make sure the prefix part is wildcard-clean
 - Add parse_pathspec() that converts cmdline args to struct pathspec
 - pathspec: save the non-wildcard length part

 Uses the parsed pathspec structure in more places where we used to
 use the raw "array of strings" pathspec.

 Unfortunately, this conflicts a couple of topics in flight. I tried
 to be careful while resolving conflicts, though.


* rs/zip-tests (2013-01-06) 4 commits
 - t5003: check if unzip supports symlinks
 - t5000, t5003: move ZIP tests into their own script
 - t0024, t5000: use test_lazy_prereq for UNZIP
 - t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead

 Updates zip tests to skip some that cannot be handled on platform
 unzip.

 I've renamed the t5002 in the original to t5003 to avoid name
 clashes with another topic in flight.

 Will merge to 'next'.


* rs/zip-with-uncompressed-size-in-the-header (2013-01-06) 1 commit
 - archive-zip: write uncompressed size into header even with streaming

 Improve compatibility of our zip output to fill uncompressed size
 in the header, which we can do without seeking back (even though it
 should not be necessary).

 Will merge to 'next'.

--------------------------------------------------
[Stalled]

* jl/submodule-deinit (2012-12-04) 1 commit
  (merged to 'next' on 2012-12-07 at ea772f0)
 + submodule: add 'deinit' command

 There was no Porcelain way to say "I no longer am interested in
 this submodule", once you express your interest in a submodule with
 "submodule init".  "submodule deinit" is the way to do so.

 But this does not yet do so (does not remove the checkout of the
 submodule).  The design discussion petered out.

 http://thread.gmane.org/gmane.comp.version-control.git/210867/focus=211456

 Will kick back to 'pu'.


* jk/lua-hackery (2012-10-07) 6 commits
 - pretty: fix up one-off format_commit_message calls
 - Minimum compilation fixup
 - Makefile: make "lua" a bit more configurable
 - add a "lua" pretty format
 - add basic lua infrastructure
 - pretty: make some commit-parsing helpers more public

 Interesting exercise. When we do this for real, we probably would want
 to wrap a commit to make it more like an "object" with methods like
 "parents", etc.


* rc/maint-complete-git-p4 (2012-09-24) 1 commit
  (merged to 'next' on 2012-10-29 at af52cef)
 + Teach git-completion about git p4

 Comment from Pete will need to be addressed ($gmane/206172).

 Will kick back to 'pu'.


* jc/maint-name-rev (2012-09-17) 7 commits
 - describe --contains: use "name-rev --algorithm=weight"
 - name-rev --algorithm=weight: tests and documentation
 - name-rev --algorithm=weight: cache the computed weight in notes
 - name-rev --algorithm=weight: trivial optimization
 - name-rev: --algorithm option
 - name_rev: clarify the logic to assign a new tip-name to a commit
 - name-rev: lose unnecessary typedef

 "git name-rev" names the given revision based on a ref that can be
 reached in the smallest number of steps from the rev, but that is
 not useful when the caller wants to know which tag is the oldest one
 that contains the rev.  This teaches a new mode to the command that
 uses the oldest ref among those which contain the rev.

 I am not sure if this is worth it; for one thing, even with the help
 from notes-cache, it seems to make the "describe --contains" even
 slower. Also the command will be unusably slow for a user who does
 not have a write access (hence unable to create or update the
 notes-cache).

 Stalled mostly due to lack of responses.


* jc/xprm-generation (2012-09-14) 1 commit
 - test-generation: compute generation numbers and clock skews

 A toy to analyze how bad the clock skews are in histories of real
 world projects.

 Stalled mostly due to lack of responses.


* jc/blame-no-follow (2012-09-21) 2 commits
 - blame: pay attention to --no-follow
 - diff: accept --no-follow option

 Teaches "--no-follow" option to "git blame" to disable its
 whole-file rename detection.

 Stalled mostly due to lack of responses.


* jc/add-delete-default (2012-08-13) 1 commit
 - git add: notice removal of tracked paths by default

 "git add dir/" updated modified files and added new files, but does
 not notice removed files, which may be "Huh?" to some users.  They
 can of course use "git add -A dir/", but why should they?

 Resurrected from graveyard, as I thought it was a worthwhile thing
 to do in the longer term.

 Waiting for comments.


* mb/remote-default-nn-origin (2012-07-11) 6 commits
 - Teach get_default_remote to respect remote.default.
 - Test that plain "git fetch" uses remote.default when on a detached HEAD.
 - Teach clone to set remote.default.
 - Teach "git remote" about remote.default.
 - Teach remote.c about the remote.default configuration setting.
 - Rename remote.c's default_remote_name static variables.

 When the user does not specify what remote to interact with, we
 often attempt to use 'origin'.  This can now be customized via a
 configuration variable.

 Expecting a reroll.
 $gmane/210151

 "The first remote becomes the default" bit is better done as a
 separate step.

--------------------------------------------------
[Cooking]

* jn/less-reconfigure (2013-01-02) 1 commit
  (merged to 'next' on 2013-01-02 at e5cd6cf)
 + build: do not automatically reconfigure unless configure.ac changed

 When autoconf is used, any build on a different commit always ran
 "config.status --recheck" even when unnecessary.

 Will merge to 'master'.


* ap/merge-stop-at-prepare-commit-msg-failure (2013-01-03) 1 commit
  (merged to 'next' on 2013-01-04 at 251e88b)
 + merge: Honor prepare-commit-msg return code

 "git merge" started calling prepare-commit-msg hook like "git
 commit" does some time ago, but forgot to pay attention to the exit
 status of the hook.  t7505 may want a general clean-up but that is
 a different topic.

 Will merge to 'master'.


* tb/test-shell-lint (2013-01-02) 1 commit
  (merged to 'next' on 2013-01-04 at 0289566)
 + test: Add check-non-portable-shell.pl

 Check for common mistakes in the test scripts, based on simple
 pattern-matching.


* jk/enable-test-lint-by-default (2013-01-03) 1 commit
  (merged to 'next' on 2013-01-04 at 65b21ad)
 + tests: turn on test-lint by default

 We had two simple and quick tests to catch common mistakes when
 writing test scripts, but they weren't run by default when running
 tests.

 Will merge to 'master'.


* jc/doc-maintainer (2013-01-03) 2 commits
 - howto/maintain: mark titles for asciidoc
 - Documentation: update "howto maintain git"

 Describe tools for automation that were invented since this
 document was originally written.


* fc/remote-testgit-feature-done (2012-10-29) 1 commit
 - remote-testgit: properly check for errors

 In the longer term, tightening rules is a good thing to do, and
 because nobody who has worked in the remote helper area seems to be
 interested in reviewing this, I would assume they do not think
 such a retroactive tightening will affect their remote helpers.  So
 let's advance this topic to see what happens.


* fc/remote-bzr (2013-01-02) 9 commits
  (merged to 'next' on 2013-01-04 at 7791dcb)
 + remote-bzr: detect local repositories
 + remote-bzr: add support for older versions of bzr
 + remote-bzr: add support to push special modes
 + remote-bzr: add support for fecthing special modes
 + remote-bzr: add simple tests
 + remote-bzr: update working tree upon pushing
 + remote-bzr: add support for remote repositories
 + remote-bzr: add support for pushing
 + Add new remote-bzr transport helper

 New remote helper for bzr, with minimum fix squashed in.

 Will merge to 'master'.


* mo/cvs-server-updates (2012-12-09) 18 commits
 - t9402: Use TABs for indentation
 - t9402: Rename check.cvsCount and check.list
 - t9402: Simplify git ls-tree
 - t9402: Add missing &&; Code style
 - t9402: No space after IO-redirection
 - t9402: Dont use test_must_fail cvs
 - t9402: improve check_end_tree() and check_end_full_tree()
 - t9402: sed -i is not portable
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic

 As nobody seems to be stepping up to review this, I am tempted to
 merge this to 'next and see who screams.

 Will merge to 'next'.


* jc/submittingpatches (2013-01-02) 4 commits
  (merged to 'next' on 2013-01-04 at 060ffb0)
 + SubmittingPatches: give list and maintainer addresses
 + SubmittingPatches: remove overlong checklist
 + SubmittingPatches: mention subsystems with dedicated repositories
 + SubmittingPatches: who am I and who cares?

 Streamline the document and update with a few e-mail addresses the
 patches should be sent to.

 Will merge to 'master'.


* kb/maint-bundle-doc (2013-01-01) 2 commits
  (merged to 'next' on 2013-01-04 at 73486d9)
 + Documentation: full-ness of a bundle is significant for cloning
 + Documentation: correct example restore from bundle

 Will merge to 'master'.


* nd/maint-branch-desc-doc (2013-01-03) 5 commits
  (merged to 'next' on 2013-01-04 at d05a47f)
 + format-patch: pick up branch description when no ref is specified
 + format-patch: pick up correct branch name from symbolic ref
 + t4014: a few more tests on cover letter using branch description
 + branch: delete branch description if it's empty
 + config.txt: a few lines about branch.<name>.description

 Teach various forms of "format-patch" command line to identify what
 branch the patches are taken from, so that the branch description
 is picked up in more cases.

 Will merge to 'master'.


* tb/test-t9020-no-which (2013-01-01) 1 commit
  (merged to 'next' on 2013-01-04 at 0bcf646)
 + t9020: which is not portable

 Will merge to 'master'.


* tb/test-t9810-no-sed-i (2013-01-01) 1 commit
  (merged to 'next' on 2013-01-04 at 0da03e6)
 + t9810: Do not use sed -i

 Will merge to 'master'.


* aw/rebase-am-failure-detection (2012-10-11) 1 commit
  (merged to 'next' on 2013-01-02 at b9db3a2)
 + rebase: Handle cases where format-patch fails

 Save output from format-patch command in a temporary file, just in
 case it aborts, to give a better failure-case behaviour.


* ap/status-ignored-in-ignored-directory (2013-01-06) 3 commits
 - status: always report ignored tracked directories
  (merged to 'next' on 2013-01-04 at 114fb2f)
 + git-status: Test --ignored behavior
 + dir.c: Make git-status --ignored more consistent

 Output from "git status --ignored" showed an unexpected interaction
 with "--untracked".


* ta/remove-stale-translated-tut (2012-12-27) 1 commit
  (merged to 'next' on 2013-01-02 at e70df8e)
 + Remove Documentation/pt_BR/gittutorial.txt

 Remove a translation of a document that was left stale.

 Will merge to 'master'.


* er/stop-recommending-parsecvs (2012-12-28) 1 commit
  (merged to 'next' on 2013-01-02 at fd816dd)
 + Remove the suggestion to use parsecvs, which is currently broken.

 Stop recommending a defunct third-party software.

 Will merge to 'master'.


* as/test-name-alias-uniquely (2012-12-28) 1 commit
  (merged to 'next' on 2013-01-02 at e297810)
 + Use longer alias names in subdirectory tests

 A few short-and-bland aliases used in the tests were interfering
 with git-custom command in user's $PATH.

 Will merge to 'master'.


* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
  (merged to 'next' on 2013-01-02 at 8795e87)
 + merge --no-edit: do not credit people involved in the side branch

 Stop spending cycles to compute information to be placed on
 commented lines in "merge --no-edit".

 Will merge to 'master'.


* as/check-ignore (2013-01-06) 11 commits
 - add git-check-ignore sub-command
 - setup.c: document get_pathspec()
 - add.c: extract new die_if_path_beyond_symlink() for reuse
 - add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
 - pathspec.c: rename newly public functions for clarity
 - add.c: move pathspec matchers into new pathspec.c for reuse
 - add.c: remove unused argument from validate_pathspec()
 - dir.c: improve docs for match_pathspec() and match_pathspec_depth()
 - dir.c: provide clear_directory() for reclaiming dir_struct memory
 - dir.c: keep track of where patterns came from
 - dir.c: use a single struct exclude_list per source of excludes
 (this branch uses as/dir-c-cleanup.)

 Rerolled.


* jc/format-patch-reroll (2013-01-03) 9 commits
  (merged to 'next' on 2013-01-04 at 6840dbd)
 + format-patch: give --reroll-count a short synonym -v
 + format-patch: document and test --reroll-count
 + format-patch: add --reroll-count=$N option
 + get_patch_filename(): split into two functions
 + get_patch_filename(): drop "just-numbers" hack
 + get_patch_filename(): simplify function signature
 + builtin/log.c: stop using global patch_suffix
 + builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
 + builtin/log.c: drop unused "numbered" parameter from make_cover_letter()

 Teach "format-patch" to prefix v4- to its output files for the
 fourth iteration of a patch series, to make it easier for the
 submitter to keep separate copies for iterations.

 Will merge to 'master'.


* mz/pick-unborn (2012-12-23) 2 commits
  (merged to 'next' on 2013-01-02 at 22b9951)
 + learn to pick/revert into unborn branch
 + tests: move test_cmp_rev to test-lib-functions

 Allows "git cherry-pick $commit" when you do not have any history
 behind HEAD yet.


* nd/retire-fnmatch (2013-01-01) 7 commits
  (merged to 'next' on 2013-01-04 at 4dc3ff1)
 + Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
 + wildmatch: advance faster in <asterisk> + <literal> patterns
 + wildmatch: make a special case for "*/" with FNM_PATHNAME
 + test-wildmatch: add "perf" command to compare wildmatch and fnmatch
 + wildmatch: support "no FNM_PATHNAME" mode
 + wildmatch: make dowild() take arbitrary flags
 + wildmatch: rename constants and update prototype
 (this branch uses nd/wildmatch.)

 Replace our use of fnmatch(3) with a more feature-rich wildmatch.
 A handful patches at the bottom have been moved to nd/wildmatch to
 graduate as part of that branch, before this series solidifies.


* os/gitweb-highlight-uncaptured (2013-01-01) 1 commit
  (merged to 'next' on 2013-01-04 at d565cdd)
 + gitweb: fix error in sanitize when highlight is enabled

 The code to sanitize control characters before passing it to
 "highlight" filter lost known-to-be-safe control characters by
 mistake.

 Will merge to 'master'.


* jc/merge-blobs (2012-12-26) 5 commits
 - merge-tree: fix d/f conflicts
 - merge-tree: add comments to clarify what these functions are doing
 - merge-tree: lose unused "resolve_directories"
 - merge-tree: lose unused "flags" from merge_list
 - Which merge_file() function do you mean?

 Update the disused merge-tree proof-of-concept code.

 Will merge to 'next'.


* er/python-version-requirements (2012-12-28) 1 commit
  (merged to 'next' on 2013-01-02 at 1023a3f)
 + Add checks to Python scripts for version dependencies.

 Some python scripts we ship cannot be run with old versions of the
 interpreter.

 Will merge to 'master'.


* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
 - Highlight the link target line in Gitweb using CSS

 Expecting a reroll.
 $gmane/211935


* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
  (merged to 'next' on 2012-12-22 at 87bd30e)
 + oneway_merge(): only lstat() when told to update worktree

 Optimize "read-tree -m <tree-ish>" without "-u".

 Will merge to 'master'.


* cc/no-gitk-build-dependency (2012-12-18) 3 commits
  (merged to 'next' on 2012-12-22 at da7b2cf)
 + Makefile: replace "echo 1>..." with "echo >..."
 + Makefile: detect when PYTHON_PATH changes
 + Makefile: remove tracking of TCLTK_PATH

 Remove leftover bits from an earlier change to move gitk in its own
 subdirectory.  Reimplementing the dependency tracking rules needs
 to be done in gitk history separately.

 Will merge to 'master'.


* zk/clean-report-failure (2013-01-06) 1 commit
 - git-clean: Display more accurate delete messages

 "git clean" states what it is going to remove and then goes on to
 remove it, but sometimes it only discovers things that cannot be
 removed after recursing into a directory, which makes the output
 confusing and even wrong.

 Rerolled.


* mp/complete-paths (2012-12-21) 1 commit
 - git-completion.bash: add support for path completion

 The completion script used to let the default completer to suggest
 pathnames, which gave too many irrelevant choices (e.g. "git add"
 would not want to add an unmodified path).  Teach it to use a more
 git-aware logic to enumerate only relevant ones.

 It has been reported (no surprise) that this does not work inside
 subdirectory. $gmane/212642

 Waiting for area-experts' review.


* ap/log-mailmap (2013-01-06) 10 commits
 - log: add log.mailmap configuration option
 - log: grep author/committer using mailmap
 - test: add test for --use-mailmap option
 - log: add --use-mailmap option
 - pretty: use mailmap to display username and email
 - mailmap: add mailmap structure to rev_info and pp
 - mailmap: simplify map_user() interface
 - mailmap: remove email copy and length limitation
 - Use split_ident_line to parse author and committer
 - list_lookup: create case and length search

 Clean up various codepaths around mailmap and teach the "log"
 machinery to use it.

 Rerolled.


* bc/append-signed-off-by (2013-01-01) 12 commits
 - t4014: do not use echo -n
 - Unify appending signoff in format-patch, commit and sequencer
 - format-patch: update append_signoff prototype
 - format-patch: stricter S-o-b detection
 - t4014: more tests about appending s-o-b lines
 - sequencer.c: teach append_signoff to avoid adding a duplicate newline
 - sequencer.c: teach append_signoff how to detect duplicate s-o-b
 - sequencer.c: always separate "(cherry picked from" from commit body
 - sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
 - t/t3511: add some tests of 'cherry-pick -s' functionality
 - t/test-lib-functions.sh: allow to specify the tag name to test_commit
 - sequencer.c: remove broken support for rfc2822 continuation in footer

 Expecting a reroll.
 $gmane/212507


* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
  (merged to 'next' on 2012-11-28 at 43d51c2)
 + config: exit on error accessing any config file
 + doc: advertise GIT_CONFIG_NOSYSTEM
 + config: treat user and xdg config permission problems as errors
 + config, gitignore: failure to access with ENOTDIR is ok

 Deal with a situation where .config/git is a file and we notice
 .config/git/config is not readable due to ENOTDIR, not ENOENT.

 Will merge to 'master'.


* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
  (merged to 'next' on 2012-11-26 at 3af69e7)
 + apply.c:update_pre_post_images(): the preimage can be truncated

 Fix to update_pre_post_images() that did not take into account the
 possibility that whitespace fix could shrink the preimage and
 change the number of lines in it.

 Will merge to 'master'.


* nd/wildmatch (2013-01-01) 18 commits
  (merged to 'next' on 2013-01-01 at 8c633a5)
 + wildmatch: replace variable 'special' with better named ones
 + compat/fnmatch: respect NO_FNMATCH* even on glibc
 + wildmatch: fix "**" special case
  (merged to 'next' on 2012-12-15 at c734714)
 + t3070: Disable some failing fnmatch tests
  (merged to 'next' on 2012-11-21 at 151288f)
 + test-wildmatch: avoid Windows path mangling
  (merged to 'next' on 2012-10-25 at 510e8df)
 + Support "**" wildcard in .gitignore and .gitattributes
 + wildmatch: make /**/ match zero or more directories
 + wildmatch: adjust "**" behavior
 + wildmatch: fix case-insensitive matching
 + wildmatch: remove static variable force_lower_case
 + wildmatch: make wildmatch's return value compatible with fnmatch
 + t3070: disable unreliable fnmatch tests
 + Integrate wildmatch to git
 + wildmatch: follow Git's coding convention
 + wildmatch: remove unnecessary functions
 + Import wildmatch from rsync
 + ctype: support iscntrl, ispunct, isxdigit and isprint
 + ctype: make sane_ctype[] const array
 (this branch is used by nd/retire-fnmatch.)

 Allows pathname patterns in .gitignore and .gitattributes files
 with double-asterisks "foo/**/bar" to match any number of directory
 hierarchies.

--------------------------------------------------
[Discarded]

* jc/doc-default-format (2013-01-03) 2 commits
 . Allow installing a non-default set of documentation
 . Allow generating a non-default set of documentation

 Instead of the default of generating html/man and installing man,
 you can control what "make doc" and "make install-doc" do via two
 make variables.

^ permalink raw reply

* Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07  3:20 UTC (permalink / raw)
  To: git
In-Reply-To: <7vip79lnnb.fsf@alter.siamese.dyndns.org>

I forgot to say that tonight's 'pu' seems to break t0008 and does
not pass the self-test. I didn't try figuring out if this is the
result of some mismerge, or one (or more) of the topics are broken.

^ permalink raw reply

* Re: [PATCH] git-send-email: treat field names as case-independent
From: Junio C Hamano @ 2013-01-07  3:27 UTC (permalink / raw)
  To: Nickolai Zeldovich; +Cc: git
In-Reply-To: <1357522498-8086-1-git-send-email-nickolai@csail.mit.edu>

Nickolai Zeldovich <nickolai@csail.mit.edu> writes:

> Field names like To:, Cc:, etc should be treated as case-independent;
> use a case-insensitive regexp to match them as such.  Previously,
> git-send-email would send email messages with a lowercase "cc:" line in
> the body without actually sending a copy of the message to that address.
>
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
> ---

While I think this patch is a sensible thing to do, I at the same
time wonder who is writing "cc:" in the lowercase in the first
place, and if that is one of our tools, we should fix that part as
well.  Such a header would leak out to the payload given to the
underlying sendmail, doesn't it?

Leaking such lowercased headers of course is not a crime (the
headers are case insensitive), but they look ugly.

>  git-send-email.perl |   10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 94c7f76..be809e5 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1285,10 +1285,10 @@ foreach my $t (@files) {
>  		}
>  
>  		if (defined $input_format && $input_format eq 'mbox') {
> -			if (/^Subject:\s+(.*)$/) {
> +			if (/^Subject:\s+(.*)$/i) {
>  				$subject = $1;
>  			}
> -			elsif (/^From:\s+(.*)$/) {
> +			elsif (/^From:\s+(.*)$/i) {
>  				($author, $author_encoding) = unquote_rfc2047($1);
>  				next if $suppress_cc{'author'};
>  				next if $suppress_cc{'self'} and $author eq $sender;
> @@ -1296,14 +1296,14 @@ foreach my $t (@files) {
>  					$1, $_) unless $quiet;
>  				push @cc, $1;
>  			}
> -			elsif (/^To:\s+(.*)$/) {
> +			elsif (/^To:\s+(.*)$/i) {
>  				foreach my $addr (parse_address_line($1)) {
>  					printf("(mbox) Adding to: %s from line '%s'\n",
>  						$addr, $_) unless $quiet;
>  					push @to, $addr;
>  				}
>  			}
> -			elsif (/^Cc:\s+(.*)$/) {
> +			elsif (/^Cc:\s+(.*)$/i) {
>  				foreach my $addr (parse_address_line($1)) {
>  					if (unquote_rfc2047($addr) eq $sender) {
>  						next if ($suppress_cc{'self'});
> @@ -1325,7 +1325,7 @@ foreach my $t (@files) {
>  			elsif (/^Message-Id: (.*)/i) {
>  				$message_id = $1;
>  			}
> -			elsif (!/^Date:\s/ && /^[-A-Za-z]+:\s+\S/) {
> +			elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) {
>  				push @xh, $_;
>  			}

^ permalink raw reply

* Re: [PATCH] git-send-email: treat field names as case-independent
From: Nickolai Zeldovich @ 2013-01-07  3:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9sllljh.fsf@alter.siamese.dyndns.org>

On Sun, Jan 6, 2013 at 10:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> While I think this patch is a sensible thing to do, I at the same
> time wonder who is writing "cc:" in the lowercase in the first
> place, and if that is one of our tools, we should fix that part as
> well.  Such a header would leak out to the payload given to the
> underlying sendmail, doesn't it?

In my case, I wrote the "cc:" headers by hand; it was not a result of
any automated tool.  (Yes, the header makes it into the message
payload.  This makes the bug all the more annoying: other people's
replies get cc:ed to the right address, but the original message never
gets sent there.)

Nickolai.

^ permalink raw reply

* Re: git push --force to update tag
From: Chris Rorvick @ 2013-01-07  3:42 UTC (permalink / raw)
  To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6Ss=KE8j_VZWf77A9FXantnwJvdDi1uoN9M-XO0c9GgEQ@mail.gmail.com>

On Sun, Jan 6, 2013 at 8:23 PM, 乙酸鋰 <ch3cooli@gmail.com> wrote:
> about git 1.8.2
>
>  * "git push" now requires "-f" to update a tag, even if it is a
>    fast-forward, as tags are meant to be fixed points.
>
> Does the server side validate this? Do we need to upgrade git on
> server side to support this?

This check is made by the side doing the push.  There is no additional
validation done on the remote side so it does not need an updated
version of Git for this feature to work correctly.

Chris

^ permalink raw reply

* recovering a corrupted git repo
From: Phillip Susi @ 2013-01-07  3:44 UTC (permalink / raw)
  To: git

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have not had any issue until I ran a git fsck recently, which
repored gzip and crc errors in some pack files.  git fsck does not
seem to repair the errors, only report them.  I would like to try to
rebuild my repository, without downloading any more from the origin
than I have to.  All of the commits I have added seem to still be
intact, so I assume the corruption in somewhere in the upstream
history packs.

How can I correct the errors, and fetch the corrupted upstream
history, while preserving my patches?  So far I have exported my
patches as bundles, and made a fresh clone from upstream, then pulled
the bundles back in, but there must be a better way that only fetches
the corrupted bits from upstream?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ6kS6AAoJEJrBOlT6nu75tFgIAJCI+DEWDVxddEQM5qhmz1y8
3JuqjTHp7gIXmQv6WGbEIehJrRfTBudQn+Ip2jLMwavvL16oZe+cf/uuLo393Z+T
pxEcWHOtjdU/XZeQOV//R/Cfo7PY5n8wfasgFYZuFesJchInwFocTI6S5x2B9kIB
dvLonoiDQwe9JqQaoAxM0OLTWe9aj0gc3c36+WUlRgRZijUhEogYQwU8aEoa+TMq
s2p+tbaNYKocRAafQ4824DMnuQTWb+HJVU4uI1pH2yB964Urq9ELSX2jxeSRdlaH
d+AoJ8oMdymmUwPeuyivcmQQHEGGsxxgCOuLSSHh1hcxMaytZNcEkVQ6OzuGyZk=
=yUr4
-----END PGP SIGNATURE-----

^ permalink raw reply

* Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07  5:13 UTC (permalink / raw)
  To: Adam Spiers; +Cc: git
In-Reply-To: <7vehhxllvz.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> I forgot to say that tonight's 'pu' seems to break t0008 and does
> not pass the self-test. I didn't try figuring out if this is the
> result of some mismerge, or one (or more) of the topics are broken.

An addendum.  This comes from the check-ignore patch and seems to
manifest itself when the test is run under /bin/dash (not bash).

Due to the mini-harness the test introduces, the output from running
the script with "-v -i" was not very helpful, and I stopped digging
at that point.

$ dash t0008-ignores.sh -i -v
...
expecting success:
                expect "$expect" &&
                eval "$code"

not ok - 64 existing tracked file at top-level not ignored
#
#                       expect "$expect" &&
#                       eval "$code"
#

^ permalink raw reply

* Re: [PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
From: Jonathan Nieder @ 2013-01-07  5:16 UTC (permalink / raw)
  To: René Scharfe; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <50E9B8CD.2010209@lsrfire.ath.cx>

René Scharfe wrote:

> InfoZIP's unzip takes default parameters from the environment variable
> UNZIP.  Unset it in the test library and use GIT_UNZIP for specifying
> alternate versions of the unzip command instead.
>
> t0024 wasn't even using variable for the actual extraction.  t5000
> was, but when setting it to InfoZIP's unzip it would try to extract
> from itself (because it treats the contents of $UNZIP as parameters),
> which failed of course.

That would only happen if the UNZIP variable was already exported,
right?

The patch makes sense and takes care of all uses of ${UNZIP} I can
find, and it even makes the quoting consistent so a person can put
their copy of unzip under "/Program Files".  For what it's worth,

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

^ permalink raw reply

* RE: Nike Air Max Shop
From: Jason Pyeron @ 2013-01-07  5:27 UTC (permalink / raw)
  To: git
In-Reply-To: <1357529831380-7574402.post@n2.nabble.com>

Is there a practical way to eliminate the spam here? Could vger.kernel.org use a
postini (list maintainers contact me offline about this) account?

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

^ permalink raw reply

* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jason Pyeron @ 2013-01-07  5:37 UTC (permalink / raw)
  To: git
In-Reply-To: <50E9F7C2.1000603@gmail.com>

> -----Original Message-----
> From: Mark Levedahl
> Sent: Sunday, January 06, 2013 17:17
> 
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>                                                           
> However, 
> >>> the newer win32api is provided only for the current 
> cygwin release 
> >>> series, which can be reliably identified by having dll version 
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from 
> >>> redhat, 1.5.x open source) still have the older api as no 
> updates are being made for the legacy version(s).
> >> Ah.  That makes sense, thanks.
> >>
> >> (For the future, if we wanted to diagnose an out-of-date 
> win32api and 
> >> print a helpful message, I guess cygcheck would be the command to 
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to 
> come up with 
> > a solution based on cygcheck (not on uname) to update this part, 
> > perhaps on top of Peff's "split default settings based on 
> uname into 
> > separate file" patch?
> >
> > If I understood what Mark and Torsten wrote correctly, you 
> will have 
> > the new win32api if you install 1.7.17 (or newer) from 
> scratch, but if 
> > you are on older 1.7.x then you can update the win32api part as a 
> > package update (as opposed to the whole-system upgrade).  A 
> test based 
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14) 
> > installation has a newer win32api because the user updated 
> it from the 
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> >
> > Am I on the same page as you guys, or am I still behind?
> >
> > In the meantime, perhaps we would need something like this?
> 
> It's perhaps worth noting how we got into this mess. The 
> problems have their root in
> 
>      adbc0b6b6e57c11ca49779d01f549260a920a97d
> 
> Cygwin's entire goal is a completely POSIX compliant 
> environment running under Windows. The above commit 
> circumvents some of Cygwin's API regarding stat/fstat to make 
> things perhaps a bit faster, and definitely not POSIX 

Ug!

> compliant (The commit message is wrong, the commit definitely 
> breaks POSIX compliance). That code is also what will not 
> compile on different w32api versions. It is curious: the 
> Cygwin  mailing list has been absolutely silent since the 
> w32api change was introduced last summer, this is the only 
> piece of code I am aware of that was broken by the new 
> headers, and of course the purpose of this code is to 

Um, going out on a limb here, but those headers are used internally as "cygwin"
apps are most likely to now know about those headers.

> circumvent the Cygwin API (and by extension, Cygwin project goals).
> 
> So, perhaps a better path forward is to disable / remove the 
> above code by default. (Those wanting a native Win32 git 
> should just use the native
> Win32 git).

Or a make option...



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

^ permalink raw reply

* Re: Moving (renaming) submodules, recipe/script
From: Jens Lehmann @ 2013-01-07  6:59 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: W. Trevor King, Git, Peter Collingbourne
In-Reply-To: <20130107013952.GE3823@elie.Belkin>

Am 07.01.2013 02:39, schrieb Jonathan Nieder:
> (just cc-ing Jens and Peter, who might be interested)

I´m currently working on teaching mv to move submodules and intend
to send those patches to the list after finishing submodule deinit.
Please see
  https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
for the current state of this series.

> W. Trevor King wrote:
> 
>> Today I had to move my first submodule, and I discovered that Git's
>> support for this is pretty limited.  There have been a few patch
>> series attempting to address this [1,2], but none of them seems to
>> have pushed through into master (although I can't put my finger on a
>> reason for why).  There are also some SO postings discussing this
>> [3,4].  It would be nice if `git mv` worked out of the box on
>> submodules.  Failing that, there could be a `git submodule mv` command
>> that casts the appropriate spell.  Failing that, there could be a
>> recipe in Documentation/git-submodule.txt.  Here's the best I could
>> come up with for a `git-submodule-mv.sh`:
>>
>>   #!/bin/sh
>>   # usage: git-submodule-mv.sh OLD NEW
>>   OLD=$(realpath --relative-to . "$1")
>>   NEW=$(realpath --relative-to . "$2")
>>   SHA=$(git ls-files -s "$OLD" | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|')
>>   NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' "$OLD" |
>>     sed -e 's|^submodule.||' -e "s|.path $OLD\$||")
>>   GITDIR=$(realpath --relative-to "$NEW" .git/modules/"$NAME")
>>   git config -f .gitmodules submodule."$NAME".path "$NEW"
>>   git config -f .git/modules/"$NAME"/config core.worktree "../../../$NEW"
>>   git rm --cached "$OLD"
>>   mv "$OLD" "$NEW"
>>   echo "gitdir: $GITDIR" > "$NEW/.git"
>>   git update-index --add --cacheinfo 160000 "$SHA" "$NEW"
>>
>> This only works from the repository root directory, and I'm sure makes
>> a number of poor assumptions (e.g. old-style submodules that don't use
>> `gitdir` links are not supported).  It does work for some simple test
>> cases.  The tricky parts (e.g. path -> name conversion) are already
>> worked out more robustly git-submodule.sh, so adding a new cmd_mv
>> shouldn't be very difficult.
>>
>> Could something like this live somewhere in Git, or are we waiting for
>> a more integrated solution?
>>
>> Cheers,
>> Trevor
>>
>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720
>> [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250
>> [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git
>> [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox