date:20130426


Hi List, 

after experiencing one crash to many, I'm back to Standard Emacs
(instead of Emacsserver/Emacsclient), thus using 'emacs' (instead of
emacsclient) as git core editor triggers reading my huge init file and
is way to slow.

I would like to use Zile (a small Emacs clone) instead, and although
otherwise it works alright on my system, it does not seem to work as git
core editor. 

Is it possible to use 'git config --global core.editor zile'?

-- 
cheers,
Thorsten


--
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] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin

When running `git clean`, it will be convenient and safe to show a
confirm dialog and only delete files and directories when confirmed.
The confirm dialog will popup when:

 * run `git clean` in interactive sessions,
 * not a dry run,
 * and not quiet.

There may be existing scripts that call `git clean -f` while leave the
standard input and the standard output of the `git clean` connected to
whatever environment the scripts were started, and such invocation might
trigger the confirm dialog. In this case, add a `-q` option, such as
`git clean -q -f`, then the confirm dialog won't popup.

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

diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..e31a1 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -169,6 +169,10 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
N_(remove only ignored files)),
OPT_END()
};
+   struct string_list dels = STRING_LIST_INIT_DUP;
+   struct string_list_item *item;
+   struct strbuf confirm = STRBUF_INIT;
+   int confirmed = 0;
 
git_config(git_clean_config, NULL);
if (force  0)
@@ -257,33 +261,67 @@ 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)) 
{
+   string_list_append(dels, ent-name);
+   }
+   } else {
+   if (pathspec  !matches)
+   continue;
+   string_list_append(dels, ent-name);
+   }
+   }
+
+   if (!isatty(0) || !isatty(1) || quiet || dry_run) {
+   confirmed = 1;
+   }
+
+   if (!confirmed  dels.nr  0) {
+   for_each_string_list_item(item, dels) {
+   qname = quote_path_relative(item-string, -1, buf, 
prefix);
+   printf(_(msg_would_remove), qname);
+   }
+   printf(_(Are you sure [y/N]? ));
+   strbuf_getline(confirm, stdin, '\n');
+   strbuf_trim(confirm);
+   if (!strcasecmp(confirm.buf, y)) {
+   confirmed = 1;
+   }
+   }
+
+   if (confirmed) {
+   for_each_string_list_item(item, dels) {
+   struct stat st;
+
+   if (lstat(item-string, st))
+   continue;
+
+   if (S_ISDIR(st.st_mode)) {
+   strbuf_addstr(directory, item-string);
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);
}
-   }
-   strbuf_reset(directory);
-   } else {
-   if (pathspec  !matches)
-   continue;
-   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);
+   strbuf_reset(directory);
+   } else {
+   res = dry_run ? 0 : unlink(item-string);
+   if (res) {
+   qname = 
quote_path_relative(item-string, -1, buf, prefix);
+   warning(_(msg_warn_remove_failed), 
qname);
+   errors++;
+   } else if (!quiet) {
+   qname = 
quote_path_relative(item-string, -1, buf, prefix);
+   printf(dry_run ? _(msg_would_remove) : 
_(msg_remove), qname);
+   }
}
}
}
free(seen);
 
strbuf_release(directory);
+   strbuf_release(confirm);
string_list_clear(exclude_list, 0);
+   string_list_clear(dels,

Re: Itches with the current rev spec

2013-04-26 Thread Yann Dirson

2. git rebase -i master fails unless I've rebased my branch on top of
master.  I always wished I could do the equivalent of 'git rebase -i
master..', but I can't.  Can we give the A..B syntax a new meaning in
the context of rebase, namely $(git merge-base A B)? 

If I understand well, you're refering to a problem that also annoys me,
ie. using rebase -i to just edit your local commits, without rebasing
onto the lastest revision on the upstream branch, right ?  That is, just
another wart of having a single command for arguably-different use cases,
or of having the single-argument version of rebase use that argument for
2 very different things (cut-off point and destination), but I won't try
to address either of these today :)

In that case, what about just adding a new flag to rebase -i, that would
prevent the single-argument to be interpreted as destination ?  I really
consider this a workaround for a suboptimal CLI, but since we don't want
to change the rebase CLI before at least 2.0, that could fill the gap for now.

As for the flag itself, what about --here ?  Obviously it would only be
meaninglful together with -i, and be exclusive with --onto.

-- 
Yann Dirson - Bertin Technologies
--
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] clean: confirm before cleaning files and directories

Jiang Xin worldhello@gmail.com writes:

  * run `git clean` in interactive sessions,
  * not a dry run,
  * and not quiet.

Err, does this mean I'll have:

$ git clean
fatal: clean.requireForce defaults to true and neither -n nor -f given; 
refusing to clean
$ git clean --force
Are you sure [y/n]?

An optional confirmation dialog seems interesting, but activating it by
default even with --force seems really weird.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Zile as git core editor?

2013-04-26 Thread Tay Ray Chuan

Hi,

Is the GIT_EDITOR or EDITOR environment variable set? They may be
overriding the core.editor setting.

--
Cheers,
Ray Chuan

On Fri, Apr 26, 2013 at 3:39 PM, Thorsten Jolitz tjol...@gmail.com wrote:

 Hi List,

 after experiencing one crash to many, I'm back to Standard Emacs
 (instead of Emacsserver/Emacsclient), thus using 'emacs' (instead of
 emacsclient) as git core editor triggers reading my huge init file and
 is way to slow.

 I would like to use Zile (a small Emacs clone) instead, and although
 otherwise it works alright on my system, it does not seem to work as git
 core editor.

 Is it possible to use 'git config --global core.editor zile'?

 --
 cheers,
 Thorsten


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

Re: Zile as git core editor?

Tay Ray Chuan rcta...@gmail.com writes:

Hi,

 Is the GIT_EDITOR or EDITOR environment variable set? They may be
 overriding the core.editor setting.

Actually, EDITOR is set to Zile, so that should not be the problem:

[tj@hostname ~]$ echo $EDITOR
/usr/bin/zile
[tj@hostname ~]$ echo $GIT_EDITOR

