summaryrefslogtreecommitdiff
path: root/wrapper.c
diff options
context:
space:
mode:
authorLibravatar Jonathan Nieder <jrnieder@gmail.com>2014-09-10 14:01:46 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-10-15 10:47:20 -0700
commit2b2b1e4d27b4e44c0c46d4857c76b8391d303af3 (patch)
treeb9ad88f7a5218a9a1bf347c58c5d2ea3086c4a6b /wrapper.c
parentUpdate draft release notes to 2.2 (diff)
downloadtgif-2b2b1e4d27b4e44c0c46d4857c76b8391d303af3.tar.xz
mv test: recreate mod/ directory instead of relying on stale copy
The tests for 'git mv moves a submodule' functionality often run commands like git mv sub mod/sub to move a submodule into a subdirectory. Just like plain /bin/mv, this is supposed to succeed if the mod/ parent directory exists and fail if it doesn't exist. Usually these tests mkdir the parent directory beforehand, but some instead rely on it being left behind by previous tests. More precisely, when 'git reset --hard' tries to move to a state where mod/sub is not present any more, it would perform the following operations: rmdir("mod/sub") rmdir("mod") The first fails with ENOENT because the test script removed mod/sub with "rm -rf" already, so 'reset --hard' doesn't bother to move on to the second, and the mod/ directory is kept around. Better to explicitly remove and re-create the mod/ directory so later tests don't have to depend on the directory left behind by the earlier ones at all (making it easier to rearrange or skip some tests in the file or to tweak 'reset --hard' behavior without breaking unrelated tests). Noticed while testing a patch that fixes the reset --hard behavior described above. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'wrapper.c')
0 files changed, 0 insertions, 0 deletions