Rename core .gitignore file to example.gitignore and add explanatory comments

http://www.kernel.org/pub/software/scm/git/docs/gitignore.html

I understand your concern, I usually use Drupal roots as the git project root too.

My patch moves the .gitignore to sites/, so there will be less conflict in the project root.

Reroll.

To get the bot going.

Looks good, not sure why this was added in the first place really, we should just encourage people to diff before commit/push, but now it's in there moving it somewhere less annoying makes sense.

erm.

It was added at the root since there was talk of adding 'files' to the list of the ignored directories.

Anyway, the change seems exceedingly sane to me, however I'm loathe to keep changing these things for the developers. Maybe we should also avoid packaging .gitignore in the project download?

x-post!

This file was added over in #917492: Add a sensible .gitignore file. I've asked some folks from that issue to chime in here with their thoughts.

Until we hear from one or more of the Git folks like rfay, etc. I'd like to consider this still "needs review". But it seems like a reasonable complaint.

As I said over in the other thread, there are plenty of reasons to check settings.php into version control, especially if you're using a settings.local.php file. If you're using a module like domain access, it HAS to have changes made to settings.php that should be on every server.

It is not the job of Drupal.org to dictate how I use version control, and this gitignore file actively breaks *the workflow used by Drupal.org itself*, as well as anyone who follows that as a best practice. Just moving the file around won't change that.

The gitignore file should be removed completely.

I'm a proponent of having a good .gitignore by default. I think moving it to sites would be reasonable, and wish I'd thought of it. +1 for this approach.

I did write about the many different ways to co-exist with the default .gitignore in http://randyfay.com/node/102.

What if we would ship a "gitignore" file (without a dot)?

If someone needs it, they can just rename, and it wouldn't cause any problem.

Renamed status and rolled patch according to suggestion in #18.

git won't use the file if it's named 'gitignore'. I don't think anybody else is in favor of renaming the file.

The point is exactly that git should not use the gitignore file by default.

I think it is a better way than removing it.

Hmmm, I'm not quite sure renaming the file is the way to go, as it doesn't actually solve anything. Renaming .gitignore will just result in a gitignore file that noone uses.

Personally, I'd rather just fix .gitignore to ignore other revision control files: #1169766: Ignore other version control systems in .gitignore

Personally, I'd rather just fix .gitignore to ignore other revision control files

Doesn't help someone who wants to maintain their own top-level .gitignore file. Although, in such a case, they could also maintain their own local branch, as well.

What if we just excluded the .gitignore file from the tarball / zipfile release? That would be consistent with excluding the rest of the git files under the .git directory.

What if we just excluded the .gitignore file from the tarball / zipfile release? That would be consistent with excluding the rest of the git files under the .git directory.

I think the tarballs are created with git archive, in which case we could add a .gitattibutes file with contents:

.gitignore export-ignore

See also #1111224: Introduce .gitattributes to end the CRLF/LF and binary diff horror, and detect/auto-fix whitespace errors.

Re-titling.

re-titling after another re-read of the whole issue.

Additionally I'd like to point out that upgrading Drupal core will be easier after #22336: Move all core Drupal files under a /core folder to improve usability and upgrades (and followups) get through. After that, most users will likely upgrade Drupal core by replacing the "core" directory only, rather than replacing everything but "sites". This would probably lead to general acceptance of modifying the default .gitignore file, just like it's very common to modify .htaccess.

I agree with rfay and others here that this looks like a good idea to split into two .gitignore files. Note that this is the approach used in #7 only. Not #19, which took a completely different approach.

The patch in #7 is definitely an improvement and I don't think anyone has objections to it (though alternatives or further changes have been suggested). I'm going to say this one is good to go. We can debate alternatives in a followup if we want, but this is a forward step with no downside that I can see.