[tj@hostname ~]$ 

BTW - would 'git config --global core.editor zile' or 'git config
--global core.editor /usr/bin/zile' the right way to set it (both did
not work)? I can start Zile simply with 'zile' on the command line. 

 --
 Cheers,
 Ray Chuan

 On Fri, Apr 26, 2013 at 3:39 PM, Thorsten Jolitz tjol...@gmail.com wrote:

 Hi List,

 after experiencing one crash to many, I'm back to Standard Emacs
 (instead of Emacsserver/Emacsclient), thus using 'emacs' (instead of
 emacsclient) as git core editor triggers reading my huge init file and
 is way to slow.

 I would like to use Zile (a small Emacs clone) instead, and although
 otherwise it works alright on my system, it does not seem to work as git
 core editor.

 Is it possible to use 'git config --global core.editor zile'?

 --
 cheers,
 Thorsten


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

-- 
cheers,
Thorsten

--
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] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin

2013/4/26 Matthieu Moy matthieu@grenoble-inp.fr

 Jiang Xin worldhello@gmail.com writes:

   * run `git clean` in interactive sessions,
   * not a dry run,
   * and not quiet.

 Err, does this mean I'll have:

 $ git clean
 fatal: clean.requireForce defaults to true and neither -n nor -f given; 
 refusing to clean
 $ git clean --force

( you omit something, because nothing to clean won't trigger this
confirm dialog)

 Are you sure [y/n]?

 An optional confirmation dialog seems interesting, but activating it by
 default even with --force seems really weird.

I don't know how many programmers had been bitten by runing `git clean -fdx`,
but I bet there were some. I think safety should be put to the 1st place.
It is because clean.requireForce defaults to true, all people trend to run
'git clean' with the '--force/-f' option.

Maybe we can do like this:

1. Set the default value of 'clean.requireForce' to false.
2. Show a error message and do nothing, if there is not 'clean.requireForce'
setting, but the user called with a '--force' flag.
( like a transition for the change of push.default in git 2.0)

any opinions?


 --
 Matthieu Moy
 http://www-verimag.imag.fr/~moy/




--
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
--
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: Itches with the current rev spec

2013-04-26 Thread Johannes Sixt

Am 4/26/2013 10:19, schrieb Yann Dirson:
 2. git rebase -i master fails unless I've rebased my branch on top of
 master.  I always wished I could do the equivalent of 'git rebase -i
 master..', but I can't.  Can we give the A..B syntax a new meaning in
 the context of rebase, namely $(git merge-base A B)? 
 
 If I understand well, you're refering to a problem that also annoys me,
 ie. using rebase -i to just edit your local commits, without rebasing
 onto the lastest revision on the upstream branch, right ?  That is, just
 another wart of having a single command for arguably-different use cases,
 or of having the single-argument version of rebase use that argument for
 2 very different things (cut-off point and destination), but I won't try
 to address either of these today :)
 
 In that case, what about just adding a new flag to rebase -i, that would
 prevent the single-argument to be interpreted as destination ?  I really
 consider this a workaround for a suboptimal CLI, but since we don't want
 to change the rebase CLI before at least 2.0, that could fill the gap for now.
 
 As for the flag itself, what about --here ?  Obviously it would only be
 meaninglful together with -i, and be exclusive with --onto.

How about this:

Allow alternative spelling of

   git rebase -i master topic

like this:

   git rebase -i master..topic

(as always, the default for topic is HEAD).

Then by extension (cf. git diff, where A...B shows the diff between the
mergebase and B)

   git rebase -i master...topic

would rebase onto the mergebase, which in practice will be the fork point
of topic, i.e., a non-rebasing rebase.

-- 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] clean: confirm before cleaning files and directories

Jiang Xin worldhello@gmail.com writes:

 Maybe we can do like this:

 1. Set the default value of 'clean.requireForce' to false.
 2. Show a error message and do nothing, if there is not 'clean.requireForce'
 setting, but the user called with a '--force' flag.
 ( like a transition for the change of push.default in git 2.0)

Perhaps introducing a new value for 'clean.requireForce':

$ git config --global clean.requireForce ask
$ git clean
will remove ...
are you sure [y/N]?

The error message when clean.requireForce is unset and --force is not
given could point the user to clean.requireForce=ask.

Then, maybe, later, this could become the default. But I tend to like
the non-interactive nature of most Git commands, so I'm a bit reluctant
here. My way of doing the confirmation dialog is

$ git clean -n
would remove ...
$ git clean -f

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Thomas Rast

Jiang Xin worldhello@gmail.com writes:

 I don't know how many programmers had been bitten by runing `git clean -fdx`,
 but I bet there were some. I think safety should be put to the 1st place.
 It is because clean.requireForce defaults to true, all people trend to run
 'git clean' with the '--force/-f' option.

But if that's the real problem, wouldn't it be better to introduce
something like clean.requireForce=interactive (or 'ask', or whatever you
make up) which will be like clean.requireForce=true except that when on
a TTY, we ask the user?

-- 
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: Zile as git core editor?

Thorsten Jolitz tjol...@gmail.com writes:

 BTW - would 'git config --global core.editor zile' or 'git config
 --global core.editor /usr/bin/zile' the right way to set it (both did
 not work)? I can start Zile simply with 'zile' on the command line. 

What do you mean by did not work? Does the launching fail? Or is
another editor launched?

Try:

GIT_TRACE=true git commit -a

to see what's going on.

BTW, you may also try emacs -nw -Q instead of zile.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] test-hg-hg-git.sh: do not use export X=Y

The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X

Signed-off-by: Torsten Bögershausen tbo...@web.de
---
 contrib/remote-helpers/test-hg-hg-git.sh | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/contrib/remote-helpers/test-hg-hg-git.sh 
