Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >> If the "auto" comes from /etc/gitconfig then we'd recommend >> changing it there, instead of overriding it per-user in ~/.gitconfig? > > Yes, though I'm on the fence about that. I wonder if we should > recommend ~/.gitconfig instead if the user account that git is running > under does not have write access to /etc/gitconfig. That also raises > the question of what advice we should give about clearing settings in > the system config file if the user does not have write access to > it. It is possible the human user has write access to the system > config even if the user account that git is running under does not but > we have no way of finding that out. Isn't it last-one-wins? How about just telling them to do without any "git config unset" and just do a single "git config set", either to the repository (when the "auto" we saw came from the repository) or to the per-user configuration (when the "auto" we saw came from elsewhere, either per-user, or system-wide)? >>>> It would be necessary to special case "auto" after 3.0 boundary >>>> anyway, whether we (1) die when we notice the value is set to >>>> "auto", and refuse to work until the user chooses a comment char, or >>>> (2) use "#" or something hardcoded. Either would be better than >>>> using literal string "auto" as comment char. > > I'm leaning towards dying to avoid any nasty surprises when the commit > message contains lines beginning with '#'. > > I'll try and re-roll next week Thanks!
