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 gits...@pobox.com writes:
How about doing something like this and set that variable in the
test
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
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano gits...@pobox.com 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.
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com 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
Jean-Noël AVILA avila...@gmail.com writes:
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Jean-Noël AVILA avila...@gmail.com writes:
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com writes:
How about doing something like this and set that variable in the
test instead? If STD_ONLY is not
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 gits...@pobox.com 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
Torsten Bögershausen tbo...@web.de 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
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
Jonathan Nieder jrnie...@gmail.com 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
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
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 AVILAavila...@gmail.com 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
13 matches
Mail list logo
