Re: [PATCH 1/2] t3507: pin CHERRY_PICK_HEAD absence for a conflicting --no-commit

Junio C Hamano [off-list ref] writes:

It is not apparent what problem, if any, the description
above claims the commit addresses.  Nor is it clear why
checking these combinations is relevant.
[...]
Can you help me understand the above two paragraphs a bit better?

The test pins the one combination t3507 did not cover. The file already
checks CHERRY_PICK_HEAD after a conflicting pick, after a clean pick, and
after a clean pick under --no-commit, but not after a conflicting pick
under --no-commit. That is the case a user hits by accident: the pick
stops on conflicts, they resolve and run "git commit", and the original
author is not restored. --no-commit never wrote the ref, d7e5c0cbfb skips
it on purpose. Your reading is right and Gemini's is backwards: under
--no-commit we do not want CHERRY_PICK_HEAD, and the test asserts it is
absent. Without it, teaching git to write the ref there would leave the
whole file green.

The message was unclear, sorry. "it" was that missing case and
"siblings" the three existing checks. v2 with a reworded message goes
out once 24 hours have passed since v1.