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
