Patrick Steinhardt <ps@xxxxxx> writes:
> On Fri, Jan 15, 2021 at 02:16:46PM -0500, Jeff King wrote:
>> On Tue, Jan 12, 2021 at 01:27:01PM +0100, Patrick Steinhardt wrote:
>>
>> > The previous commit added a new format for $GIT_CONFIG_PARAMETERS which
>> > is able to robustly handle subsections with "=" in them. Let's start
>>
>> It looks like this commit and 6 got flipped from the original ordering
>> (it's the "previous commit" talked about here). And indeed, running the
>> tests on the individual commits in this series shows that we fail at
>> this step (because we are writing the new format, but the reader is too
>> strict to accept it).
>>
>> That doesn't matter to the end result, of course, but it hurts later
>> bisecting. Just flipping patches 5 and 6 makes it all work.
>>
>> -Peff
>
> Oops, yes. That always happens to me when I start using git-am(1). I see
> that the patch series has been applied to "next" already, so does it
> make any sense to resend with patches 5 and 6 flipped?
I recall saying that I'd "rebase -i" before merging it to "next".
Did I forget to do so?
Disecting 4ed03412 (Merge branch 'ps/config-env-pairs' into next,
2021-01-15), we see:
$ git log --oneline --reverse master..4ed03412^2 | cat -n
1 b0812b6ac0 git: add `--super-prefix` to usage string
2 ce81b1da23 config: add new way to pass config via `--config-env`
3 13c44953fb quote: make sq_dequote_step() a public function
4 b342ae61b3 config: extract function to parse config pairs
5 f9dbb64fad config: parse more robust format in GIT_CONFIG_PARAMETERS
6 1ff21c05ba config: store "git -c" variables using more robust format
7 b9d147fb15 environment: make `getenv_safe()` a public function
8 d8d77153ea config: allow specifying config entries via envvar pairs
The 5/8 that needs to come after 6/8 has title "store ... using more
rebust format" and that is the 6th patch in the series merged to
'next'. The 6/8 that needs to come before that one was called
"parse more robust format" and it now appears as the 5th patch.
So it seems all is well?
