Re: [PATCH v8 5/8] config: store "git -c" variables using more robust format

> Patrick Steinhardt <ps@pks.im> 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?