Re: Intricacies of submodules

>  > 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.
>