On Tue, Mar 16, 2021 at 06:10:26PM +0900, Mike Hommey wrote: > > > For the record, this is backwards incompatible with git-programs in > > > $PATH that were expecting the old format (e.g. git-cinnabar releases > > > using an older version of libgit.a). > > > > What isn't noted there is that we're still parsing the old format in > > some cases, see f9dbb64fad (config: parse more robust format in > > GIT_CONFIG_PARAMETERS, 2021-01-12). > > > > But I suspect you mean that you have your own parser that expects the > > old format only, I didn't find which way it was by grepping > > git-cinnabar's sources. > > git-cinnabar is using git's libgit.a, so when using a pre-compiled > version built against git < 2.31.0, it fails to parse > GIT_CONFIG_PARAMETERS when used with git 2.31.0. > There's not much I can do apart from releasing a new version. Yeah, that makes sense. As Ævar noted, we did write it such that people passing in values would be unaffected. But we couldn't help anybody _parsing_ the old format. This was a risk we accepted, because it's an undocumented internal format. So the "right" thing to do would be for the receiving side to pull the value out with "git config" (which, presumably running the same version of Git as the generating side, would do fine). I understand why a program like git-cinnabar wouldn't want to make a bunch of awkward and expensive git-config calls. But it's a problem that comes with using the (also undocumented and not recommended) libgit.a as an interface. So I am sad to have created headaches, but I also think it should not be a far-reaching problem. (I also wondered whether something like libgit2 or jgit might have been parsing GIT_CONFIG_PARAMETERS, but neither seems to). -Peff
