"Ping Yin" <pkufranky@xxxxxxxxx> writes: > 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? "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. -- 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