b/contrib/remote-helpers/test-hg-hg-git.sh
index 253e65a..8440341 100755
--- a/contrib/remote-helpers/test-hg-hg-git.sh
+++ b/contrib/remote-helpers/test-hg-hg-git.sh
@@ -103,10 +103,11 @@ setup () {
git config --global receive.denycurrentbranch warn
git config --global remote-hg.hg-git-compat true
 
-   export HGEDITOR=/usr/bin/true
+   HGEDITOR=/usr/bin/true
 
-   export GIT_AUTHOR_DATE=2007-01-01 00:00:00 +0230
-   export GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
+   GIT_AUTHOR_DATE=2007-01-01 00:00:00 +0230
+   GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
+   export HGEDITOR GIT_AUTHOR_DATE GIT_COMMITTER_DATE
 }
 
 setup
@@ -296,7 +297,8 @@ test_expect_success 'encoding' '
git add alpha 
git commit -m add älphà 
 
-   export GIT_AUTHOR_NAME=tést èncödîng 
+   GIT_AUTHOR_NAME=tést èncödîng 
+   export GIT_AUTHOR_NAME 
echo beta  beta 
git add beta 
git commit -m add beta 
-- 
1.8.2.1.614.g66d7af5


--
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 3/5] test-hg-bidi.sh: do not use export X=Y

The shell syntax export X=Y A=B is not understood by all shells.
Split the non portable line into separate lines like this:
A=B
X=Y
export A X

Signed-off-by: Torsten Bögershausen tbo...@web.de
---
 contrib/remote-helpers/test-hg-bidi.sh | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/contrib/remote-helpers/test-hg-bidi.sh 
b/contrib/remote-helpers/test-hg-bidi.sh
index f368953..f569697 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -68,10 +68,10 @@ setup () {
)  $HOME/.hgrc 
git config --global remote-hg.hg-git-compat true
 
-   export HGEDITOR=/usr/bin/true
-
-   export GIT_AUTHOR_DATE=2007-01-01 00:00:00 +0230
-   export GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
+   HGEDITOR=/usr/bin/true
+   GIT_AUTHOR_DATE=2007-01-01 00:00:00 +0230
+   GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
+   export HGEDITOR GIT_AUTHOR_DATE GIT_COMMITTER_DATE
 }
 
 setup
@@ -88,7 +88,8 @@ test_expect_success 'encoding' '
git add alpha 
git commit -m add älphà 
 
-   export GIT_AUTHOR_NAME=tést èncödîng 
+   GIT_AUTHOR_NAME=tést èncödîng 
+   export GIT_AUTHOR_NAME 
echo beta  beta 
git add beta 
git commit -m add beta 
-- 
1.8.2.1.614.g66d7af5


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

[PATCH 2/5] t9501: do not use export X=Y

The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X

Signed-off-by: Torsten Bögershausen tbo...@web.de
---
 t/t9501-gitweb-standalone-http-status.sh | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/t/t9501-gitweb-standalone-http-status.sh 
b/t/t9501-gitweb-standalone-http-status.sh
index ef86948..d3a5bac 100755
--- a/t/t9501-gitweb-standalone-http-status.sh
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -130,7 +130,8 @@ test_expect_success DATE_PARSER 'modification: feed 
last-modified' '
 test_debug 'cat gitweb.headers'
 
 test_expect_success DATE_PARSER 'modification: feed if-modified-since 
(modified)' '
-   export HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   export HTTP_IF_MODIFIED_SINCE 
test_when_finished unset HTTP_IF_MODIFIED_SINCE 
gitweb_run p=.git;a=atom;h=master 
grep Status: 200 OK gitweb.headers
@@ -138,7 +139,8 @@ test_expect_success DATE_PARSER 'modification: feed 
if-modified-since (modified)
 test_debug 'cat gitweb.headers'
 
 test_expect_success DATE_PARSER 'modification: feed if-modified-since 
(unmodified)' '
-   export HTTP_IF_MODIFIED_SINCE=Thu, 7 Apr 2005 22:14:13 + 
+   HTTP_IF_MODIFIED_SINCE=Thu, 7 Apr 2005 22:14:13 + 
+   export HTTP_IF_MODIFIED_SINCE 
test_when_finished unset HTTP_IF_MODIFIED_SINCE 
gitweb_run p=.git;a=atom;h=master 
grep Status: 304 Not Modified gitweb.headers
@@ -153,7 +155,8 @@ test_expect_success DATE_PARSER 'modification: snapshot 
last-modified' '
 test_debug 'cat gitweb.headers'
 
 test_expect_success DATE_PARSER 'modification: snapshot if-modified-since 
