The basic idea of t3501 is to check whether revert
and cherry-pick works on renamed files.
But as there is no pure cherry-pick/revert test, it is
good to also check if commits are actually done in that
scenario.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.
The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.
Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They are already set and exoprted by sourcing ./test-lib.sh
in all test scripts.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes revert and cherry-pick to use merge-recursive, to
allow them to notice renames. A pair of test scripts
demonstrate that an old change before a rename happened can be
applied (reverted) after a rename with cherry-pick (with revert).
Signed-off-by: Junio C Hamano <junkio@cox.net>
