On 2014-01-10 22:00:40 +1300 (+1300), Robert Collins wrote: [...synchronized .gitignore across all projects...] > Out of curiousity, why wouldn't it work?
The example I gave earlier in the thread... one project wants autogenerated ChangeLog so it's in their .gitignore but another project wants a hand-curated ChangeLog so they commit it to the repository. The two projects can't share a common .gitignore file as a result. There are almost certainly other examples, that's just the first to spring to mind. Could work around it by dynamically proposing semi-synchronized .gitignore updates based on a number of other preferences expressed individually by each project, but this seems like overengineering. > *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. Do you have a recommendation for a canned .gitignore which safely covers the files left behind by most free software editors, IDEs, debuggers, test tools, et cetera? Something we should incorporate into a recommended initial list in openstack-dev/cookiecutter's template perhaps? [...adding my preferred tool dotfiles to every project...] > This is another strawman, no? Is anyone suggesting a crusade? If this is recommended as the preferred solution over me just configuring my computer to not commit these files, then yes. Each time I commit a change to another project, I'll need to propose an additional .gitignore change to cover whatever files my own oddball tool choices leave lying around in the repo. I still don't understand what's hard to get right about customizing your development environment, but trying to make this "easier" for people new to software development and doing it in inconsistent ways (some projects going out of their way to hide those file patterns, others not) strikes me as a recipe for *more* confusion, not less. However, I don't feel strongly about this one way or another, and was mainly responding to the previous objection that we as a project should never make development environment configuration recommendations to contributors. > I read that as 'we don't test that our tarballs work'. No? We don't test that changes won't break our tarballs in some ways, no. I suppose we could add new jobs to generate throwaway tarballs and then re-run all other tests using source extracted from those in addition to the source obtained from the VCS, but that's probably duplicating a lot of the current tests we run. Could be worthwhile to explore anyway. -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
