Paul Tan [off-list ref] writes:
Hi Luis,
On Fri, Mar 6, 2015 at 7:41 AM, Luis Ressel [off-list ref] wrote:
quoted
Okay, I've had a look at Paul's patch for this. Sorry again for the
dupe, I must've missed it before. I guess I'll attempt another
microproject.
However, I feel like my patch is really all that's neccessary; I don't
think we should try to use both files if they exist -- I consider
Paul's approach to be a bit overcomplicated.
My patch still uses ~/.git-credentials as a default location, which
should be sufficient for compability.
Indeed, that was my initial plan for implementation as well[1]. Matthieu,
however, wanted the behavior to follow that of git-config[2].
The fact that I suggested doing it this way does not mean it _has_ to be
done this way. Decisions are taken by trying to reach a consensus with
discussion, so everyone is welcome to argue.
I don't remember all the discussions we had about the ~/.gitconfig, but
one issue with considering only one file is if you create
~/.git/config/foo and initially make sure you don't have ~/.gitfoo, and
then one tool creates ~/.gitfoo (either an old Git, or another tool
trying to edit the config file), then you totally break your
configuration.
I argued for not taking backward compatibility too much into account in
another thread, but that was about precedence of one file over the other
which is far less important. Here, any tool creating even an empty home
file would break your configuration.
That also breaks the least surprise principle if you have a ~/.gitfoo
file that you forgot about: edit ~/.config/git/foo, nothing is taken
into account, at all (or the other way around, depending on the
precedence you choose). I remember loosing some time with two vlc
configuration files like this.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Hi,
Reading my previous message again, I apologize if it sounded
conflicting. Truth to be told, I see merits in both proposed
behaviors, but it all depends on whether we want git-credentials-store
to support an arbitrary number of config files (now or in the future)
or just two. I'm not sitting on the fence though, personally I think
that we should go with supporting an arbitrary number of config files
(and the behavior it entails for xdg file vs home file), because it
will open up more possibilities in the future with regards to
supporting multiple config sources.
On Sat, Mar 7, 2015 at 1:28 AM, Matthieu Moy
[off-list ref] wrote:
The fact that I suggested doing it this way does not mean it _has_ to be
done this way. Decisions are taken by trying to reach a consensus with
discussion, so everyone is welcome to argue.
Well, I think we need to decide if git is going to implement support
for XDG_CONFIG_DIRS as well, as support for reading/writing an
arbitrary number of config files will affect my views on the behavior.
Personally, I think git-credentials-store should implement support for
XDG_CONFIG_DIRS because, as I mentioned in the previous message,
administrators may wish to provide users with default saved
credentials.
If machinery is being added to support reading/writing to an arbitrary
number of config files, it would lead to simpler behavior (and simpler
code) if the old ~/.git-credentials is just treated as just another
config file to load from. (So yes, I agree with implementing your
proposed behavior)
However, if we are just going to support 2 configuration files (the
xdg file and the home file), then I think Luis' proposed behavior has
some merit. See below.
(Just mentioning for completeness) The third option would be to
implement a hybrid of the above two approaches (support arbitrary
number of config files, but only choose 1 between the xdg file and
home file), but this behavior is unnecessarily complex.
I don't remember all the discussions we had about the ~/.gitconfig, but
one issue with considering only one file is if you create
~/.git/config/foo and initially make sure you don't have ~/.gitfoo, and
then one tool creates ~/.gitfoo (either an old Git, or another tool
trying to edit the config file), then you totally break your
configuration.
I argued for not taking backward compatibility too much into account in
another thread, but that was about precedence of one file over the other
which is far less important. Here, any tool creating even an empty home
file would break your configuration.
Luis mentioned that if the user expects to use an old version of git,
the user would (or should) not create the xdg file in the first place.
I think that automated tools (and users) should call git-config to
edit the config files anyway and not roll their own. In fact, I think
that this issue will not occur at all if git prioritized
~/.config/git/foo over ~/.gitfoo instead of the other way around. When
the user creates the xdg file, the user is signaling that old versions
of git will not be used. Thus, if a tool creates/updates the old home
file (and it should not if it calls git-config), then configuration
changes won't take effect at all, and it _shouldn't_ because the tool
is _broken_.
But yes, the above strategy does not scale at all for multiple
configuration sources, which there will be if support for
XDG_CONFIG_DIRS is implemented.
(As an aside, I find it weird that git-config allows values in
~/.gitconfig to override ~/.config/git/config, given that the xdg file
is opt-in and introduced after ~/.gitconfig. Furthermore, it conflicts
with its writing behavior -- it writes to ~/.config/git/config and not
~/.gitconfig if it exists.)
That also breaks the least surprise principle if you have a ~/.gitfoo
file that you forgot about: edit ~/.config/git/foo, nothing is taken
into account, at all (or the other way around, depending on the
precedence you choose). I remember loosing some time with two vlc
configuration files like this.
Hmm, I don't know the exact specifics of what happened with VLC, so I
can't judge. As mentioned above, if the user wants compatibility with
old tools, the user will not create the xdg file. If the user has an
updated toolset, the user will create the xdg file and delete the old
home file. The old home file will not be created at all because all
tools would have been updated to support the xdg file, and hence the
user will not be confused.
Of course, in the context of git-config, it has to read the files in
/etc/gitconfig, $GIT_DIR/config etc, and thus as mentioned above,
reading from the home file as well would lead to simpler behavior and
code.
Regards,
Paul