Hi Greg On 02/02/2022 16:04, Greg Hurrell wrote:
Hi, Not sure if this is confined specifically to `git-checkout`, but that's the command I noticed the issue with: With the release of the v2.35.0 and the "zdiff3" setting for "merge.conflictStyle", I find myself wanting to use "zdiff3" on machines running the new version, and falling back to "diff3" on machines with an older version. To this end, I have a ~/.gitconfig that contains: [merge] conflictStyle = zdiff3 [include] path = ~/.gitconfig.local The idea is that I can use the same `~/.gitconfig` on every machine I use, but on machines that only have an older Git version, I drop in a ~/.gitconfig.local with overrides like this: [merge] conflictStyle = diff3 `git config --get merge.conflictStyle` correctly reports that my setting is "diff3" on such machines, and `git config --get-all merge.conflictStyle` shows: diff3 zdiff3 In other words, it knows that I have multiple values set, but it uses a last-one-wins policy. However, when I try to run a command like `git checkout -b something`, Git dies with: fatal: unknown style 'zdiff3' given for 'merge.conflictstyle'
I think what is happening is that git parses each line of the config file as it reads it so the old version of git sees "zdiff3" and errors out before it reads the include line. I'm afraid I don't have any useful suggestions for avoiding this other than switching the include around so that it contains zdiff3 and is only included by newer versions of git.
So, it looks like something in `git-checkout`'s option processing is causing it to disregard the override set via "include.path". In fact, it even disregards a value passed in with `-c` like this: git -c merge.conflictStyle=diff3 checkout -b something
I think the values passed with -c are parsed after all the config files so the override works. What we really want in this case is to store the string value for each config option as we read each config source and then parse those values at the end, unfortunately I think that would break multi-valued config keys.
Best Wishes Phillip
Does this sound like a bug, or are my expectations off? I'd be happy to look into fixing this, but first would like to know whether it is expected behavior. Cheers, Greg