refix bug in a better way

Always run Git.Config.store, so when the git config gets reloaded,
the override gets re-added to it, and changeGitRepo then calls extractGitConfig
on it and sees the annex.* settings from the override.

Remove any prior occurance of -c v and add it to the end. This way,
-c foo=1 -c foo=2 -c foo=1 will pass -c foo=1 to git, rather than -c foo=2

Note that, if git had some multiline config that got built up by
multiple -c's, this would not work still. But it never worked because
before the bug got fixed in the first place, the -c value was repeated
many times, so the multivalue thing would have been wrong. I don't think
-c can be used with multiline configs anyway, though git-config does
talk about them?
This commit is contained in:
Joey Hess 2020-07-02 13:32:33 -04:00
parent ec0f8a6e74
commit f912f8e5fd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 38 additions and 5 deletions

View file

@ -51,3 +51,19 @@ worth filing in case there's a simple fix.
> I don't currently understand why, but that prevented the value getting
> added.
> --[[Joey]]
> > Huh, with that commit's patch, the option is passed to all calls to
> > git.. But not to the call to ssh.
> >
> > Ah.. remoteAnnexSshOptions is populated by parsing the git config,
> > and is what gets passed to ssh. The patch though made it not call
> > Git.Config.Store, so when the git config has been reloaded, it loses
> > the -c config.
> >
> > Also, I notice that c8fec6ab0 had a second bug:
> > If -c foo=1 -c foo=2 -c foo=1 were passed, it would
> > add the first and second, but not add the third.
> >
> > I was really not at even 10% back in March. For obvious reasons.
> >
> > Ok, all fixed, the right way this time. [[done]] --[[Joey]]

View file

@ -45,3 +45,6 @@ dropped, but I haven't made any progress yet.
[[!meta author=kyle]]
[[!tag projects/datalad]]
> [[fixed|done]] (also re-fixed the original bug in a better way)
> --[[Joey]]