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 <Matthieu.Moy@xxxxxxxxxxxxxxx> 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 -- 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