On Fri, 2008-04-11 at 15:32 -0700, Junio C Hamano wrote: > > But, how to handle the case that there are more than one policies > > for different projects? > > "How to"? You would handle the case just like either of us suggested > above. > > Are you talking about a single project with more than one policies A, B, > C, ... that conflict with each other? Or are you talking about more than > one projects, each of which has a single project-wide policy? > > I do not think the former makes sense and won't be helped with in-tree > file that overrides .git/config Roman discussed either. > > The latter would be helped equally well whether that in-tree polic file is > called .gitconfig or update-git-config.sh. I believe Fedor addressed the social aspects of this issue quite well, so I'm just going to focus on a technical aspect here: there is a difference between .gitconfig and update-git-config.sh approaches that I would like you to acknowledge. With update-git-config.sh you are allowing for a repository to be in a state that is inconsistent with the policies that need to be enforced, without novice users even realizing that. Contrast this with .gitconfig where policies get enforced right from the minute your clone operation finishes and there's much less opportunity for the user to shoot himself in the foot. In fact "shooting in the foot" (senselessly overriding default policies via .git/config) becomes an *explicit* action on user's part. He is the one to blame. Thanks, Roman. -- 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