(modified)' '
-   export HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   export HTTP_IF_MODIFIED_SINCE 
test_when_finished unset HTTP_IF_MODIFIED_SINCE 
gitweb_run p=.git;a=snapshot;h=master;sf=tgz 
grep Status: 200 OK gitweb.headers
@@ -161,7 +164,8 @@ test_expect_success DATE_PARSER 'modification: snapshot 
if-modified-since (modif
 test_debug 'cat gitweb.headers'
 
 test_expect_success DATE_PARSER 'modification: snapshot if-modified-since 
(unmodified)' '
-   export HTTP_IF_MODIFIED_SINCE=Thu, 7 Apr 2005 22:14:13 + 
+   HTTP_IF_MODIFIED_SINCE=Thu, 7 Apr 2005 22:14:13 + 
+   export HTTP_IF_MODIFIED_SINCE 
test_when_finished unset HTTP_IF_MODIFIED_SINCE 
gitweb_run p=.git;a=snapshot;h=master;sf=tgz 
grep Status: 304 Not Modified gitweb.headers
@@ -170,7 +174,8 @@ test_debug 'cat gitweb.headers'
 
 test_expect_success DATE_PARSER 'modification: tree snapshot' '
ID=`git rev-parse --verify HEAD^{tree}` 
-   export HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   HTTP_IF_MODIFIED_SINCE=Wed, 6 Apr 2005 22:14:13 + 
+   export HTTP_IF_MODIFIED_SINCE 
test_when_finished unset HTTP_IF_MODIFIED_SINCE 
gitweb_run p=.git;a=snapshot;h=$ID;sf=tgz 
grep Status: 200 OK gitweb.headers 
-- 
1.8.2.1.614.g66d7af5


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

[PATCH 1/5] t9020: do not use export X=Y

The shell syntax export X=Y is not understood by all shells.
Split the non portable line into separate lines like this:
X=Y
export X

Signed-off-by: Torsten Bögershausen tbo...@web.de
---
 t/t9020-remote-svn.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh
index 2d2f016..d9f6b73 100755
--- a/t/t9020-remote-svn.sh
+++ b/t/t9020-remote-svn.sh
@@ -74,7 +74,8 @@ test_expect_success REMOTE_SVN 'mark-file regeneration' '
 '
 
 test_expect_success REMOTE_SVN 'incremental imports must lead to the same 
head' '
-   export SVNRMAX=3 
+   SVNRMAX=3 
+   export SVNRMAX 
init_git 
git fetch svnsim 
test_cmp .git/refs/svn/svnsim/master .git/refs/remotes/svnsim/master  
-- 
1.8.2.1.614.g66d7af5


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

[PATCH 5/5] t7409: do not use export X=Y

The shell syntax export X=Y A=B is not understood by all shells.
Split the non portable line into separate lines like this:
A=B
X=Y
export A X

Signed-off-by: Torsten Bögershausen tbo...@web.de
---
 t/t7409-submodule-detached-worktree.sh | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/t/t7409-submodule-detached-worktree.sh 
b/t/t7409-submodule-detached-worktree.sh
index 2fec13d..c207171 100755
--- a/t/t7409-submodule-detached-worktree.sh
+++ b/t/t7409-submodule-detached-worktree.sh
@@ -23,7 +23,9 @@ test_expect_success 'submodule on detached working tree' '
mkdir home 
(
cd home 
-   export GIT_WORK_TREE=$(pwd) GIT_DIR=$(pwd)/.dotfiles 
+   GIT_WORK_TREE=$(pwd) 
+   GIT_DIR=$(pwd)/.dotfiles 
+   export GIT_WORK_TREE GIT_DIR 
git clone --bare ../remote .dotfiles 
git submodule add ../bundle1 .vim/bundle/sogood 
test_commit sogood 
@@ -39,7 +41,9 @@ test_expect_success 'submodule on detached working tree' '
(
cd home2 
git clone --bare ../remote .dotfiles 
-   export GIT_WORK_TREE=$(pwd) GIT_DIR=$(pwd)/.dotfiles 
+   GIT_WORK_TREE=$(pwd) 
+   GIT_DIR=$(pwd)/.dotfiles 
+   export GIT_WORK_TREE GIT_DIR 
git checkout master 
git submodule update --init 
(
@@ -55,7 +59,8 @@ test_expect_success 'submodule on detached working pointed by 
core.worktree' '
mkdir home3 
(
cd home3 
-   export GIT_DIR=$(pwd)/.dotfiles 
+   GIT_DIR=$(pwd)/.dotfiles 
+   export GIT_DIR 
git clone --bare ../remote $GIT_DIR 
git config core.bare false 
git config core.worktree .. 
@@ -66,7 +71,8 @@ test_expect_success 'submodule on detached working pointed by 
core.worktree' '
) 
(
cd home 
-   export GIT_DIR=$(pwd)/.dotfiles 
+   GIT_DIR=$(pwd)/.dotfiles 
+   export GIT_DIR 
git config core.bare false 
git config core.worktree .. 
git pull 
-- 
1.8.2.1.614.g66d7af5

--
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] t9501: Do not use export X=Y

On 2013-04-25 22.46, Junio C Hamano wrote:
 Torsten Bögershausen tbo...@web.de writes:
 
 Spilt lines like export X=Y into 2 lines:
 X=Y
 export X
 
 That can be read from the patch text.
 
 If you are going to spend three lines, please describe why it has to
 be split; that would help educate developers new to the codebase.
 
So true,
writing good commit messages is not easy.
and this was a good example for a bad example

Side questions:
Which shells of which OS/distribution do not understand export X=Y?

--
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/9] remote-bzr: trivial cleanups

Felipe Contreras wrote:
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all, Ramkumar
Ramachandra, did so in a bellicose tone, but I replied to all his
comments either way, which where invalid.

I've never wanted to pick fights with anyone, and I don't foresee
having a desire to do so in the future. I was just saying what was on
my mind, which is along the lines of: you have written this patch with
the attitude I know what I'm doing, my users will benefit, and nobody
else is going to look at this patch anyway; I'm worried about what
your other patches look like if this is your attitude towards
development. Junio is harping about the same thing: the impedance
mismatch between you and the rest of us.

The history *is* readable. If anybody has any problems with the commit
messages, the place to mention such problems is IN THE PATCH REVIEW.
Nobody has done that, because either nobody has any problems, or they
are not interested. Either way, there's nothing I can do about it.

That's what I've been trying to say over and over again: _why_ are
people not reviewing your patches?

0. Because nobody has any problems with them.

1. Because nobody on the git list cares about remote-hg.

2. Because you're stubborn as a mule, and the resulting thread often
results in long-winded discussions like this one (which wastes
everyone's time). Therefore, the potential reviewer's reasoning is
that their review time is better spent elsewhere, where their review
is actually appreciated.

Hint: it's not (0).

If you're claiming that (1) is the case, then why are you posting to
the git list and hitting everyone's inboxes? Maintain your project
outside git.

I'm claiming that it's (2). In which case, it's you who needs changing.

I'm willing to change my ways when there's reason to change my ways,
and so far, nobody has provided any evidence that my commit messages
are indeed lacking, only *opinions*.

You want a formal mathematical proof? We operate on opinions, and
freeze what we think we all agree with into community guidelines.

Other people are perfectly fine with them:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=authorq=felipe.contreras

So you're now claiming that we're the ones at fault (Peff, Thomas,
Junio, and me, among others). Okay, so why are you forcing your
changes and opinions down our throats? You're in the wrong community:
join a community of people who are more like you (or start your own
project), and stop wasting our time.

Junio C Hamano wrote:
I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for developers.

On this.

If Peff were to suddenly stop working on git one day (because he was
frustrated with the community/ development practices), we'd all lose a
lot more than if one random end-user switches to using hg for his tiny
personal projects. I'm _not_ claiming that there's a split between
users and users that are developers (we have one mailing list for
everyone, and I like that). What I'm claiming is that we cannot (and
should not) pay equal attention to every user of git. Some users are
more important than others. Again, that does _not_ mean that we push
a change that benefits one important user but breaks everyone else's
setup.

Ofcourse the project exists for its users; we're not doing research.
However, we don't all have to write tutorials to keep in touch with
end-users who are completely detached from the development process
(our time is better spent elsewhere), or even have an
end-user-friendly bug tracker (where the SNR is very low). We don't
have to consciously reach out to people we're not connected to
directly: if we're all sufficiently connected to the real world, the
itches/ bugs worth working on will always find their way to us. We
live in a connected world.

Yes, I know. You're going to respond to this email arguing about why
you're Right and why I (and everyone else) is Wrong, either by quoting
what Linus (TM) said and twisting it to mean what you want, belaboring
over what you've already said, or something similar.

I've given up on you, and I suspect a lot of other people have too.
--
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] t5801: properly test the test shell

2013-04-26 Thread Michael J Gruber

Junio C Hamano venit, vidit, dixit 25.04.2013 19:12:
 Junio C Hamano gits...@pobox.com writes:
 
 Michael J Gruber g...@drmicha.warpmail.net writes:

 fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) introduced a
 test which was meant to skip the test unless the test shell is bash.
 Unfortunately, it tests for the availability of bash only.

 True.

 But users can
 opt to use a different shell (using SHELL_PATH) for the tests even though
 bash is available.

 At least for dash,
 21610d8 (transport-helper: clarify pushing without refspecs, 2013-04-17)
 is the commit which actually introduces a test (pushing without refspec)
 which fails to fail even though it is supposed to. It uses the
 construct:

 VAR=value function arguments

 The right fix for that is to fix that line, so that the test itself
 can run under any sane POSIX shell, isn't it?  The test in turn may
 need to run git-remote-testgit, which, without J6t's updates, only
 is usable under bash, but to make sure the test will choke on
 absence of bash, the existing check should be sufficient, no?
 
 Curiously enough, there were a few instances of the correct set and
 export environment explicitly during the life of subshell construct
 already in the script.  I found only this one as problematic.
 
 Does it fix your issue without your change?
 
 It is a separate issue to port git-remote-testgit to POSIX (J6t
 already has a two part draft), move it to git-remote-testgit.sh, and
 get its shebang line preprocessed like all other shell scripts.  I
 think it is worth doing.
 
 Takers?
 
  t/t5801-remote-helpers.sh | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
 index 4dcf744..c956abd 100755
 --- a/t/t5801-remote-helpers.sh
 +++ b/t/t5801-remote-helpers.sh
 @@ -118,7 +118,9 @@ test_expect_success 'pushing without refspecs' '
   (cd local2 
   echo content file 
   git commit -a -m ten 
 - GIT_REMOTE_TESTGIT_REFSPEC= test_must_fail git push 2../error) 
 + GIT_REMOTE_TESTGIT_REFSPEC= 
 + export GIT_REMOTE_TESTGIT_REFSPEC 
 + test_must_fail git push 2../error) 
   grep remote-helper doesn.t support push; refspec needed error
  '
  
 

