On 6 January 2014 05:18, Jeremy Stanley <fu...@yuggoth.org> wrote: > I think people are conflating two different "global" concepts > here... > > There had been a discussion about synchronizing the .gitignore files > of all projects into one central list (a la openstack/requirements > synchronization): "global" across our entire developer community. > > There were also suggestions that contributors could adjust their own > ~/.gitconfig to ignore the particular trashfiles created by the > tools that they commonly use: "global" across all local git > repositories on a particular developer's computer. > > The first is something which I'm pretty sure will flat out not work, > and would almost certainly annoy a great many people if we did find
Out of curiousity, why wouldn't it work? > enough workarounds to get it to "sort-of work." The second I see as > no different than configuring Git to know your preferred E-mail > address or OpenPGP key, but Sam was expressing a concern that we as > a project should never educate contributors about available options > for configuring their development tools. *everyone* I know gets git's preferred email and gpg config wrong to start with. Recent gits make this explicit by refusing to work in a broken fashion. I see having common defaults in trees as an analogous thing - rather than beating people up when they got it wrong, make it harder for them to get it wrong. > I'm not opposed to projects adding random development tool droppings > to their .gitignore files, though I personally would prefer to just > configure my development environment to ignore those sorts of files > for any project I happen to touch rather than go on a crusade to > patch every project under the sun to ignore them. This is another strawman, no? Is anyone suggesting a crusade? > I also disagree that they require no reviewer time... we have > release tooling which takes the patterns in .gitignore into account > so it knows to skip files which get generated as part of the build > process. A too-greedy pattern in a .gitignore file can very quickly > end in broken release tarballs if reviewers are not especially > careful to confirm those patterns match *only* what's intended > (which also means gaining confidence in the nuances of git's pattern > matcher). I read that as 'we don't test that our tarballs work'. No? -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
