Re: Intricacies of submodules

[Junio C Hamano <gitster@pobox.com>]

"Ping Yin" <pkufranky@gmail.com> writes:

> On Fri, Apr 11, 2008 at 1:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>  > Some of it is personal, yes. But sometimes those personal preferences
>>  > need to be enforced on a project level (of course, giving everybody
>>  > a way to override the setting if they really want to). For a big
>>  > software organization with a mix of senior and junior engineers I need
>>  > a way to set up *my* workspace in such a way that everybody who
>>  > clones/pulls from it get not only the source code, but also "Git best
>>  > practices". That would simplify things a great deal for me, because
>>  > I can always say: "just pull my latest .gitconfig, make sure you
>>  > don't have any extra stuff in your .git/confing and everything
>>  > in Git will work for you".
>>
>>  I think the way you stated the above speaks for itself.  The issue you are
>>  solving is mostly human (social), and solution is majorly instruction with
>>  slight help from mechanism.  The instruction "Use this latest thing, do
>>  not have anything in .git/config" can be substituted with "Use this latest
>>  update-git-config.sh which mucks with your .git/config to conform to our
>>  project standard", without losing simplicity and with much enhanced
>>  robustness, as you can now enforce that the users do not have anything
>>  that would interfere with and countermand your policy you would want to
>>  implement.
>>
> 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.