Perfect, I just failed to notice that the subshell would make the export
local to that test.

Thanks!

Michael
--
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] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin

2013/4/26 Matthieu Moy matthieu@grenoble-inp.fr:
 Jiang Xin worldhello@gmail.com writes:

 Maybe we can do like this:

 1. Set the default value of 'clean.requireForce' to false.
 2. Show a error message and do nothing, if there is not 'clean.requireForce'
 setting, but the user called with a '--force' flag.
 ( like a transition for the change of push.default in git 2.0)

 Perhaps introducing a new value for 'clean.requireForce':

 $ git config --global clean.requireForce ask
 $ git clean
 .will remove ...
 are you sure [y/N]?

 The error message when clean.requireForce is unset and --force is not
 given could point the user to clean.requireForce=ask.

Add new value for clean.requireForce would break old git clent.

   $ git clean
   fatal: bad config value for 'clean.requireforce' in .git/config


 Then, maybe, later, this could become the default. But I tend to like
 the non-interactive nature of most Git commands, so I'm a bit reluctant
 here. My way of doing the confirmation dialog is

 $ git clean -n
 would remove ...
 $ git clean -f


I try to put all cases in one table, but still looks weird.

| clean.requireForce  | git clean | git clean --force |
+-+---|---|
| TRUE| error | delete... |
+-+---|---|
| FALSE   | delete... | delete... |
+-+---|---|
| unset   | confirm   | warn + confirm|
+-+---|---|

Does anyone really set and use clean.requireForce setting?
And if there is a confirm dialog, do we need 'clean.requireForce' any more?
Or we can add a `--no-ask` option, in order to override the confirm dialog.


 --
 Matthieu Moy
 http://www-verimag.imag.fr/~moy/



--
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
--
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: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote:
 The range version of $(git merge-base A B) B is B ^$(git merge-base A
 B), and not B --not $(git merge-base --all A B) [which is equivalent
 to B ^A or A..B].

Let me make this easier for you, and everyone else.

In git.git, checkout master and merge 9915605c^2 (rr/shortlog-doc).
So, my changeset has graduated from 'pu' to 'master' (I know 'master'
is directly ahead of 'pu', and this is not what you do; but this is
just an exercise).  Now, I execute git log master..pu and search for
the author Ramkumar Ramachandra.  I can see that my shortlog-doc
commits aren't present; so I infer that my changes have graduated to
master.  I can also see the merge commit corresponding to
rr/shortlog-doc, and infer that master merged in rr/shortlog-doc
differently.

