t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
http://thread.gmane.org/gmane.comp.version-control.git/208085
It's not unthinkable that in the future other tests could break for
similar reasons. Therefore it would be good to sanitize $PATH in the
test framework so that it cannot destabilize tests, although I am
struggling to think of a good way of doing this. Naively stripping
directories under $HOME would not protect against git "plugins" such
as the above being installed into places like /usr/bin. Thoughts?
On Mon, Dec 17, 2012 at 01:05:38AM +0000, Adam Spiers wrote:
t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
http://thread.gmane.org/gmane.comp.version-control.git/208085
It's not unthinkable that in the future other tests could break for
similar reasons. Therefore it would be good to sanitize $PATH in the
test framework so that it cannot destabilize tests, although I am
struggling to think of a good way of doing this. Naively stripping
directories under $HOME would not protect against git "plugins" such
as the above being installed into places like /usr/bin. Thoughts?
I've run into this, too. I think sanitizing $PATH is the wrong approach.
The real problem is that the test is overly picky. Right now it is
failing because you happen to have "check-email" in your $PATH, but it
will also need to be adjusted when a true "check-email" command is added
to git.
I can think of two other options:
1. Make the test input more specific (e.g., looking for "checkou").
This doesn't eliminate the problem, but makes it less likely
to occur.
2. Loosen the test to look for the presence of "checkout", but not
fail when other items are present. Bonus points if it makes sure
that everything returned starts with "check".
I think (2) is the ideal solution in terms of behavior, but writing it
may be more of a pain.
-Peff
On Thu, Dec 20, 2012 at 2:55 PM, Jeff King [off-list ref] wrote:
On Mon, Dec 17, 2012 at 01:05:38AM +0000, Adam Spiers wrote:
quoted
t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
http://thread.gmane.org/gmane.comp.version-control.git/208085
It's not unthinkable that in the future other tests could break for
similar reasons. Therefore it would be good to sanitize $PATH in the
test framework so that it cannot destabilize tests, although I am
struggling to think of a good way of doing this. Naively stripping
directories under $HOME would not protect against git "plugins" such
as the above being installed into places like /usr/bin. Thoughts?
I've run into this, too. I think sanitizing $PATH is the wrong approach.
The real problem is that the test is overly picky. Right now it is
failing because you happen to have "check-email" in your $PATH, but it
will also need to be adjusted when a true "check-email" command is added
to git.
I can think of two other options:
1. Make the test input more specific (e.g., looking for "checkou").
This doesn't eliminate the problem, but makes it less likely
to occur.
2. Loosen the test to look for the presence of "checkout", but not
fail when other items are present. Bonus points if it makes sure
that everything returned starts with "check".
I think (2) is the ideal solution in terms of behavior, but writing it
may be more of a pain.
I agree with all your points. Thanks for the suggestions.
On 20.12.12 16:13, Adam Spiers wrote:
On Thu, Dec 20, 2012 at 2:55 PM, Jeff King [off-list ref] wrote:
quoted
On Mon, Dec 17, 2012 at 01:05:38AM +0000, Adam Spiers wrote:
quoted
t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
http://thread.gmane.org/gmane.comp.version-control.git/208085
It's not unthinkable that in the future other tests could break for
similar reasons. Therefore it would be good to sanitize $PATH in the
test framework so that it cannot destabilize tests, although I am
struggling to think of a good way of doing this. Naively stripping
directories under $HOME would not protect against git "plugins" such
as the above being installed into places like /usr/bin. Thoughts?
I've run into this, too. I think sanitizing $PATH is the wrong approach.
The real problem is that the test is overly picky. Right now it is
failing because you happen to have "check-email" in your $PATH, but it
will also need to be adjusted when a true "check-email" command is added
to git.
I can think of two other options:
1. Make the test input more specific (e.g., looking for "checkou").
This doesn't eliminate the problem, but makes it less likely
to occur.
2. Loosen the test to look for the presence of "checkout", but not
fail when other items are present. Bonus points if it makes sure
that everything returned starts with "check".
I think (2) is the ideal solution in terms of behavior, but writing it
may be more of a pain.
I agree with all your points. Thanks for the suggestions.
I volonteer for 1) (and we got for 2) later)