Open Stack

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