If I execute git log pu ^$(git merge-base master pu), I see the merge
commit rr/shortlog-doc _and_ the shortlog-doc commits.  Here, I don't
want to know if my change graduated to master or not: I just want to
know what changes were introduced by the pu branch since the last
fork.  Think of it as a time-truncated version of git log pu: it has
nothing to do with reachability.  The only reason that master even
appears in the command is because I need to specify where pu forked
off from.

I would argue that this is incredibly useful: to see what changes were
introduced by my branch independent of everything else.  What do you
think?
--
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: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote:
 Think of it as a time-truncated version of git log pu: it has
 nothing to do with reachability.

Er, scratch that out.  I don't like talking in vague terms, and this
feature has nothing to do with git log --since (which is what
time-truncated 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: [PATCHv2 7/7] git grep: honor textconv by default

2013-04-26 Thread Michael J Gruber

Junio C Hamano venit, vidit, dixit 24.04.2013 20:55:
 Matthieu Moy matthieu@grenoble-inp.fr writes:
 
 Grepping through the binary, on the other hand, can very well make
 sense, like:

 $ git grep foo
 file.txt: some instance of foo
 binary file bar.bin matches

BTW, textconv does not have to be slow - just use textconv-cache.

 Yes, 
 
 I am moderately negative on making it the default, mostly because it
 goes against established expectations, but I did not mean to say
 that an ability to pass blob contents through textconv before
 running grep should not exist.  It would be a good option to have.

I'm still looking for a way to at least treat git grep and git show
blob the same way. I understand that I cannot convince you to change
the default here. The two options that I see are:

- Implement the --textconv option but leave the default as is. I did
that for git grep already (just drop 7/7) but it seems to be
cumbersome for git show blob. I have to recheck.

- Implement a new attribute show analogous to diff which applies to
the blob case (git grep is a blob case, and so is git show blob)
which can specify a show driver, which is like a diff driver but
understands textconv and cachetextconv options only.
Here, the default would be --textconv in any case, but unless you
specify a show attribute and driver there is no change in current
behavior.

The second case is a bit like clean/smudge, so, alternatively, one could
add a textconv and cachetextconv option to filter rather than
introducing show. I'm not sure how much the textconv machinery needs
to change, though.

Michael
--
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/9] remote-bzr: trivial cleanups

Felipe Contreras wrote:
 Any sensible reviewer would be context aware, notice that this
 is a contrib patch, and focus on behavioral changes, notice the
 mistake I made, and point that *one* of the changes was changing the
 behavior, at which point I would agree and reroll either without that
 change, or with the change in a separate commit (which I don't want to
 do right now). The maintainer (you), wouldn't even have to reply at
 all.

Personally, I think it is the job of the submitter to provide a really
helpful commit message and widen his review audience.  If I'm hitting
the git mailing list with my patches, I try to make sure that nearly
everyone on the list can understand what I've done and potentially
review it.  Why else would I want to hit their inboxes with my
patches?

Here's my solution to the problem: maintain your project outside
git.git and merge changes in every couple of months or so with a
simple email containing a pull URL, addressing Junio.  If Junio trusts
you enough to put the changes you send into contrib/ after a cursory
glance, we're done.  Start a separate mailing list for your project/
accept GitHub pull requests via which contributors can send you
changes.  No more fuss or drama on the git list about this.  You can
be as stubborn as you want, and we go back to our lives.  Everyone
wins.

If you want to submit patches to other parts of git, you seriously
need to change your ways.  Let's deal with that problem when it arises
next.
--
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: Itches with the current rev spec

Johannes Sixt wrote:
git rebase -i master..topic
git rebase -i master...topic

We absolutely don't want to go down the inconsistent diff UI route.  See [1].

[1]: http://thread.gmane.org/gmane.comp.version-control.git/48
--
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 7/7] git grep: honor textconv by default

Michael J Gruber g...@drmicha.warpmail.net writes:

 BTW, textconv does not have to be slow - just use textconv-cache.

Right, thanks for reminding me about this, I had forgotten its existance ;-).

 I'm still looking for a way to at least treat git grep and git show
 blob the same way.

I agree they should be treated similarly.

 - Implement the --textconv option but leave the default as is. I did
 that for git grep already (just drop 7/7)

That seems sensible.

 but it seems to be cumbersome for git show blob. I have to recheck.

It should be possible to have a tri-state for the --[no-]textconv
option: unset, set to true or set to false. But the code sharing between
log, show and diff might make that non-trivial.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] inotify to minimize stat() calls

2013-04-26 Thread Robert Zeh

On Thu, Apr 25, 2013 at 4:20 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Fri, Apr 26, 2013 at 2:44 AM, Robert Zeh robert.allan@gmail.com 
 wrote:
 Can you just replace lstat/stat with cached_lstat/stat inside
 git-compat-util.h and not touch all files at once? I think you may
 need to deal with paths outside working directory. But because you're
 using lookup table, that should be no problem.

 That's a good idea; but there are a few places where you want to call
 the uncached stat because calling the cache leads to recursion or
 you bump into things that haven't been setup yet.  Any ideas how to
 handle that?

 On second thought, no my idea was stupid. We only need to optimize
 lstat for certain cases and naming cached_lstat is much clearer. I
 suspect read-cache.c and maybe dir.c and unpack-trees.c are the only
 places that need cached_lstat. Other places should not issue many
 lstats and we don't need to touch them.

ok.  The only reason I did it for all of them was the it was a simple search
and replace, and I didn't know how often lstat was called from various
locations.
--
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: Zile as git core editor?

Matthieu Moy matthieu@grenoble-inp.fr writes:

 Thorsten Jolitz tjol...@gmail.com writes:

 BTW - would 'git config --global core.editor zile' or 'git config
 --global core.editor /usr/bin/zile' the right way to set it (both did
 not work)? I can start Zile simply with 'zile' on the command line. 

 What do you mean by did not work? Does the launching fail? Or is
 another editor launched?

 Try:

 GIT_TRACE=true git commit -a

 to see what's going on.

 BTW, you may also try emacs -nw -Q instead of zile.


