Re: [PATCH 9/9] revert: simplify communicating command-line arguments
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Dec 9, 2011, 19:29 UTC
- Message-ID
- <20111209192919.GB20913@elie.hsd1.il.comcast.net>
- In-Reply-To
- <CALkWK0m_6yGuyLt-VqvRZkAiDoSxES8KeNzeXaejYRCpW=HAOg@mail.gmail.com>
Ramkumar Ramachandra wrote:
>> Ramkumar Ramachandra wrote:
Show 7 quoted lines
>>> +++ 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 >>> +'
[...]
Show 7 quoted lines
> 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.