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