Thanks for the tip, I found out that:

1. on the command-line, zile actually works as core editor, but
2. not from within Emacs (Magit) where I tried it

 emacs -nw -Q is a nice tip, but I think what I really would like to
 have it that, when I use GNU Emacs Magit and enter a git command 

,-
| Run git like this: command
`-

that calls an editor (e.g. commit --amend), the running Emacs instance
is (re)used and a new buffer is opened for editing (instead of starting
another Emacs instance).

-- 
cheers,
Thorsten

--
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] clean: confirm before cleaning files and directories

Jiang Xin worldhello@gmail.com writes:

 I don't know how many programmers had been bitten by runing `git clean -fdx`,
 but I bet there were some. I think safety should be put to the 1st place.

git clean without -n/f errors out, hinting the availablilty of -n
while mentioning -f; that is the safety, isn't it?  Once the user
decides to give -f, the user _wants_ to remove cruft, and it is a
hinderance to require any further confirmation.

Your problem description sounds like that you want to drive without
wearing seatbelts but in case you get in a collision, you suggest to
make the seat automatically stick to the back of anybody who sits on
it with superglue to make it safer.

That approach might give it an alternative safety, but it would make
it extremely annoying if you apply it also to people who do wear
belts, no?

This extra confirmation should never be the default.
--
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] clean: confirm before cleaning files and directories

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

 git clean without -n/f errors out, hinting the availablilty of -n
 while mentioning -f; that is the safety, isn't it?  Once the user
 decides to give -f, the user _wants_ to remove cruft, and it is a
 hinderance to require any further confirmation.

This is only half true: because git clean does nothing without -f,
people's fingers get trained to type git clean -f without really
thinking about it. Just like people alias rm='rm -i' and then type
rm -fr * mechanically.

The nice thing with the confirmation dialog is that it shows the list
before asking (and unlike 'rm -i', it asks only once).

But as I said in another thread, I fully agree that adding the
confirmation by default even with -f is nonsense.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] t9501: Do not use export X=Y

Torsten Bögershausen tbo...@web.de writes:

 On 2013-04-25 22.46, Junio C Hamano wrote:
 Torsten Bögershausen tbo...@web.de writes:
 
 Spilt lines like export X=Y into 2 lines:
 X=Y
 export X
 
 That can be read from the patch text.
 
 If you are going to spend three lines, please describe why it has to
 be split; that would help educate developers new to the codebase.
 
 So true,
 writing good commit messages is not easy.
 and this was a good example for a bad example

 Side questions:
 Which shells of which OS/distribution do not understand export X=Y?

I have not met one for quite some time myself. cf.

http://thread.gmane.org/gmane.comp.version-control.git/35543/focus=35551
--
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 00/20] remote-bzr: massive changes

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

 On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:

 I forgot to mention; these apply on top of the previous 'fixes and cleanups'.

Then I should probably wait for v2 6/9 of that series is rerolled.

There could be ones that you may want to reroll other than 6/9 in
that, I didn't have time to look at the backlog. I'll be whipping
the -rc0 into shape today and it is unlikely I'll have time to look
at this or the previous one today.

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: Zile as git core editor?

Thorsten Jolitz tjol...@gmail.com writes:

  ... I think what I really would like to
  have it that, when I use GNU Emacs Magit and enter a git command 

 ,-
 | Run git like this: command
 `-

 that calls an editor (e.g. commit --amend), the running Emacs instance
 is (re)used and a new buffer is opened for editing (instead of starting
 another Emacs instance).

Hmph, isn't that what emacsclient is for?  I have these

(setenv PAGER cat)
(setenv EDITOR emacsclient)
(server-start)

somewhere in my ~/.emacs to make commands in M-x compile behave.
--
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] clean: confirm before cleaning files and directories

Matthieu Moy matthieu@grenoble-inp.fr writes:

 The nice thing with the confirmation dialog is that it shows the list
 before asking (and unlike 'rm -i', it asks only once).

I wouldn't object to having clean -i, which automatically defeats
the requireforce option.

As to a huge single list you have to approve or reject as a whole, I
am on the fence.  When running rm -i, I often wished to see
something like that, but I am fairly sure that I'll call it unusable
the first time I see a list with a few items I want to keep while
removing all others.

--
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: Possible bug report

Pierre-François CLEMENT lik...@gmail.com writes:

 As you can see, the --cumulative lines seem to be duplicated, though
 the computed stats aren't exactly the same... It appears when you
 combine the --cumulative option with either --stat, --numstat or
 --shortstat (but not --dirstat) ...

Thanks for a report.

I do not think the deprecated --cumulative command line option was
ever designed to be used with anything but --dirstat.

It was a UI mistake to make it look like an independent option,
which was corrected with 333f3fb0c530 (Refactor --dirstat parsing;
deprecate --cumulative and --dirstat-by-file, 2011-04-29) and the
fix shipped back in v1.7.6. Since that release we do not even
mention the option in the manual.

These days, the right way to spell it is as an option parameter to
the --dirstat option itself (e.g. --dirstat=cumulative).

The parser to parse --cumulative as a command line argument was kept
so that people who were used to --dirstat --cumulative do not have
to see an error from the command line parser.  We could have made
--cumulative with other kind of stat an error back then, but we
didn't. I suspect that we thought it would be sufficient to not
document --cumulative as a standalone option, but I do not recall
the details.
--
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 parallelism question

2013-04-26 Thread Linus Torvalds

Since I reboot fairly regularly to test new kernels, I don't *always*
have the kernel source tree in my caches, so I still care about some
cold-cache performance. And git grep tends to be the most noticeable
one.

Now, I have a SSD, and even the cold-cache case takes just five
seconds or so, but that's still somethng I react to, since the normal
kernel tree in cache case ends up bring close enough to
instantaneous (half a second) that then when it takes longer I react
to it.

And I started thinking about it, and our git grep parallelism seems
to be limited to 8.

Which is fine most of the time for CPU parallelism (although maybe
some people with big machines would prefer higher numbers), but for IO
parallelism I thought that maybe we'd like a higher number...

