Open Stack

On 6 January 2014 05:18, Jeremy Stanley <fungi at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud