Re: Intricacies of submodules

["Ping Yin" <pkufranky@gmail.com>]

On Sat, Apr 12, 2008 at 6:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> "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.

I meant more than one projects, each of  which has a different
project-wide policy.  I originally thought update-git-config.sh can't
help, but i'm wrong since it can update $GIT_DIR/config instead of
$HOME/.gitconfig.

However, i think .gitconfig is better since it's more consistent with
other analogies.



-- 
Ping Yin