Sorry, it doesn't feel like this isusue has consensus yet. The patch in #7, while it solves some problems, also doesn't solve others (#15).

I think I was too hasty in committing .gitignore for D7 in the first place, so I'd like to make sure the next thing I do to it is the right thing to do. Let's discuss more.

Okay, let me sum up for latecommers to get the discussion going again:

A lot of people are using git to manage sites built with git. Drupal code provides a .gitignore file which makes git ignore certain files.
This file is currently in the Drupal root and ignores certain files from the "sites" directory.

On upgrading the .gitignore file a lot of people mistakenyl overwrote his/her own .gitignore file or caused merging conflicts. To avoid these cases in the future we could:

• Keep everything as it is.
  We could hope that the .gitignore file won't be updated in the next releases.
  People were not rushing the issueque after the update, so we could assume that it is not an issue that affected a lot of people.
• Remove the gitignore file (#15)
  People could manage their own .gitignore files, and if they are bothered with the output of git status they will eventually ignore the files they don't want to commit.
  Note that for people who are updating their Drupals from tarball, the .gitignore file will be left in the Drupal root (but I guess that can't be helped).
• Move the .gitignore file under the /sites directory (#1, #7)
  Since it only ignores files under /sites it is certainly possible.
  It will not help your workflow if you do want to check files in which are ignored by the .gitignore (on the other hand it won't make it worse either) (#15)
• Rename the gitignore file and provide it as an example on how to write gitignore files, including the most common best practices. (#18, #19)
  That way people who need that could just rename it to the correct name, people who don't can just ignore it, or write a better one for their workflow.

Am I missing something?

You missed one of the problems with the currently committed gitignore, which is that it ignores settings.php. There are many workflows that involve checking settings.php into version control (and using a settings.local.php instead), and that is even a recommended workflow. Thus excluding settings.php by default is incompatible with a recommended workflow, requiring in essence a hack of core in order to use it. (OK, maybe I'm stretching there but it does mean editing a file that subsequent updates will change back on you, which is a PITA.)

I would support removing the file and instead providing good examples and best practices.

Straight rollback sounds good to me too.

And, of course, I still like the approach in #7 (The third approach in #31).

It provides an easy fix, and is not too intrusive. I've written about how to override the existing approach, and with #7 it's even easier.

IMO the vast majority of sites should not control their settings.php with the source code approach they use for their code. It causes overwrites on deployment... Happened to webchick and Dries loads of times in the CVS days for exactly those reasons. Also, on the vast majority of sites the files directories should not be controlled by the source control system used for code because the files are transient.

The simple approach we already have in place (improved by #7) works in general, has worked for most of us since it went in, and is fine.

This is no great thing, and we'll all live fine however it comes out. I like it the way it is.

The reason this happened in the cvs days was because we actually shipped with settings.php, once we changed to default.settings.php I'm not aware of any incidences of settings.php being checked in. It feels like a very different issue to me.

Another idea: we could provide a .gitignore (for example under sites/) with commented out examples of every sane workflow we can come up with.

@Crell in #32:

You missed one of the problems with the currently committed gitignore, which is that it ignores settings.php.

So the patch in #7 fixes this problem doesn't it? Most sites do not commit settings.php, and because the patch in #7 would put the .gitignore file that ignores settings.php inside of /sites, users could modify it without "hacking" core, since it's within the sites directory (which isn't considered part of core). So "most" sites would get good defaults and those that implement more complicated uses of settings.php could modify the /sites/.gitignore file to suit their needs.

If you update core using drush, it overwrites all files in the original tarball, even those in sites. This is already an issue for htaccess, which frequently requires slight tweaks for each server. That doesn't mean we should make it an issue for another file, too.

If you update core using drush, it overwrites all files ...

Sounds like a drush problem. Have you filed an issue?

@Crell, you make a strong case that we should move this to the Drush queue :-) That behavior is an ugliness of drush, I agree.

WHEREAS A properly configured .gitignore is useful, especially to prevent accidentally uploading your settings.php file as part of a patch; and

WHEREAS Drupal can be acquired through either a tarball download or a git clone; and

WHEREAS Drupal downloaded in a tarball is either not checked into git, rendering .gitignore useless, or checked into a local repository where uploading settings.php is harmless or even desired; and

WHEREAS Updating core with Drush wouldn't mess up .gitignore if it wasn't in the tarball; and

WHEREAS Drupal downloaded with git clone is usually done by an expect hacker who can figure out how to deal with modifying the .gitignore file; therefore be it

RESOLVED Drupal core shall include the .gitignore file in the git repository, but shall exclude it from tarballs by #1111224: Introduce .gitattributes to end the CRLF/LF and binary diff horror, and detect/auto-fix whitespace errors.

+1 to bfroehle on style if nothing else. :-)

Having .gitignore in the clone but not in the tarball is, I think, a reasonable compromise. That way, it's only relevant if you are:

- Making core patches.
- Building your site by tracking upstream Git and managing multiple repositories.

In either case, I think the bar to those is sufficiently high already that you either won't be hurt by a .gitignore file or know how to work around it, because you're being fancy already.

Note that this is not incompatible with the other suggestions to move the .gitignore file to sites/, etc. (I'm also not sure why .gitattributes is relevant, since the packaging scripts can just take care of it.)

Rather than randomly have this file there or not (not everyone in charge of a Drupal site is the same person who installed it), what if we just removed it altogether and added a handbook page somewhere for recommended stuff to put in it?

Rather than randomly have this file there or not (not everyone in charge of a Drupal site is the same person who installed it), what if....

I think doing a git clone versus a package download is a huge difference in project management style. Having a root .git directory would also be added if you did a git checkout, which would make this pretty "un-random", in that if you have .git directory from drupal.org then you'd also have the .gitignore. Git does not work properly (in my experience) if you have nested Git projects. You'd have to be a pretty gutsy person to manage your entire site through Git clones and submodules (the only way to have subdirectory Git projects work reliably).

I think the age of CVS/Git checkouts for each project (including core) is dead. Git is not intuitive to use if you've got remotes and submodules from drupal.org in addition to your own project repository. If you're that ninja-like with Git, the .gitignore file isn't going to pose a problem to you anyway.

Anyway, +1 to removing .gitignore from project archives. I'd love to see this in contrib too, since I regularly have to ignore Eclipse's .project files from Git.

Another point, shouldn't we make another issue for this? Or hasn't it already been raised in the past? I'd still like to see the original patch in #7 to be committed (as it IS still an improvement). The issue was retitled in #27.

EDIT: Sorry the other issue is #1111224: Introduce .gitattributes to end the CRLF/LF and binary diff horror, and detect/auto-fix whitespace errors, which I didn't realize would provide this functionality.

webchick: Removing .gitignore entirely and reverting to the original behavior was and still is my preference, but having it stripped out by the packager is a compromise I can accept.

Tagging issues not yet using summary template.

I'm throwing my vote in with the "removing it altogether" club. The handbook page is a good idea so that folks can understand what's going on with this.

To work around this currently, I have to add another .gitignore in the sites directory. It's rather confusing to have multiple .gitignores, and I don't think that this should become a best practice, but it will be if we leave it in.

Anyway, my second .gitignore looks like this:

# Override the parent directory's declaration that settings.php files shouldn't
# be version controlled.  We actually would like these files stored in the
# repository.
#
# We're overriding this here, as opposed to editing the other .gitignore, because
# that other file is part of Drupal core, and we don't want to mess with it.
!*/settings*.php

Everyone will have a different preference here: Some will want settings.php files in, and some won't. It's best that we don't try and put everyone in the same waffle house. Different strokes for different folks.

Merging a few of the ideas here, can we:

1. move .gitignore to /sites/.gitignore // as it only ignores these files

2. Don't package /sites/.gitignore // how many people actually use git to manage their site, and can't they write their own? * I always overwrite .gitignore on projects, but like having it there for creating Core diffs

3. Provide a /sites/example.gitignore in the repo / package, as we do for example.sites.php

I don't think that stripping gitignore from the package is enough.

I would expect the same behavior when I download the tarball and add it to a repo and when I clone it from drupal.org .
I would be very surprised to see two different things if I wouldn't attend this topic (especially since it wasn't the case of the previous versions).

I still think that removing the file from the repository and providing a nice example is the way to go.

I would expect the same behavior when I download the tarball and add it to a repo and when I clone it from drupal.org .

Your expectation is unrealistic. For one thing, the tarball will include a version in the .info file; the git checkout will not. This complicates module dependencies.

See #1013302: Composer metadata on dev versions doesn't work in update.php

Your expectation is unrealistic. For one thing, the tarball will include a version in the .info file; the git checkout will not. This complicates module dependencies.

I see your point and can't argue with that.
On the other hand I still remain convinced that providing an example gitignore file is the best solution for our problems.

Ok, it sounds like we're approaching consensus in this issue. Let's go with:

1) Removing the .gitignore file
2) Including an example one that documents possible approaches.

Sound good?

Well, I'm not going to bikeshed, but I'm very happy with what we have, and would be even happier if we put a .gitignore in sites instead. I suspect the commenters on this have been only those who are dissatisfied :-)

But I'll live with whatever.

rfay: Hm. Well, it's worth asking what the consequences would be to site builders if we did this during a d7 stable release. Since this has been in core so long, people have likely already figured out whatever workarounds.

rfay: Even if we move it to the "sites" directory, there is still the problem of some users wanting settings.php files in Git while others don't. In fact, this gets more difficult to override because now there has to be an overriding .gitignore in every single site directory. Basically, users need to be able to edit this file without hacking core.

webchick: That sounds like a good plan to me.

Dunno what my opinion is worth, but I'm definitely okay with removing .gitignore from core.

+1 on #52.

Also happy with #52

Well, somebody is going to need to write the example .gitignore file before this moves forward. webchick suggested an example that documented possible approaches.

So what approaches can we have?

1) The way the current .gitignore handles things
2) The approach in the current issue summary

What else?

Also, what are we going to call this new example file? I propose .gitignore.example

Also, retitling to reflect consensus. The second part of the title is worded weird, but I couldn't figure out a better way to state it succinctly.

Should be something without a leading dot so people know it's there. We call the example sites.php example.sites.php so we should call this one example.gitignore.

So we're removing the .gitignore, that's great!
Now we have to discuss if the example gitignore file should be under sites/ or not =)

