Re: Can't assign user.name to "E F" in git config

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

 



On Mon, Mar 29, 2010 at 4:32 PM, Disc Magnet <discmagnet@xxxxxxxxx> wrote:
> I've never done a git init and I don't have any .git directory in the
> current directory. I get warnings in the following example. Moreover,
> I can't assign user.name to "E F".

Take a look at 'man git-config' and search for "value_regex".  The
behaviour is incredibly non-obvious, but git-config is working as
documented:

> humpty@wall:~/work$ rm ~/.gitconfig
> humpty@wall:~/work$ git config --global user.name A B
> humpty@wall:~/work$ git config --global user.name C D
> humpty@wall:~/work$ git config --global user.name "E F"
> warning: user.name has multiple values
> humpty@wall:~/work$ git config -l
> user.name=A
> user.name=C
> humpty@wall:~/work$ cat ~/.gitconfig
> [user]
>        name = A
>        name = C

The A B line means "remove any user.name options containing B and then
add A".  Similarly with C D.  But the "E F" line means "there is only
one value of user.name, and it should be E F."  At that time,
user.name has more than one value, so git assumes you've made a
mistake and refuses to perform the operation (which would have
resulted in potentially many lost lines of config information).

You can fix it with "git config --global --unset-all user.name".

> However, everything works fine here.
>
> humpty@wall:~/work$ rm ~/.gitconfig
> humpty@wall:~/work$ git config --global user.name A
> humpty@wall:~/work$ git config --global user.name C
> humpty@wall:~/work$ git config --global user.name "E F"
> humpty@wall:~/work$ git config -l
> user.name=E F
> humpty@wall:~/work$ cat ~/.gitconfig
> [user]
>        name = E F

In the above, you never created multiple values, because the first two
lines didn't have extra parameters.

> Is this an expected behavior or is it a bug?

I didn't know about it before, and to be honest, it seems a little
insane.  But I found it by reading the man page, so it's clearly
"expected" behaviour, in the sense that we're told to expect it.  And
now that it exists, removing it would break backward compatibility.

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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]