You should not create .gitignore to your project to exclude patches, diffs and phpstorm project files.

#1 git_ignore-2514146-1.patch166 bytesram4nd
PASSED: [[SimpleTest]]: [MySQL] 5,337 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


ram4nd’s picture

Status: Needs work » Needs review
166 bytes
PASSED: [[SimpleTest]]: [MySQL] 5,337 pass(es). View
Sneakyvv’s picture

I second that!

Sneakyvv’s picture

Status: Needs review » Reviewed & tested by the community

I'll even boldly RTBC this.

IRuslan’s picture

I just could recommend if maintainer do prefer to have separate project in phpStorm to add gitignore to gitignore itself.

So you could just add:
to .gitignore file.
But don't forget to do
git rm .gitignore because file is already in git it's required to make effect.

podarok’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

Where is a rule about "you shouldn't" ?

When you are maintainer - adding gitignore saves a lot of time.

ram4nd’s picture

I guess I would explain it this way. The module you provide is made to be used in production. As you don't include your IDE project to production, you should not include any of your development hidden files. You could use other strategies for your local setup to exclude these things.

Sneakyvv’s picture

Then do what IRuslan suggested. Or ignore those files globally. Not sure anymore why I RTBC'd this, but I suppose your gitignore file was causing problems for people using your module. Another reason why you "shouldn't" do that, is because no one does, so perhaps everyone has good reason to do so.

JamesOakley’s picture

I know this is marked as "won't fix", but I'll still add a comment here to say "+1"

It seems to me that, when you clone a repository to work on it, you create your own .gitignore file to determine what files within that working directory will be ignored by local git commands. Those needs will be different for each developer who works on their own fork, so I'd presume it's bad practice for a .gitignore file ever to be committed to the master repository.

>> I suppose your gitignore file was causing problems for people using your module.

Yes, it is. I use quite a lot of contrib modules and themes, and Date is the only one that has a .gitignore file in the packaged releases. When I create a development copy of a site to work on it, I use drush rsync, which does not copy across .gitignore files. If I then use Hacked to check to ensure that I'm using correct versions of all files, it always flags up the Date module as not having the file ".gitignore" that should be present. Only it shouldn't actually be present, so I'm getting a red flag in Hacked when actually nothing's amiss. Too many of those, there's then a danger that I start ignoring red flags that are genuine issues, because I've got too used to seeing the false alerts.

I'm sure other people, who have their own development environments and wish to use their own .gitignore file, also find it causes problems to have a project that uses its own one.

>> When you are maintainer - adding gitignore saves a lot of time.

Yes, I can quite see that.

However, with the greatest of respect (because I'm every grateful for this module), surely a maintainer's task is to run a public contributed module in whatever way is best for all users of the module, as constrained by its intended use-case. Adding your own personal .gitignore settings so that everyone else inherits them is, I would have thought, not best-practice in a public repo.

Anyway, just my 2p. It's your (collectively - 5 of you) module, presumably you've discussed this amongst the maintainers and decided this is the best approach, so it's up to you. (So I won't change the status of this issue away from "won't fix": I assume you've made your choice already).

ram4nd’s picture

Status: Closed (won't fix) » Needs review

Thanks, will put this up for another review by the maintainer.

Tom Verhaeghe’s picture

I strongly agree with #8 here. On top of that, if you want to patch a module a common method is to put that patch inside the module's directory (in folder sites/all/modules/patched). In the current state *.patch files are bluntly ignored and .gitignore therefore needs another hack.

It's the same reason why Thumbs.db or .DS_store files are also not ignored. If you really want to save time you can choose to ignore those files globally.

matthiasm11’s picture

I do share #8's opinion. .idea and other editor files should be ignored globally, since not everyone uses the same editors.
#10 is the main reason why I looked into this issue, we also need to have the applied patches in the repo.

@Maintainers, could you please remove the .gitignore from the repository?

apmsooner’s picture

I agree... please remove .gitignore file. I was wondering why i couldn't see my own patch files and then found that file.

jcisio’s picture

I second (or tenth) that.

It is not an exotic technique to put some patches in a patched module. This file prevents this behavior.

vijaycs85’s picture

Status: Needs review » Reviewed & tested by the community

Let's do this.

DamienMcKenna’s picture

DamienMcKenna’s picture

Title: .gitignore » Remove the .gitignore file

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks.

JamesOakley’s picture

Ooh, @DamienMcKenna - I didn't know you were a maintainer for this module. Thank you for resolving this after so long. :-)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.