Thomas Rast wrote: > I'm indifferent about this. It does save a process, but (maybe that's > just me though) I had to look up a POSIX manpage to verify that the > repeating behaviour is guaranteed. If saving a process is the only benefit, let's forget it. >> While at it, add a missing && to the "git checkout -p HEAD with change >> already staged" test. > > Good catch. Here's a patch with just that. -- 8< -- Subject: t2016 (checkout -p): add missing && Although the set_state command is not likely to fail, it is best to stay in the habit of checking for failures. Cc: Thomas Rast <trast@xxxxxxxxxxxxxxx> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> --- t/t2016-checkout-patch.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/t/t2016-checkout-patch.sh b/t/t2016-checkout-patch.sh index 7657ec1..a463b13 100755 --- a/t/t2016-checkout-patch.sh +++ b/t/t2016-checkout-patch.sh @@ -52,7 +52,7 @@ test_expect_success PERL 'git checkout -p HEAD with NO staged changes: apply' ' ' test_expect_success PERL 'git checkout -p HEAD with change already staged' ' - set_state dir/foo index index + set_state dir/foo index index && # the third n is to get out in case it mistakenly does not apply (echo n; echo y; echo n) | git checkout -p HEAD && verify_saved_state bar && -- 1.7.2.3 -- 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