So I tried it out, and with THREADS set to 32, I get a roughly 15%
performance boost for the cold-cache case (the error bar is high
enough to not give a very precise number, but I see it going from
~4.8-4.9s on my machine down to 4.2..4.6s).

That's on an SSD, though - the performance implications might be very
different for other use cases (NFS would likely prefer higher IO
parallelism and might show bigger improvement, while a rotational disk
might end up just thrashing more)

Is this a big deal? Probably not. But I did react to how annoying it
was to set the parallelism factor (recompile git with a new number).
Wouldn't it be lovely if it was slightly smarter (something more akin
to the index preloading that takes number of files into account) or at
least allowed people to set the parallelism explicitly with a command
line switch?

Right now it disables the parallel grep entirely for UP, for example.
Which makes perfect sense if grep is all about CPU use. But even UP
might improve from parallel IO..

  Linus
--
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: Itches with the current rev spec

Johannes Sixt j.s...@viscovery.net writes:

 Allow alternative spelling of

git rebase -i master topic

 like this:

git rebase -i master..topic

 (as always, the default for topic is HEAD).

I actually made this typo a few times in the past.

In a single-strand-of-pearls history, what rebase operates on is
clearly a _range_ with a defined linear order of commits, and
master..topic is a natural way to express it.

And rebase not just needs the range that defines the set of commits
to be replayed, but also needs the commit on top of which they are
replayed.  It is natural to take ^master as that commit, and it is
useful when you are trying to catch up with that branch.  

The reason you would use rebase -i is not for catching up [*1*],
so defaulting to replay onto ^master is not useful.  You want the
command to replay on top of the stable same base, so that you can
compare the result with the previous version in order to verify.
Often, the fork-point with master is a good choice for that.

It is tempting to say that rebase -i and normal catch-up rebase
(e.g. pull --rebase) should have designed to behave differently.
git rebase -i master perhaps should have made to rebase the
current work on top of the fork-point from master, not on top of it,
and require an explict --onto master if the user does want to also
catch up.

But the above is orthogonal to the syntax ../... issue.


[Footnote]

*1* rebase and rebase -i already behave slightly differently
with respect to $onto in that a catch-up rebase that is already up
to date notices the situation and turns into a no-op, but it does
not turn rebase -i into a no-op for this exact reason.

--
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] t/Makefile: remove smoke test targets

2013-04-26 Thread John Keeping

Commit d24fbca (Remove Git's support for smoke testing - 2011-12-23)
removed the smoke test support from the test suite but it was re-added
by commit 342e9ef (Introduce a performance testing framework -
2012-02-17).  This appears to be the result of a mis-merge, since
re-adding the smoke testing infrastructure does not relate to the
subject of that commit.

The current 'smoke' target is broken since the 'harness' script it
uses no longer exists, so just reapply this section of commit d24fbca
and remove all of the smoke testing section in the makefile.

Signed-off-by: John Keeping j...@keeping.me.uk
---
 t/Makefile | 38 --
 1 file changed, 38 deletions(-)

diff --git a/t/Makefile b/t/Makefile
index 1923cc1..44ca7d3 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -83,42 +83,4 @@ valgrind:
 perf:
$(MAKE) -C perf/ all
 
-# Smoke testing targets
--include ../GIT-VERSION-FILE
-uname_S := $(shell sh -c 'uname -s 2/dev/null || echo unknown')
-uname_M := $(shell sh -c 'uname -m 2/dev/null || echo unknown')
-
-test-results:
-   mkdir -p test-results
-
-test-results/git-smoke.tar.gz: test-results
-   '$(PERL_PATH_SQ)' ./harness \
-   --archive=test-results/git-smoke.tar.gz \
-   $(T)
-
-smoke: test-results/git-smoke.tar.gz
-
-SMOKE_UPLOAD_FLAGS =
-ifdef SMOKE_USERNAME
-   SMOKE_UPLOAD_FLAGS += -F username=$(SMOKE_USERNAME) -F 
password=$(SMOKE_PASSWORD)
-endif
-ifdef SMOKE_COMMENT
-   SMOKE_UPLOAD_FLAGS += -F comments=$(SMOKE_COMMENT)
-endif
-ifdef SMOKE_TAGS
-   SMOKE_UPLOAD_FLAGS += -F tags=$(SMOKE_TAGS)
-endif
-
-smoke_report: smoke
-   curl \
-   -H Expect:  \
-   -F project=Git \
-   -F architecture=$(uname_M) \
-   -F platform=$(uname_S) \
-   -F revision=$(GIT_VERSION) \
-   -F report_file=@test-results/git-smoke.tar.gz \
-   $(SMOKE_UPLOAD_FLAGS) \
-   http://smoke.git.nix.is/app/projects/process_add_report/1 \
-   | grep -v ^Redirecting
-
 .PHONY: pre-clean $(T) aggregate-results clean valgrind perf
-- 
1.8.2.1.715.gb260f47

--
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: Zile as git core editor?

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

 Thorsten Jolitz tjol...@gmail.com writes:

  ... I think what I really would like to
  have it that, when I use GNU Emacs Magit and enter a git command 

 ,-
 | Run git like this: command
 `-

 that calls an editor (e.g. commit --amend), the running Emacs instance
 is (re)used and a new buffer is opened for editing (instead of starting
 another Emacs instance).

 Hmph, isn't that what emacsclient is for?  I have these

   (setenv PAGER cat)
   (setenv EDITOR emacsclient)
   (server-start)

 somewhere in my ~/.emacs to make commands in M-x compile behave.

I was a big fan of emacsclient and used it quite some time - but finally
those frequent Emacs crashes caused by it were just unbearable, so I
went back to 'normal' use of Emacs.

But maybe you are right - I should run a second Emacs instance as server
only used to popup emacsclient buffers on demand, while doing all the
serious stuff in a non-server instance of Emacs. 

-- 
cheers,
Thorsten

--
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] t5801: properly test the test shell