On 26 Oct 2015, at 17:52, Jens Lehmann <jens.lehm...@web.de> wrote: > Am 26.10.2015 um 17:34 schrieb Stefan Beller: >> On Sun, Oct 25, 2015 at 8:12 AM, Lars Schneider <larsxschnei...@gmail.com> >> wrote: >>> On 20 Oct 2015, at 19:33, Junio C Hamano <gits...@pobox.com> wrote: >>>> I do not think this topic is specific to use of submodules. If you >>>> want to encourage your engineers to fetch from nearby mirrors you >>>> maintain, you would want a forest of url.mine.insteadof=theirs for >>>> the external repositories that matter to you specified by >>>> everybody's $HOME/.gitconfig, and one way to do so would be to have >>>> them use the configuration inclusion. An item in your engineer >>>> orientation material could tell them to add >>>> >>>> [include] >>>> path = /usr/local/etc/git/mycompany.urlrewrite >>>> >>>> when they set up their "[user] name/email" in there. >>>> >>>> And you can update /usr/local/etc/git/mycompany.urlrewrite as >>>> needed. >>> Oh nice, I didn't know about "include". However, as mentioned to Stefan in >>> this thread, I fear that our engineers will miss that. I would prefer a >>> solution that does not need any additional setup. Therefore the suggestion >>> to add rewrites in the .gitmodules file. >> >> How do you distribute new copies of Git to your engineers? >> Maybe you could ship them a version which has the "include" line >> already builtin as default? So your distributed copy of Git >> would not just check the default places for configs, but also >> some complied in /net/share/mycompany.gitconfig > > Which is just what we do at $DAYJOB, that way you can easily > distribute all kinds of settings, customizations and hooks > company-wide.
That's a very good idea. I will try to establish this practice, too. Thanks, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
