Adding the .gitignore file to the Panopoly repository can create situations in which modules, libraries and themes do not get added to git repositories that are built from Panopoly. To see what I'm talking about, try running the following commands:
git clone --branch 7.x-1.x http://git.drupal.org/project/panopoly.git
drush make -y panopoly/build-panopoly.make panopoly_docroot --no-gitinfofile
cd panopoly_docroot
git init
git add *
git commit -m "initial commit of full panopoly docroot"
rm profiles/panopoly/.gitignore
git status -s
After removing profiles/panopoly/.gitignore, you can see that the following directories have still not been added and committed to the new repository:
profiles/panopoly/libraries/
profiles/panopoly/modules/
profiles/panopoly/themes/
This is going to create problems for developers who try to use Panopoly as the starting-point to build their own websites. They'll create the codebase on their local computer, add their custom code and then create their own repository and push to their server, only to discover that code which was working on their local has gone missing.
The Drupal.org packaging script is adding the .gitignore file to tarballs, so this is an issue for developers who download the tarball in addition to developers who do a git clone and then drush make.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | panopoly-gitignore-2215829-5.patch | 367 bytes | dsnopek |
Comments
Comment #1
dsnopekThis is a frustrating issue. The "real solution" is for Drupal.org to stop including the .gitignore in the packaged downloads. We (as in Panopoly contributors and manitainers) use the current .gitignore to make developing Panopoly itself more convenient for us. It allows us to do "git add " without fear of accidentally committing something we shouldn't.
However, since this keeps comming up, I'm starting to think that removing the .gitignore file is good interim solution. Basically, we have to choose between: making life easier for contributors/maintainers of Panopoly, or making life easier for users.
If things have to become less convenient for us (in the short-term, until Drupal.org can be fixed) to be more convenient for users, that probably makes sense.
What do other contributors/maintainers think?
Comment #2
sheldon rampton commentedI think it would be better to remove the .gitignore file and provide a bash script that the Panopoly developers and maintainers can use it to add the gitignore to their local development clones (but not commit it) to the d.o. repository.
If you want to avoid accidentally committing the .gitignore file, you can also tell git to ignore files on local repositories using .git/info/exclude
In any case, I think removing .gitignore from the publicly-shared repo on Drupal.org is the best approach. It's a tradeoff between making life easier for Panopoly developers, vs. making life easier for developers who use Panopoly to build websites. I think the latter category is more numerous and also more likely to be significantly inconvenienced by this.
Comment #3
damienmckenna+1 for removing the .gitignore file and using .git/info/exclude for local development.
Comment #4
owen barton commentedAgreed that this .gitignore breaks normal site development with panopoly (and isn't easily noticed until upgrades break when pushed with missing files, which is an issue).
Confirmed that this patch works, but not marking as RTBC until we have a script or documentation for panopoly developers.
Comment #5
dsnopekDiscussed with @mrfelton and he recommended an approach which I think will work great:
.gitignoretogitignore.examplegitignore.exampleto.git/info/exclude- which I just tested and it works as expected!Thanks everyone for helping move this forward! A new patch is attached, I hope to commit this soon. :-)
Comment #6
sheldon rampton commentedGreat! Now can I get someone to blog about how doing this with .gitignore files is a Drupal best practice? My ulterior motive in filing this issue ticket in the first place is that I'm trying to convince developers of my own distros to do what you've just done. :-)
Comment #8
dsnopekCommitted!
@Sheldon Rampton: Well, we've only just started using this approach - I'm not sure it's a best practice yet. :-) But it does seem to be a good middle ground. Maybe you could write a blog post about why you think this should be the accepted best practice? I'll mention to the Open Atrium team that we made this change and if they follow suite and then we'd have two examples to point to, which starts to sound more like a best practice.