I for one think it should be in the root (where the current .gitignore file is).

example.gitignore in root is fine with me. I propose we trick sdboyer into writing this for us. :-)

With great sadness...

Let's try that again, with (hopefully) improved wording.

Another slight tweak, after re-reading #917492.

Added more comments explaining what to change if you decide to store your .gitignore file in the sites/ folder.

Perhaps we should also add the following?

# Ignore this file as it is no longer included in the official repository.
.gitignore

No, because .gitignore needs to be a part of the repository...

It might be worth adding a note saying something to the effect of:

"A .gitignore was included with core by default. As of [version this patch makes it into], that is no longer the case and any changes to your .gitignore will no longer be overwritten by core updates."

@#70 -- Okay, but:

1. I'm not sure what happens if someone updates via git pull or git rebase after this patch makes it in. Will their (possibly customized) .gitignore file be renamed to example.gitignore?
2. I'll go ahead and re-roll with your suggested change with [version this patch makes it into] set to 7.9 but obviously it will have to be re-rolled if 7.9 is released before this patch is committed.

If they're using release tarballs, they'll end up with a .gitignore AND an example.gitignore.

If they're using git for deployment, it might or might not be renamed to example.gitignore. You could find out by doing this:

cd ~
git clone git://drupalcode.org/project/drupal.git
git clone ~/drupal ~/drupal2
cd drupal
[Apply latest patch and commit]
cd ../drupal2
[edit .gitignore - add something to it]
git pull --rebase
[check .gitignore and example.gitignore to see what the contents are]

