On Fri, Apr 11, 2008 at 1:20 PM, Junio C Hamano <gitster@xxxxxxxxx> 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? -- Ping Yin -- 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
