On Mon, Jan 21, 2013 at 03:32:29PM -0800, Junio C Hamano wrote: > "Jean-Noël AVILA" <jn.avila@xxxxxxx> writes: > > > At least, "it works for me". > > I suspect that your approach will still not fix the case in which > you build a branch with a new command git-check-ignore, and then > check out another branch that does not yet have that command without > first running "make clean". > > Does the following really pass with your patch? > > git checkout origin/next > make > git checkout origin/maint > git apply your_patch.mbox > make > cd t && sh ./t9902-completion.sh I really hate to suggest this, but should it be more like: if test -z "$FAKE_COMMAND_LIST"; then __git_cmdlist() { git help -a | egrep '^ [a-zA-Z0-9]' } else __git_cmdlist() { printf '%s' "$FAKE_COMMAND_LIST" } fi That gives us a nice predictable starting point for actually testing the completion code. The downside is that it doesn't let us test that we remain compatible with the output of "help -a". But we could potentially add a single, more liberal test (without $FAKE_COMMAND_LIST, but ready to expect extra output) that checks that. > > + __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^ [a-zA-Z0-9]'; } > > 'egrep' is not even in POSIX in the first place but grep -E ought to > be a replacement for it, so I'll let it pass, but "-m1 -B1000"? > Please stay within portable options. If I recall correctly, egrep is actually more portable than "grep -E" (and it is already in use, so I think we are OK). I agree on the rest, though. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html