I'd do it myself, but I'm typing from my phone atm.

When this patch gets in, we should add something in the release notes that says "Check to make sure your .gitignore is configured how you want it after upgrading to [version this patch makes it into]"

Here's what I got:

First, rewinding head to replay your work on top of it...
Applying: Added "myfiles/*" to .gitignore
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (delete/modify): .gitignore deleted in HEAD and modified in Added "myfiles/*" to .gitignore. Version Added "myfiles/*" to .gitignore of .gitignore left in tree.
Failed to merge in the changes.
Patch failed at 0001 Added "myfiles/*" to .gitignore

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Obviously this is confusing, but if someone is maintaining a modified copy of .gitignore in their local repository they should be able to cope, right?

Hm. That seems to be a fairly good reason to not backport this to D7...

@webchick, if somebody gets that error, it means they are deploying directly from Git and are more than capable of either 1) handling it, or 2) Googling it, then handling it.

Hm. That seems to be a fairly good reason to not backport this to D7...

So ignore the patch in #71 and consider the one in #68 instead.

I think this REALLY needs to get into Drupal 7...that .gitignore is a pain to deal with.

Users aren't supposed to be hacking core, right? That .gitignore is part of core now, so assuming that they didn't edit it, it shouldn't be a problem. (Assuming folks could edit core files like this is how we got into this mess in the first place.)

Isn't everyone simply using "drush pm-update drupal" anyway? :) It'll happily clear out modified core files like hacked .gitignores.

@colan: The problem is that the .gitignore that was added to core provided an ignore list that didn't work for anybody who wanted to keep their settings.php in version control. The same thing happens for people who need to add custom things to their .htaccess (for instance, to make Boost work correctly). IMO, neither of them should have been added to core in the first place (I think we should have htaccess.example as well, but I'm sure others would disagree).

I think it's safe to assume that users who have modified their .gitignore know what they're doing. As such, a change like this should absolutely NOT be held back on the basis that there's now a conflict that those users have to resolve.

