Hi Phillip,

On Sat, 7 Jun 2025 at 11:45, Phillip Wood [off-list ref] wrote:

Range-diff against v2:

     +test_expect_success 'stash -p <pathspec> stash and restores the file' '
    -+  cat file >expect-file &&
    -+  echo changed-file >file &&
    ++  test_write_lines b c >file &&
    ++  git commit -m "add a few lines" file &&
    ++  test_write_lines a b c d >file &&
    ++  test_write_lines b c d >expect-file &&
     +  echo changed-other-file >other-file &&
    -+  echo a | git stash -p file &&
    ++  test_write_lines s y n | git stash -p file &&
     +  test_cmp expect-file file &&
     +  echo changed-other-file >expect &&
     +  test_cmp expect other-file &&

This range-diff matches what I'd expect. Now this test makes sure we
really pick up the `-p`. On that note ... I just realized that all of
these would keep the test passing:

 test_write_lines s y n | git stash -p file # what you have
 test_write_lines s y n | git stash -p file otherfile
 test_write_lines s y n | git stash -p .
 test_write_lines s y n | git stash -p

So the implementation under test could bungle the pathspec, query the
user for both `file` and `otherfile` (in that order!), get EOF from
stdin while handling `otherfile`, leave it out of the stash, and end up
passing the test. We could try to protect against this by providing
another "y": if git wants to read something after our "s y n" sequence,
we'll give it a "y" in the hopes that it will trip things up. We do want
to test the handling of pathspecs here, so maybe tighten this?

    ++  git checkout HEAD -- file &&

This is better than what I had in my "maybe something like this". This
explicitly restores the file.

Martin