We are talking about policies not fundamental laws of the universe. Policies are created in order to simplify decisions based on previous history, so clearly there were projects that existed before this policy was introduced. Try to look at it via pragmatic approach: this policy tries to avoid a never ending list of reviews related to local files. -- for good reasons, people have the freedom to use whatever editor they want. So what if everyone is writing his own editor with his own editor config files to be ignore? This is why such a policy was created. Obviously it appeared after it was observed and I am sure there are lots of projects that do have .gitignore files that do not "pass" this policy. Don't waste time trying to solve it, it does not worth the time.... you may endup like "someone is wrong on the internet". ;) harmony sounds nice on paper but in real life is impossible (or at least impractical) to achieve. If someone mentions it during a review, accept it and add the exception to your user .gitingore file. Cheers Sorin PS. I got myself a CR rejected few months ago for the same reason, I read about it and accepted it. It makes sense.

On 22 Jan 2019, at 14:32, Sean McGinnis <sean.mcginnis@gmx.com> wrote:

...

Then I have started to make patch, to align OpenStack projects with this policy:

https://review.openstack.org/#/c/632086/

In nova project the patch was refused, the first reason was we have already talk about this subject. The second reason was this policy is only for the new projects. Oslo is not a new project and is follow this policy.

I know is not a priority subject, but I just want understand. For me a policy must be followed by all projects, to harmonize all, but maybe I wrong. For example, in this case, I would to know what is the rules? The new projects must follow the policy but not the old ones? In this case, what the rules for old projects and can we defined also an policy for it? Thanks in advance for your help.

My best regards

It is somewhat up to each project and the core teams if, when, and how they want to enforce something like this.

So while it is generally recommended not to put IDE, OS-specific, and other similar things in the per-project gitignore, there is also no real value added by going through all existing projects and removing things that are already there.

Sean

On Tue, 2019-01-22 at 17:29 +0000, Sean Mooney wrote:

On Tue, 2019-01-22 at 15:32 +0000, Sorin Sbarnea wrote:

...

We are talking about policies not fundamental laws of the universe.

Policies are created in order to simplify decisions based on previous history, so clearly there were projects that existed before this policy was introduced.

Try to look at it via pragmatic approach: this policy tries to avoid a never ending list of reviews related to local files. -- for good reasons, people have the freedom to use whatever editor they want. So what if everyone is writing his own editor with his own editor config files to be ignore?

This is why such a policy was created. Obviously it appeared after it was observed and I am sure there are lots of projects that do have .gitignore files that do not "pass" this policy.

Don't waste time trying to solve it, it does not worth the time.... you may endup like "someone is wrong on the internet". ;)

harmony sounds nice on paper but in real life is impossible (or at least impractical) to achieve.

If someone mentions it during a review, accept it and add the exception to your user .gitingore file.

so i personally am in the camp of just merge patches for trivial change like this when they are proposed but also as you said you can just set these in you users ~/.gitignore too. by the way your user level git ignore is at this location by default $HOME/.config/git/ignore if you want to use a ~.gitgnore you need to override that default. using ~/.gitignore is generally not ideal if you are one of those people that like to commit there home directory to git to be able to easily version contol it. anyway i hope that helps. there is some documentation about that here https://git-scm.com/docs/gitignore however i have found most people are not aware that there is such a thing as a user's git ignore which is what propmts people to propose patches to change the projects .gitignore so if we do say we dont suport this becase of policy x we should try to tell people how they can update ther local env to have the same effect.

...

Cheers Sorin

PS. I got myself a CR rejected few months ago for the same reason, I read about it and accepted it. It makes sense.

...

On 22 Jan 2019, at 14:32, Sean McGinnis <sean.mcginnis@gmx.com> wrote:

...

Then I have started to make patch, to align OpenStack projects with this policy:

https://review.openstack.org/#/c/632086/

In nova project the patch was refused, the first reason was we have already talk about this subject. The second reason was this policy is only for the new projects. Oslo is not a new project and is follow this policy.

I know is not a priority subject, but I just want understand. For me a policy must be followed by all projects, to harmonize all, but maybe I wrong. For example, in this case, I would to know what is the rules? The new projects must follow the policy but not the old ones? In this case, what the rules for old projects and can we defined also an policy for it? Thanks in advance for your help.

My best regards

It is somewhat up to each project and the core teams if, when, and how they want to enforce something like this.

So while it is generally recommended not to put IDE, OS-specific, and other similar things in the per-project gitignore, there is also no real value added by going through all existing projects and removing things that are already there.

Sean