They're going to have to take some action anyways - git is just notifying them of that fact.

I don't think we can assume that people didn't edit .gitignore. Personally I didn't consider gitignore as part of core, and edited it without considering the kittens.
I agree with webchick that it cannot be merged back, as I can't figure out any way to avoid the conflict.

Updated Issue Summary

So we introduce a bug that breaks crap for some people, and then don't fix it because Git is doing what it is supposed to do for those same people? That doesn't make any sense to me at all.

We broke it, we bought it, we document it in release notes for how to resolve it.

Isn't everyone simply using "drush pm-update drupal" anyway?

No. drush is slow and uses too much memory. In order to use it, I have to shut down everything else, because I'm on a cheap VPS with a 512MB memory limit.

Also, I track my changes in a separate git branch, and don't want drush overwriting things willy-nilly.

The same thing happens for people who need to add custom things to their .htaccess (for instance, to make Boost work correctly). IMO, neither of them should have been added to core in the first place

<rant offtopic=1>
Hear, hear! I use nginx and resent seeing both an apache-specific .htaccess and an IIS-specific web.config file in my web root. (Not to mention all those .txt files that should be moved to a /docs directory...)
</rant>

I didn't say that we can assume people didn't edit .gitignore. On the contrary, any non-trivial site probably edited .gitignore. I'm saying that the people that did hacked core and that we can assume they know how to resolve a conflict.

The solution is simple:

cp .gitignore .gitignore.tmp
git pull --rebase
cp .gitignore.tmp .gitignore
git rebase --continue
git commit

Problem solved. Anything else?

The solution is simple:

cp .gitignore .gitignore.tmp
git pull --rebase
cp .gitignore.tmp .gitignore
git rebase --continue
git commit

That almost works. Here's a console log of what does work.

bobvin@bowie:~/www/8.x$ git status
# On branch 8.x
nothing to commit (working directory clean)
bobvin@bowie:~/www/8.x$ cd ..
bobvin@bowie:~/www$ git clone 8.x 8.x-local
Cloning into 8.x-local...
done.
bobvin@bowie:~/www$ cd 8.x-local/
bobvin@bowie:~/www/8.x-local$ echo 'myfiles/*' >> .gitignore
bobvin@bowie:~/www/8.x-local$ git commit .gitignore -m 'Local changes to .gitignore'
[8.x 1f2af34] Local changes to .gitignore
 1 files changed, 1 insertions(+), 0 deletions(-)
bobvin@bowie:~/www/8.x-local$ cd ../8.x
bobvin@bowie:~/www/8.x$ curl http://drupal.org/files/issues/drupal-rename-gitignore-1170538-71.patch | git am
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2090  100  2090    0     0   8643      0 --:--:-- --:--:-- --:--:-- 16854
Applying: Issue #1170538: Rename core .gitignore file to example.gitignore.
Applying: Issue #1170538: Add explanatory comments to the example.gitignore file.
bobvin@bowie:~/www/8.x$ cd ../8.x-local/
bobvin@bowie:~/www/8.x-local$ cp .gitignore .gitignore.tmp
bobvin@bowie:~/www/8.x-local$ git pull --rebase
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From /home/bobvin/www/8.x
   d36af64..a23bd78  8.x        -> origin/8.x
First, rewinding head to replay your work on top of it...
Applying: Local changes to .gitignore
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (delete/modify): .gitignore deleted in HEAD and modified in Local changes to .gitignore. Version Local changes to .gitignore of .gitignore left in tree.
Failed to merge in the changes.
Patch failed at 0001 Local changes to .gitignore

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

bobvin@bowie:~/www/8.x-local$ mv .gitignore.tmp .gitignore
bobvin@bowie:~/www/8.x-local$ git add .gitignore
bobvin@bowie:~/www/8.x-local$ git rebase --continue
Applying: Local changes to .gitignore
bobvin@bowie:~/www/8.x-local$ git status
# On branch 8.x
# Your branch is ahead of 'origin/8.x' by 1 commit.
#
nothing to commit (working directory clean)

So in short, the magic incantation is:

cp .gitignore .gitignore.tmp
git pull --rebase
mv .gitignore.tmp .gitignore
git add .gitignore
git rebase --continue

If this patch goes in, we probably ought to include the working incantation in the release notes, since even a subject-matter expert (**cough**cweagans**cough**) got it wrong.

And btw, I love this quote:

...any non-trivial site probably ... hacked core and ... we can assume they know how.

