[PATCH 4/6] t7502: drop confusing test_might_fail call

In t7502.20, we run "git commit" and check that it warns us that the author and committer identity are not the same (this is always the case in the test environment, since we set up the idents differently).

Instead of actually making a commit, we have a clean index, so the "git commit" we run will fail. This is marked as might_fail, which is not really correct; it will always fail since there is nothing to commit.

However, the only reason not to do a complete commit would be to see the intermediate state of the COMMIT_EDITMSG file when the commit is not completed. We don't need to care about this, though; even a complete commit will leave COMMIT_EDITMSG for us to view. By doing a real commit and dropping the might_fail, we are more robust against other unforeseen failures of "git commit" that might influence our test result.

It might seem less robust to depend on the fact that "git commit" leaves COMMIT_EDITMSG in place after a successful commit. However, that brings this test in line with others parts of the script, which make the same assumption. Furthermore, if that ever does change, the right solution is not to prevent commit from completing, but to set EDITOR to a script that will record the contents we see. After all, the point of these tests is to check what the user sees in their EDITOR, so that would be the most direct test. For now, though, we can continue to use the "shortcut" that COMMIT_EDITMSG is left intact.

Signed-off-by: Jeff King <peff@peff.net>
---
Sorry for the long explanation. It took me a long time to figure out why
this test_might_fail is there at all, so I wanted to present my full
analysis as to why it's OK to remove.

 t/t7502-commit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)