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:

I'd recommend taking .gitignore out of the tree so that devs can add arbitrary stuff.

Reply to this email directly or view it on GitHub:
#3 (comment)

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:

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.

Reply to this email directly or view it on GitHub:
#3 (comment)

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
/configuration.php

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 ;-)