May I have permission to use it out of context?

I'm not exactly a subject matter expert, especially re: git. I didn't have a terminal open, so it was mainly from memory.

Are there any other blockers to get .gitignore out of core?

+1 on removal.

Are there any other blockers to get .gitignore out of core?

+1 on removal.

Well, yes. Somebody has to step up the plate and RTBC either #68 or #71 or submit an alternate proposal.

Okay, I'm good with #71 as long as there's some way to communicate to site owners that their .gitignore could get hosed and that they need to take some action before they upgrade.

Created an API change node.

Committed to 8.x.

It sounds like we want to commit this to 7.x but that there might be some risk.

Moving to 7.x for webchick to consider more carefully.

Hm. :\ I'm really torn on this. :\ The original change was made way back in 7.2. We're now (going to be) at 7.9 (10 months after D7 came out).

It seems like people who use Git will have already worked around this issue in D7, and changing it under them once again could have really nasty effects (like their entire /files directory ending up in version control).

Especially given the shenanigans in #85 required to work around this, I'm inclined to pass.

Can we discuss this more, please? What's the worst-case scenario if we introduce this fix this late?

@webchick, I interpret that as:

"We introduced a featurebug in Drupal 7 that requires people to work around it in 80% of setups. Since most people have worked around said featurebug already, removing it would probably cause more damage than it's already done."

That sentiment makes zero sense to me - it's how Windows came to be Windows, and I don't really want to push Drupal down that path.

It's a pain to deal with every time I want to upgrade core, and it seems like there's a pretty strong feeling that it should be removed and should have never been included in the first place.

Re commands in #85...they're nothing. Especially for somebody that's already using git to version their site. Especially if we literally spell it out for them.

I think the bigger question is "How can we communicate to site owners that such a change took place?". If we can answer that question, then committing this becomes a no-brainer IMO.

I don't think this is major against 7.x, if we're not sure whether it's won't fix or not.

Moreover, it also means that now, as .gitignore is part of the Drupal core project, having one's own .gitignore file could be considered as a core hack (as it implies manual maintenance and ports over Drupal versions).

It seems like people who use Git will have already worked around this issue in D7, and changing it under them once again could have really nasty effects (like their entire /files directory ending up in version control).

This bit me today. Suddenly I have 33MB of media files in my repository. Huge +1 for removing .gitignore and adding an example.gitignore with much helpful commenting.

Random snarky comment:

A .gitignore file is only slightly different than an .htaccess file, in my opinion.

* They both tell another piece of "might-not-be-using-it" software how to work.
* They both often require customization for specific (and advanced) case scenarios.
* If either is overwritten, they will often cause headaches.

I have to be careful about my older-than-Drupal-itself .htaccess file each and every release too.

@#97

Hear, hear! Posted: Never Hack Core. Please review.

A .gitignore file is only slightly different than an .htaccess file, in my opinion.

The difference is that .htaccess is required for the site to function, while .gitignore is simply a file that makes a host of assumptions about how the developer works.

Posted: Never Hack Core.

This isn't about hacking core so much as core hacking the developer. I was fine with my git workflow and ignores until Drupal decided to decide things for me.

The difference is that .htaccess is required for the site to function, while .gitignore is simply a file that makes a host of assumptions about how the developer works.

Incorrect. The .htaccess means nothing under nginx or IIS (thus why I said "another piece of "might-not-be-using-it" software" above) or an Apache VirtualHost which includes necessary parent configurations that the .htaccess then overrides. Your lament about "the .gitignore is screwing me up!" is as irrelevant to someone who uses bar (as above, again) as someone else lamenting that the shipped web.config is screwing up their IIS (for example).

We should stick all of these configuration files (.htaccess, web.config, .gitignore, etc.) into a directory called config.wouldn't that make sense?

@laura s.

This isn't about hacking core so much as core hacking the developer. I was fine with my git workflow and ignores until Drupal decided to decide things for me.

From Never Hack Core:

Similarly, when any change to Drupal core benefits some users at the expense of others, there should be a way to avoid or override the change without "hacking core." Instructions for doing so should accompany the change. Changes that lack such methods and instructions are strongly discouraged. Core patches should stay in "needs work" status until such methods and instructions are provided or deemed irrelevant.

@cweagans

We should stick all of these configuration files (.htaccess, web.config, .gitignore, etc.) into a directory called config.wouldn't that make sense?

Or a directory called doc/examples

