Ramkumar Ramachandra wrote: >> Ramkumar Ramachandra wrote: >>> +++ b/t/t3510-cherry-pick-sequence.sh >>> @@ -414,4 +414,15 @@ test_expect_success 'mixed pick and revert instructions' ' >>> +test_expect_success 'commit set passed through --all' ' >>> + pristine_detach initial && >>> + test_expect_code 1 git cherry-pick --all && >>> + git cherry-pick --continue >>> +' [...] > This one's actually quite interesting. "git cherry-pick --all" first > tries to apply everything from "intial" to "yetanotherpatch" (both > inclusive) -- its first "git commit" invocation returns 1, refusing to > create an empty commit. Then when we say "--continue", it notices > that the worktree and index are clean, removes "initial" from the > instruction sheet and executes everything else as usual. This is > something we should attempt to fix So, is it a bad test? Was the initial command crazy and ill-defined enough that no one would actually do that? Is the response to the command incorrect, meaning that the new test should be instead checking for some different result with test_expect_failure? I only mentioned --all in the first place because it is a "revision pseudo-option" (i.e., option starting with "--" whose position on the rev-list command line matters) and gets handled by a slightly different revision parsing code path than foo..bar. There are other revision pseudo-options that are easier to control and might make for a better test if it's wanted, like --remotes=foo. > Way starts with creating an API for "git commit". Not sure what this means. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html