Moe <moe@xxxxxxxxxxxxxx> writes: >> I find the original use case highly moronic. >> >> For people to be sharing an account, hence $HOME, there must be a reason. >> They want to (rather, the administrator wants them to) use a common shared >> set of settings, so $HOME/.gitconfig should be shared among them, just >> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason >> to treat .gitconfig any differently from all the other $HOME/.whatever >> files. But I don't think there wasn't any argument to defend that. > > I'm not arguing to treat .gitconfig differently from other > dot-files, but to treat it differently from .git/config. > > The former is user-specific, the latter is repository-specific. That is something we already do, like everybody else. $HOME/.emacs is user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:" section is per-document. Have you asked emacs guys (and vim folks) about a change similar to the one on topic here? This question is rhetoric and you do not have to answer it. >> Wouldn't it be just a matter of giving different HOME after they log-in? >> >> After all, Moe will be giving _some_ way to his users set different value >> to GIT_CONFIG_EXTRA depending on who they really are, and that same >> mechanism should be usable to set different HOME to them, no? > > The individual users are identified by their ssh key. Ssh sets a > distinct environment variable for each, which in turn is used in > .bash_profile to read an additional user-profile. > > Yes, we could overwrite $HOME but that would defeat the purpose. > The goal of this setup is to share almost all settings. You haven't answered the crucial question, and repeating yourself is not an explanation. I've already said sharing the account is to share things, you know I understand you want to _share_. I asked why $HOME/.gitconfig has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk, etc. that are shared. You are not answering the question. What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and all the other things? Why do you want to share all the other dot files, most of which lack the support for you to do the "set-up" you have to do in $HOME/.bashrc to switch based on something other than the UID (I would call that a "set-up", not a "hack", because you have to do that somewhere)? Why do your users tolerate that they cannot have their own private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have to share $HOME/.gitconfig with others? Knowing that is very important for us, as $HOME/.gitconfig will not stay the only thing you would need to single out with future versions of git. For example, we have discussed a support for $HOME/.git-excludes that sits between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile configuration variable. Should it be shared, or separated? Why? I do not want to count on you, who I have never seen on this list before, being around to ask if such a change would break your use case when the day comes. If we do not know the _criteria_ you are using, the reason why you want to single out $HOME/.gitconfig when it is Ok for your users to share $HOME/.vimrc, we will not be able to make good design decisions to support this "shared account" configuration [*1*]. Will we introduce GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA? Where does it end? > I hope this can still make it, considering the small size of > the patch and the .git/config vs ~/.gitconfig argument. That is not an argument at all. We handle .git/config vs $HOME/.gitconfig just fine; see above. One plausible answer you could have given is that your users do not have an account in the usual sense of the word at all, and the _only_ thing they can do with your system is to run git and nothing else. IOW they have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these other dotfiles do not matter at all. That makes $HOME/.gitconfig special. A possible solution might be for us to honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR overrides $EDITOR. That allows us to extend the notion more naturally in the future. For example, when we start reading from $HOME/.git-excludes, if the GIT_HOME environment is set, we would instead read from $GIT_HOME/.git-excludes. That would be a much cleaner solution than Miklos's patch [*2*]. But you have given us too little for us to be able to judge what the best longer-term course of action is. How could you even _hope_ it can "make it"? [Footnote] *1* Of course, before doing so, we need to decide if this "shared account" configuration makes sense or not to begin with, but you haven't given us enough to work with to even decide that. *2* I am not criticizing Miklos's patch in particular. The patch was done in the same void without any usable information from you what you really needed, so the lack of provision for future we can see in the patch is not Miklos's fault. Also he is not the git maintainer and is not used to worry about the future like I do. -- 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