From Never Hack Core:

Quoting oneself isn't an argument. And it does not respond to the proposal to remove this extraneous and unnecessary file from core so one doesn't end up "hacking core". What is your proposed solution? Live with it? Why not put this unnecessary file out of the way, better yet into an example.gitignore file? What is its purpose here?

The .htaccess means nothing under nginx or IIS (thus why I said "another piece of "might-not-be-using-it" software" above) or an Apache VirtualHost which includes necessary parent configurations that the .htaccess then overrides. Your lament about "the .gitignore is screwing me up!" is as irrelevant to someone who uses bar (as above, again) as someone else lamenting that the shipped web.config is screwing up their IIS (for example).

The argument that by working around .htaccess you don't need .htaccess is more an argument to remove it from core than a rebuttal against my position on this. And considering that hacking .htaccess is encouraged (just read the comments in it), this whole .htaccess analogy is a red herring.

is more an argument to remove it from core than a rebuttal against my position on this

It's about time you realized I was agreeing with you ;)

It's about time you realized I was agreeing with you ;)

Sometimes heated agreement precludes the need for that second cup of coffee. :) (But thanks for clarifying b/c I hadn't had my first yet.)

It seems like people who use Git will have already worked around this issue in D7, and changing it under them once again could have really nasty effects (like their entire /files directory ending up in version control).

Just noting here is that this is more of a user training argument - it usually happens by using 'git add -a' without looking at 'git status' first, which is a bad practice. You are betting that there will never be a circumstance where files you don't intend to commit will be committed.

While I agree that we should try to make our usage of Git as accessible as possible for newer users, we also can't take responsibility for users potentially departing best practices.

Also, with respect to another facet of this issue, I am all in favor of not including active platform-specific config files such as web.config, .htaccess, .gitignore or anything else.

I have no problem providing example files with documentation that the end users can build off of, or modify themselves. But shipping active server configuration files with Drupal has the downside that we need to worry about screwing up someone's site behaviour every time we update.

A better process in general would be to ship examples, and note in the release notes for a release when these examples have been updated so users can apply the updated example code to their own configurations.

@brianV

I am all in favor of not including active platform-specific config files such as web.config, .htaccess, .gitignore or anything else.

Patch?

@laura s.

Quoting oneself isn't an argument.

Sorry; this is the agreements department. Arguments are down the hall, right next to "abuse".

And it does not respond to the proposal to remove this extraneous and unnecessary file from core so one doesn't end up "hacking core".

If you find my input irrelevant, feel free to disgregard it.

Sorry; this is the agreements department. Arguments are down the hall, right next to "abuse".

Heh. :) Sorry. Didn't mean to complain. Thought it was getting-hit-on-the-head lessons. ;)

We should stick all of these configuration files (.htaccess, web.config, .gitignore, etc.) into a directory called config.wouldn't that make sense?

I do believe it might be easier for people new to installation to notice these things in the docroot. Not sure if that's the deciding factor, though.

Related issue:

#1117704: Move .htaccess to .htaccess.default

So, this is a lovely(?) discussion and all, but it still doesn't address the fact that all current D7 sites affected by this need to go through the song and dance at #85 in order to not completely screw themselves.

We already renamed the file in 8.x, so this will be fixed for Drupal 8. I think it's natural that when you do a major version upgrade stuff changes on you and you need to review it carefully. Simple point releases, a lot less so. I really don't feel it's appropriate to change this in a minor point release.

I would not change this in D7, just to spite all those people who have not had to carefully manage their .htaccess for the past 8 years ;)

Also, http://randyfay.com/content/handling-new-gitignore-file-d7-and-d8 has some nice advice for dealing with this for affected sites in D7. Something I would be totally fine with is someone working with Randy to move that information to Drupal.org and adding a link to the page in a comment in .gitconfig.

webchick: Ever since this went in, it's meant that anyone using git has to do a song-and-dance for MINOR core updates if they have a gitignore strategy that isn't precisely what's mandated by the current .gitignore file. Right now, we DO have to review carefully for minor point releases, which is exactly what you said we shouldn't be doing.

We introduced a bug. We still have not fixed it. We should still fix it.

Add Issue Summary

Working on issue summary
Summary written.

@dastagg, How's the issue summary coming? Need a hand? Feel free to ping me in IRC if you'd like a second set of eyes!

The Summary was written.

From Summary:

As of Drupal 7.9, this is no longer the case, and any changes made to your .gitignore file will no longer be overwritten by core updates.

