Re: t9902 fails

2013-01-17 Thread Junio C Hamano
Jonathan Nieder  writes:

> Thoughts?  Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?

Yeah, it would be a robust alternative approach to verify that (1)
output is a superset of what we expect, and (2) they all share the
string we fed to the machinery as the common prefix, I would 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: t9902 fails

2013-01-18 Thread Junio C Hamano
Jonathan Nieder  writes:

> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH.  I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts?

How about doing something like this and set that variable in the
test instead?  If STD_ONLY is not set, you will get everything, but
when STD_ONLY is set, we will stop reading from "help -a" when it
starts listing additional stuff.

 contrib/completion/git-completion.bash | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index a4c48e1..415a078 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -534,7 +534,8 @@ __git_complete_strategy ()
 __git_list_all_commands ()
 {
local i IFS=" "$'\n'
-   for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
+   for i in $(LANG=C LC_ALL=C git help -a |
+  sed -n ${GIT_HELP_STD_ONLY+-e /^git.*elsewhere/q} -e '/^  
[a-zA-Z0-9]/p')
do
case $i in
*--*) : helper pattern;;
--
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: t9902 fails

2013-01-18 Thread Junio C Hamano
Junio C Hamano  writes:

> How about doing something like this and set that variable in the
> test instead?  If STD_ONLY is not set, you will get everything, but
> when STD_ONLY is set, we will stop reading from "help -a" when it
> starts listing additional stuff.
>
>  contrib/completion/git-completion.bash | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index a4c48e1..415a078 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -534,7 +534,8 @@ __git_complete_strategy ()
>  __git_list_all_commands ()
>  {
>   local i IFS=" "$'\n'
> - for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
> + for i in $(LANG=C LC_ALL=C git help -a |
> +sed -n ${GIT_HELP_STD_ONLY+-e /^git.*elsewhere/q} -e '/^  
> [a-zA-Z0-9]/p')
>   do
>   case $i in
>   *--*) : helper pattern;;

Alternatively, we could do this and replace everything inside $()
with "git help --standard", but that requires the completion script
update to go in sync with the core update, which is a downside.

 builtin/help.c | 21 +
 help.c |  3 +++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/builtin/help.c b/builtin/help.c
index bd86253..e6b9b5f 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -36,11 +36,16 @@ enum help_format {
 
 static const char *html_path;
 
-static int show_all = 0;
+#define HELP_ALL 1
+#define HELP_STANDARD 2
+static int show_what;
 static unsigned int colopts;
 static enum help_format help_format = HELP_FORMAT_NONE;
 static struct option builtin_help_options[] = {
-   OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+   OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+   HELP_ALL),
+   OPT_SET_INT(0, "standard", &show_what, N_("list subcommands that comes 
with git"),
+   HELP_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), 
HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -436,19 +441,27 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
int nongit;
const char *alias;
enum help_format parsed_help_format;
-   load_command_list("git-", &main_cmds, &other_cmds);
 
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
parsed_help_format = help_format;
 
-   if (show_all) {
+   load_command_list("git-", &main_cmds,
+ show_what == HELP_STANDARD ? NULL : &other_cmds);
+
+   if (show_what == HELP_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
}
+   if (show_what == HELP_STANDARD) {
+   int i;
+   for (i = 0; i < main_cmds.cnt; i++)
+   printf("%s\n", main_cmds.names[i]->name);
+   return 0;
+   }
 
if (!argv[0]) {
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
diff --git a/help.c b/help.c
index 2a42ec6..3e6b04c 100644
--- a/help.c
+++ b/help.c
@@ -182,6 +182,9 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
 
+   if (!other_cmds)
+   return;
+
if (env_path) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
--
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: t9902 fails

2013-01-18 Thread Jean-Noël AVILA
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> Junio C Hamano  writes:
> > How about doing something like this and set that variable in the
> > test instead?  If STD_ONLY is not set, you will get everything, but
> > when STD_ONLY is set, we will stop reading from "help -a" when it
> > starts listing additional stuff.

I tried both of your propositions but none made test 10 of t9902 pass.

Am I supposed to run "make install" before running the test?

--
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: t9902 fails

2013-01-18 Thread Junio C Hamano
"Jean-Noël AVILA"  writes:

> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano  writes:
>> > How about doing something like this and set that variable in the
>> > test instead?  If STD_ONLY is not set, you will get everything, but
>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>> > starts listing additional stuff.
>
> I tried both of your propositions but none made test 10 of t9902 pass.

Do you have a leftover git-check-ignore or something from a previous
build that is *not* known to "git" you just built?

Neither will help in such a case.  The test pretty much runs with
GIT_EXEC_PATH set to the build area, and we do want to be able to
test what we have in the build area before we decide to install
them, so that is nothing new.


--
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: t9902 fails

2013-01-18 Thread Junio C Hamano
Junio C Hamano  writes:

> "Jean-Noël AVILA"  writes:
>
>> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>>> Junio C Hamano  writes:
>>> > How about doing something like this and set that variable in the
>>> > test instead?  If STD_ONLY is not set, you will get everything, but
>>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>>> > starts listing additional stuff.
>>
>> I tried both of your propositions but none made test 10 of t9902 pass.
>
> Do you have a leftover git-check-ignore or something from a previous
> build that is *not* known to "git" you just built?

"... in the build directory" was missing from the sentence.  Sorry
about noise.

> Neither will help in such a case.  The test pretty much runs with
> GIT_EXEC_PATH set to the build area, and we do want to be able to
> test what we have in the build area before we decide to install
> them, so that is nothing new.
--
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: t9902 fails

2013-01-18 Thread Torsten Bögershausen
On 18.01.13 23:23, Jean-Noël AVILA wrote:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano  writes:
>>> How about doing something like this and set that variable in the
>>> test instead?  If STD_ONLY is not set, you will get everything, but
>>> when STD_ONLY is set, we will stop reading from "help -a" when it
>>> starts listing additional stuff.
> 
> I tried both of your propositions but none made test 10 of t9902 pass.
> 
> Am I supposed to run "make install" before running the test?

No. The test suite could (and should) be run before you make install.
So a typical sequence could be:
Run test suite, and if that passes, install the binaries on my system.
This could look like this on the command line:
make test && sudo make install

Jean-Noël,
would it be possible to run
"git status"
and share the result with us?

And did you try Jonathans patch?

/Torsten


--
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* t9902 fails

2013-01-18 Thread Junio C Hamano
Torsten Bögershausen  writes:

> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?

It may hide the immediate issue, but I am afraid Jonathan's patch
does not fix anything fundamental.  If you do this:

git checkout next
make
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh

then the completion machinery will see the leftover git-check-ignore
at the top of the working tree (which is the $GIT_EXEC_PATH) and the
test that expects "check" to expand only to "checkout" will fail,
because 'master' does not have exclusion definition for check-ignore,
even though it knows check-attr, check-ref-format and checkout-index
are to be excluded as "plumbing".

So if you come up with a brilliant idea to add "git cherry-pack"
command and did this:

git checkout -b tb/cherry-pack
edit Makefile builtin/cherry-pack.c builtin.h git.c ...
git add builtin/cherry-pack.c
make test
git commit -a -m "cherry-pack: new command"
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh

the test will break exactly the same way.

If we really wanted to exclude random build artifacts that the
current checkout did not build, you have to do one of these things:

 (1) at the beginning of t9902, "rm -fr" a temporary location,
 install the built product with a custom DESTDIR set to that
 temporary location that we now know is empty, and point
 GIT_EXEC_PATH to the libexec/git-core directory in that
 temporary location, so that "git help -a" run in the completion
 script will find _only_ the executable we would install; or

 (2) instead of being inclusive, collecting all executable in
 GIT_EXEC_PATH that happens to be named "git-", add a mode to
 "git help" that lists those that we know to be standard
 commands that the users may want to complete from the command
 line.

An outline to do (2) would look like this patch, but I didn't check
other consumers of command-list.txt, so this may be breaking them in
unplanned ways.

 builtin/help.c | 35 ++---
 command-list.txt   |  4 +--
 contrib/completion/git-completion.bash | 14 +-
 generate-cmdlist.sh| 13 +-
 help.c | 47 --
 help.h |  1 +
 6 files changed, 75 insertions(+), 39 deletions(-)

diff --git a/builtin/help.c b/builtin/help.c
index bd86253..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
 #include "cache.h"
 #include "builtin.h"
 #include "exec_cmd.h"
-#include "common-cmds.h"
 #include "parse-options.h"
 #include "run-command.h"
 #include "column.h"
@@ -36,11 +35,16 @@ enum help_format {
 
 static const char *html_path;
 
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_STANDARD 2
+static int show_what;
 static unsigned int colopts;
 static enum help_format help_format = HELP_FORMAT_NONE;
 static struct option builtin_help_options[] = {
-   OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+   OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+   HELP_SHOW_ALL),
+   OPT_SET_INT(0, "standard", &show_what, N_("print all available 
commands"),
+   HELP_SHOW_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), 
HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -287,23 +291,6 @@ static int git_help_config(const char *var, const char 
*value, void *cb)
 
 static struct cmdnames main_cmds, other_cmds;
 
-void list_common_cmds_help(void)
-{
-   int i, longest = 0;
-
-   for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
-   if (longest < strlen(common_cmds[i].name))
-   longest = strlen(common_cmds[i].name);
-   }
-
-   puts(_("The most commonly used git commands are:"));
-   for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
-   printf("   %s   ", common_cmds[i].name);
-   mput_char(' ', longest - strlen(common_cmds[i].name));
-   puts(_(common_cmds[i].help));
-   }
-}
-
 static int is_git_command(const char *s)
 {
return is_in_cmdlist(&main_cmds, s) ||
@@ -442,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char 
*prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
 
-   if (show_all) {
+   if (show_what == HELP_SHOW_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));

Re: t9902 fails

2013-01-19 Thread Jean-Noël AVILA
Le samedi 19 janvier 2013 06:38:54, Torsten Bögershausen a écrit :
> On 18.01.13 23:23, Jean-Noël AVILA wrote:
> > Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> >> Junio C Hamano  writes:
> >>> How about doing something like this and set that variable in the
> >>> test instead?  If STD_ONLY is not set, you will get everything, but
> >>> when STD_ONLY is set, we will stop reading from "help -a" when it
> >>> starts listing additional stuff.
> > 
> > I tried both of your propositions but none made test 10 of t9902 pass.
> > 
> > Am I supposed to run "make install" before running the test?
> 
> No. The test suite could (and should) be run before you make install.
> So a typical sequence could be:
> Run test suite, and if that passes, install the binaries on my system.
> This could look like this on the command line:
> make test && sudo make install
> 
> Jean-Noël,
> would it be possible to run
> "git status"
> and share the result with us?
> 
> And did you try Jonathans patch?
> 
> /Torsten


Hi all,

My workdir is clean. 


jnavila@cayenne git (master)]$ make
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: « GIT-VERSION-FILE » est à jour.
GEN git-instaweb
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Rien à faire pour « all ».
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
[jnavila@cayenne git (master)]$ git branch -vv
  attr_pattern   3cb6a4c Add directory pattern matching to attributes
  fix_test_t9902 02f55e6 Merge git://bogomips.org/git-svn
  maint  611fa18 Add directory pattern matching to attributes
* master 02f55e6 [origin/master] Merge git://bogomips.org/git-svn
  next   82c5000 [origin/next: ahead 157, behind 550] Merge branch 
'jc/doc-diff-blobs' into next
  pu 25f269c [origin/pu: ahead 68, behind 137] Merge branch 
'mp/diff-algo-config' into pu
  todo   70e0e3e [origin/todo: behind 1] What's cooking (2013/01 #06)
[jnavila@cayenne git (master)]$ git status
# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   gitk-git/gitk-wish
nothing added to commit but untracked files present (use "git add" to track)
[jnavila@cayenne git (master)]$ ls -l | grep git-check
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-attr
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout-index
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-ref-format


If I move git-checkout-branches out of /usr/bin, the test passes. So somehow 
GIT_EXEC_PATH is not what is expected.


--
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: Re* t9902 fails

2013-01-19 Thread Jean-Noël AVILA
Le samedi 19 janvier 2013 08:52:25, Junio C Hamano a écrit :
>  (2) instead of being inclusive, collecting all executable in
>  GIT_EXEC_PATH that happens to be named "git-", add a mode to
>  "git help" that lists those that we know to be standard
>  commands that the users may want to complete from the command
>  line.

Am I wrong when I say that "git help -a" already provides the difference 
between core git commands and other commands available through path?

If we use this, then we can instruct git-completion that we are in test mode 
and that it should not provide additional completions.

---
 contrib/completion/git-completion.bash | 13 +++--
 t/t9902-completion.sh  |  2 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
completion.bash
index 14dd5e7..dc0ea5b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -23,6 +23,8 @@
 #3) Consider changing your PS1 to also show the current branch,
 #   see git-prompt.sh for details.
 
+__testing_git=$1
+
 case "$COMP_WORDBREAKS" in
 *:*) : great ;;
 *)   COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -533,8 +535,15 @@ __git_complete_strategy ()
 
 __git_list_all_commands ()
 {
-   local i IFS=" "$'\n'
-   for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
+   local i cmdlist IFS=" "$'\n'
+
+   if [ "x$__testing_git" != "xTEST" ]; then
+   cmdlist=$(git help -a|egrep '^  [a-zA-Z0-9]')
+   else
+   cmdlist=$(git help -a| egrep -m 1 -B1000 PATH | egrep '^  
[a-zA-Z0-9]')
+   fi
+
+   for i in $cmdlist
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
 }
 
-. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash"
+. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" TEST
 
 # We don't need this function to actually join words or do anything special.
 # Also, it's cleaner to avoid touching bash's internal completion variables.
-- 
1.8.1.1.271.g02f55e6

--
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: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)

2013-01-15 Thread Torsten Bögershausen

On 01/16/2013 12:24 AM, Jeff King wrote:

On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:


"Jean-Noël AVILA"  writes:


Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known
issue?


Which branch?


t9902.10 is overly sensitive to extra git commands in your PATH, as well
as cruft in your build dir (especially if you have been building 'pu',
which has git-check-ignore). Try "make clean&&  make test".

-Peff

This may help, or it may not.

If there are other binaries like
"git-check-email" or "git-check-ignore" in the PATH
.

When you switch to a branch generating a file like
git-check-ignore then "make clean" will know about it
and will remove it.
If you switch to master, then "make clean" will not remove it.

What does "git status" say?

We had a discussion about this some weeks ago, but never concluded.

How about this:
http://comments.gmane.org/gmane.comp.version-control.git/211907
--
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: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)

2013-01-17 Thread Jean-Noël AVILA
Le mercredi 16 janvier 2013 07:15:51, Torsten Bögershausen a écrit :
> On 01/16/2013 12:24 AM, Jeff King wrote:
> > On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
> >> "Jean-Noël AVILA"  writes:
> >>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a
> >>> known issue?
> >> 
> >> Which branch?
> > 
> > t9902.10 is overly sensitive to extra git commands in your PATH, as well
> > as cruft in your build dir (especially if you have been building 'pu',
> > which has git-check-ignore). Try "make clean&&  make test".
> > 
> > -Peff
> 
> This may help, or it may not.
> 
> If there are other binaries like
> "git-check-email" or "git-check-ignore" in the PATH
> .
> 
> When you switch to a branch generating a file like
> git-check-ignore then "make clean" will know about it
> and will remove it.
> If you switch to master, then "make clean" will not remove it.
> 
> What does "git status" say?
> 
> We had a discussion about this some weeks ago, but never concluded.
> 
> How about this:
> http://comments.gmane.org/gmane.comp.version-control.git/211907

OK. I have installed practically everything related to git from the package 
manager and there is a git-checkout-branches utility available.

That result defeats the purpose of the test. This needs a tighter environment 
to work whatever the configuration of the user may be.
--
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: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)

2013-01-17 Thread Jonathan Nieder
Jean-Noël AVILA wrote:

> OK. I have installed practically everything related to git from the package 
> manager and there is a git-checkout-branches utility available.
>
> That result defeats the purpose of the test. This needs a tighter environment 
> to work whatever the configuration of the user may be.

Presumably 'git checkout-branches' is from git-stuff.

Here's a patch to make the tested command a little less likely to
conflict with commands from the user's $PATH.  I'm not thrilled with
it because the contents of $PATH are still not tightly controlled, and
this does nothing to avoid problems due to existence of, for example,
a "git cherry-pick-branches" command.

Thoughts?  Maybe it would be enough to check that the intended get
commands are present in the completion list and other git commands are
not, ignoring binaries that might live elsewhere on the $PATH?

Signed-off-by: Jonathan Nieder 
---
 t/t9902-completion.sh | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..06dcfb2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -192,19 +192,19 @@ test_expect_success 'general options' '
 '
 
 test_expect_success 'general options plus command' '
-   test_completion "git --version check" "checkout " &&
-   test_completion "git --paginate check" "checkout " &&
-   test_completion "git --git-dir=foo check" "checkout " &&
-   test_completion "git --bare check" "checkout " &&
-   test_completion "git --help des" "describe " &&
-   test_completion "git --exec-path=foo check" "checkout " &&
-   test_completion "git --html-path check" "checkout " &&
-   test_completion "git --no-pager check" "checkout " &&
-   test_completion "git --work-tree=foo check" "checkout " &&
-   test_completion "git --namespace=foo check" "checkout " &&
-   test_completion "git --paginate check" "checkout " &&
-   test_completion "git --info-path check" "checkout " &&
-   test_completion "git --no-replace-objects check" "checkout "
+   test_completion "git --version cherry-p" "cherry-pick " &&
+   test_completion "git --paginate cherry-p" "cherry-pick " &&
+   test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
+   test_completion "git --bare cherry-p" "cherry-pick " &&
+   test_completion "git --help cherry-p" "cherry-pick " &&
+   test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
+   test_completion "git --html-path cherry-p" "cherry-pick " &&
+   test_completion "git --no-pager cherry-p" "cherry-pick " &&
+   test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
+   test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
+   test_completion "git --paginate cherry-p" "cherry-pick " &&
+   test_completion "git --info-path cherry-p" "cherry-pick " &&
+   test_completion "git --no-replace-objects cherry-p" "cherry-pick "
 '
 
 test_expect_success 'setup for ref completion' '
-- 
1.8.1

--
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: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)

2013-01-17 Thread Torsten Bögershausen
On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package 
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter 
>> environment 
>> to work whatever the configuration of the user may be.
> Presumably 'git checkout-branches' is from git-stuff.
>
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH.  I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts?  Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
>
> Signed-off-by: Jonathan Nieder 
> ---
>  t/t9902-completion.sh | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..06dcfb2 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -192,19 +192,19 @@ test_expect_success 'general options' '
>  '
>  
>  test_expect_success 'general options plus command' '
> - test_completion "git --version check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --git-dir=foo check" "checkout " &&
> - test_completion "git --bare check" "checkout " &&
> - test_completion "git --help des" "describe " &&
> - test_completion "git --exec-path=foo check" "checkout " &&
> - test_completion "git --html-path check" "checkout " &&
> - test_completion "git --no-pager check" "checkout " &&
> - test_completion "git --work-tree=foo check" "checkout " &&
> - test_completion "git --namespace=foo check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --info-path check" "checkout " &&
> - test_completion "git --no-replace-objects check" "checkout "
> + test_completion "git --version cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
> + test_completion "git --bare cherry-p" "cherry-pick " &&
> + test_completion "git --help cherry-p" "cherry-pick " &&
> + test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
> + test_completion "git --html-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-pager cherry-p" "cherry-pick " &&
> + test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
> + test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --info-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-replace-objects cherry-p" "cherry-pick "
>  '
>  
>  test_expect_success 'setup for ref completion' '
That looks good to me, 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