Re: git-checkout doesn't seem to respect config from include.path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux