Re: Intricacies of submodules

[Roman Shaposhnik <rvs@sun.com>]

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.