BTW this is not true, at least if updating via Drush. My one legacy project with Drupal sitting in my repository root once again was borked today by core's overwriting my .gitignore file ... which, of course, I wasn't thinking about as I did this ... leading to several GB of images being added to the repository and the grinding down of several layers of tooth enamel.

Yep, this is a huge PITA, but it sounds like we aren't going to fix it in D7 because we evidently can't expect site owners to actually know what's going on with their site files for an upgrade.

Can we please have an update on this? It took .2 releases to include and .15 after its still a problem.
We ususally track the 'files' directory with git for most of our sites (smaller ones at least) so this whole default .gitignore file does work well in our setup.
I think the most valid aproach is to rename it to .gitignore.example so as not to override an existing .gitignore on each update like you have done with settings.php or even completly remove it from tar/gz packages. We cannot expect one size fits all aproach on .gitignore since it depends on the development policy each company uses. Even putting it in /sites/ directory is not correct since it still enforces a policy (tho i think we can override it easier there).

While in the first post it says that after 7.8 .gitignore is not included that is wrong.
http://img338.imageshack.us/img338/8161/gitignore.png

I don't have anything good to say that hasen't been said, but I just want to say...I would like to not have it the default way.

I didn't see a patch for this, but just took what is in D8 and backported it.

It seems pretty simple, but haven't read the whole thread here.

This issue got mentioned at one point in #2135189: Proposal to manage the Drupal core release cycle as an issue with backport troubles, so I tried to take a look now.

1. As far as I can tell, the crazy set of Git commands in #85 would only be required for sites that are running a Git checkout of Drupal core inside of (or as part of) a Git repository that contains their site. (I.e., they either branched their site's Git repository from Drupal core's Git repository, or they are using Git submodules, or something else like that.) Is that correct?
2. People doing the above are (I think) a pretty small minority, and when it comes to Git they are probably ninjas, or gods, or possibly ninja gods. Agreed?
3. The majority of sites (certainly the majority or perhaps 100% of sites that I've seen) presumably just have a tarball of Drupal core checked into their version control system (if they use version control at all). For those sites, assuming they have customized the .gitignore file, this update wouldn't be any more complicated than a core update that changes .htaccess or robots.txt or one of the other files that people often customize. In fact, it might be less complicated than that, since here we're deleting the file rather than changing it, so depending on what method you use to unpack the tarball this might not even affect your customized .gitignore file at all. Is that correct?

If all the above is true, it seems to me we probably could do this (with a release notes mention - similar to what we already do whenever we change .htaccess/robots.txt/etc - and also a pointer to the instructions for people who are in the Git-within-Git situation).

I'm also wondering about the Drupal 8 change record for this issue (https://www.drupal.org/node/1282644 - which could be repurposed for Drupal 7 if necessary)... currently it mentions the required Git commands but doesn't really indicate it's only for people doing the Git-in-Git thing, so if my understanding above is correct we should edit that change record too.

Uploading the correct patch from #124.

Removed inaccuracy regarding Drupal 7.8+ from issue summary not having this problem as that is completely false. Not sure where that came from since ALL drupal 7 releases have this issue :D

The way I usually solve this problem is by removing the .git directory from the Drupal document root and pushing it 1 directory above. This allows having a master .gitignore file 1 directory ABOVE drupal. The core .gitignore file takes care of sites/default/files, settings, etc and the master gitignore file can ignore anything else which includes files and directories both within the drupal document root as well as deeper in the drupal install if necessary. I think the correct way to fix this for Drupal 7 is to not even attempt to fix it since there are 50+ drupal 7 releases that have this problem. Changing it now would be to little to late. It's best to describe my solution in a README instead since it's the only solution that would be a onesize fits all type of solution. It changes how many repos may be structured but changing it to this structure is as simple as cd drupal_root_dir ; cp -f -r -a .git .. ; git add -A . ; git commit -a ; git push origin ; echo 'call it a day.'

This also has some security benefits as well because having .git in the Drupal document root is a MASSIVE security problem since Drupal does NOT have a .htaccess file for it (like it does with the files directory, why, I dont know, its a huge gaping security issue since there is a script kiddie script called and I quote "gitripper" that will rip .git dirs that are exposed to curious anonymous users such as worms, hackers, etc).

Added recommendations for Drupal 7 to eliminate this issue completely by simply moving the .git dir 1 dir above drupal to summary.

This was committed, restoring version to the commit and status.