-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Ignore configuration.php #3
Conversation
I'd recommend taking .gitignore out of the tree so that devs can add arbitrary stuff. |
It's still possible to add arbitrary stuff to .gitignore, even with an existing one in place. I think that for the majority of the people cloning from GitHub, having a .gitignore file with configuration.php (and possibly the tmp, cache, & administrator/cache folders) would be most useful. If we distribute without a .gitignore, people adding one will run into essentially the same issue: .gitignore will appear as an unstaged change or addition. On Oct 6, 2011, at 7:34 PM, Andrew Eddie wrote:
|
Mmmm, but wouldn't you just ignore the .gitignore? I've just had trouble trying to untrack it and then change branches. Git tends to complain about that. |
I agree. Changing ignore files is mandatory in this tree for example if you are also testing your own extensions and you really don't want to have those in CMS branch. :) By default eGit adds ignore files to the ../target directory, so it would be easy to add a rule that ignores all the other .ignore files and have basic stuff in the main ignore. After that you could just ignore .ignore and edit it from github.. |
Personally, I'd prefer to see a default .gitignore similar to the SVN's ignore ruleset. If devs want more, then they can handle it themselves, but a good template to start with is always nice. |
I'd have no problem adding a gitignore-dist file. I think that would be a good idea. |
RE, testing extensions: I personally prefer to see those as unstaged changes. They server as a reminder that "hey, this isn't a clean copy of Joomla." I'll leave it at this though: I'd prefer to see .gitignore ready to go for the majority of us doing feature adds and bug fixes. I can see the case for leaving it out (or doing gitignore-dist), but I think that including it will make it easier for people to get their commits out there without issues. |
Hi, Joe, once there is agreement on this would you please make a patch and post it on joomlacode? That is the only way that changes are coming in at this point. Otherwise this change will have to wait until the next stage of migration which is not going to happen at minimum until there is documentation of JBS process as done on github is available on the joomla wiki. |
Since this commit solely concerns the configuration of Git, it doesn't make sense to post it over at JoomlaCode. If the change has to wait, we can wait. On Oct 7, 2011, at 10:31 AM, elinw wrote:
|
Well it does in that the only way commits are being made to github is via committers reviewing patches at joomlacode. But it's up to you. |
IMO the .gitignore file is meant to be shared. Things only you need to exclude but no one else can go into .git/info/exclude |
@realityking I had forgotten about .git/info/exclude. In that case, I'd strongly prefer to have configuration.php and those three folders in a standard, distributed .gitignore file. |
What three folders are you referring too? Also I'd suggest changing the line to This will only exclude the file if it's at the repro's root. Oh and please add a new line at the end of the file. |
@realityking I've updated the pull request with your suggestions, along with the three folders (/tmp, /cache, /administrator/cache). Since there are already index.html files being tracked in these three folders, they'll still get cloned in Git. However, any files that get added to those folders will be ignored. So I think we have it covered. Also added a newline :) |
I think 06157ec has this one covered quite well, so closing the oldest open item here ;-) |
Update en-GB.com_postinstall.ini
``` PHP Fatal error: Uncaught exception 'PHP_CodeSniffer_Exception' with message 'Class PHP_CodeSniffer_CommentParser_ClassCommentParser not found' in /home/travis/build/photodude/joomla-cms/build/phpcs/Joomla/Sniffs/Commenting/ClassCommentSniff.php:19 Stack trace: #0 /home/travis/build/photodude/joomla-cms/libraries/vendor/squizlabs/php_codesniffer/CodeSniffer.php(1318): include_once() #1 /home/travis/build/photodude/joomla-cms/libraries/vendor/squizlabs/php_codesniffer/CodeSniffer.php(560): PHP_CodeSniffer->registerSniffs(Array, Array) joomla#2 /home/travis/build/photodude/joomla-cms/libraries/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php(830): PHP_CodeSniffer->initStandard(Array, Array) joomla#3 /home/travis/build/photodude/joomla-cms/libraries/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php(95): PHP_CodeSniffer_CLI->process() joomla#4 /home/travis/build/photodude/joomla-cms/libraries/vendor/squizlabs/php_codesniffer/scripts/phpcs(25): PHP_CodeSniffer_CLI->runphpcs() joomla#5 {main} thrown in /home/travis/build/photodude/joomla-cms/build/phpcs/Joomla/Sniffs/Commenting/ClassCommentSniff.php on line 19 ```
Fix deprecation warning with PHP 8.1+ If a replacement string is used, but no 'quicktask' is defined `$params->get('menu-quicktask')` will return `null` which is deprecated in PHP 8.1+. Deprecated: str_replace(): Passing null to parameter joomla#3 ($subject) of type array|string is deprecated in administrator/components/com_menus/src/Helper/MenusHelper.php on line 894
Fix deprecation warning with PHP 8.1+ If a replacement string is used, but no 'quicktask' is defined `$params->get('menu-quicktask')` will return `null` which is deprecated in PHP 8.1+. Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in administrator/components/com_menus/src/Helper/MenusHelper.php on line 894
Database stuff
Added configuration.php to .gitignore.