change .gitignore after some commits/push

Question

I have created a repository in my github account with a socialengine php project without .gitignore file.

Then I clone the repository localyl and I create a .gitignore file and i write some lines of paths to ignore files and folders.
As an example

temporary/log
temporary/session
temporary/package

There is a file auth.php in install/config/auth.php path and I write also in my .gitignore file the path of it to ignore it as follows

install/config

During the installation I see that the subfolders of temporary folder are ignored.

The think is that when I am in the installation step where some authentication lines of code should be written in auth.php file, the file auth.php looks unstaged when I type git status.
I can not figure out why this happens although I have included the path (install/config) in .gitignore file.

I have tried also install/config/, install/config/* but nothing.

If I use git rm --cached install/config/auth.php then the file will be deleted remotely something that must not happen because this file is needed to exist for socialengine installation and for future installation.

There is any idea what I can do for this situation ?

Answer 1

I pushed .idea folder by mistake, that contains some IDE settings, then, tracking all changes made to .idea bothered me. so I followed these steps

• Add all the files, individually or in a folder, that you want to remove from the repo but keep locally to .gitignore.
• Execute git rm --cached put/here/your/file.ext for each file or git rm --cached folder/* if they are in a folder. (It is /* because you need to escape the *)
• Commit your changes.
• Push to remote.

Then, I reverted the folder that I am no longer willing to track using git. here is a helpfull thread in Link

Answer 2

Don't do that!

What you have done here is to assign the responsibility of maintaining the local auth.php file to the source system that uses it.

Consider the following line of thought. Imagine you're the user of the system, which you get from the vendor. Every quarter, the vendor ships you a new system. But you reconfigure whenever you shuffle your servers around, which is every month, or sometimes more or less frequently based on load.

How often should you, as the user, commit your own personal configuration? Well, every time it changes, if you are source-controlling it at all. That's monthly, more or less.

Every three months, the vendor ships you the latest version of the system ... with a new configuration he foists upon you, even though that's not your configuration. That's just wrong. Not only did you not want a new configuration from him, your schedule of configuration changes is not his schedule.

The solution is: as the vendor, don't do that. Don't put the local configuration into the source at all. Your users will have their own local configuration, which they store separately from your code, maybe even in a completely separate repository.

"But my users are stupid! I must foist a configuration upon them!"

Well, that's fine; many are. Go ahead and include an initial configuration, or a default configuration. If your users have not set up their own configuration, use that—maybe even copy it into place as the local configuration. But then, after that, don't touch their local configuration.¹ Update the initial and/or default configurations, sure. But don't touch the user's local configuration.

---

¹Except, perhaps, for migrations: if the user is upgrading from version 1.7 to version 2.1, you can migrate their local configuration to add new features. Depending on your configuration file format, you may also need to support reverse migration, should they wish to downgrade from 2.1 back to 1.7.

Answer 3

Local ignore

You need to use the assume-unchanged flag
https://git-scm.com/docs/git-update-index

# To temporarily ignore changes in a certain file, run:
git update-index --assume-unchanged <file>

# When you want to track changes again:
git update-index --no-assume-unchanged <file>

Server side ignore

Read this full answer with a full code to do it on the server side:
What are some more forceful ways than a .gitignore to keep (force) files out of a repo?

---

--[no-]assume-unchanged

When this flag is specified, the object names recorded for the paths are not updated.

Instead, this option sets/unsets the "assume unchanged" bit for the paths.

When the assume unchanged bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.