0

So my .gitignore just at some point just stops working properly, and is showing me the changes in directories I want to ignore.

  • yes, I save it as ANSI
  • no extra characters on the file end
  • .gitinore is in a root dir of the working tree

  • I've read all the info about this *** solution:

    git rm -r --cached . git add . git commit -m "fixed untracked files"

It works indeed perfectly on my machine, I make this three steps - commit them - and I can make changes on my machine in ignored directories.

The problem is, when I pull this commit to the server, then it deletes all the ignored stuff! Not that it just ignores it, it removes files and directories from the server so the project becomes useless...

All over the internet this solution seems to be the only one for broken .gitignore, but it's not as it deletes the files and directories that should not be deleted. This is silly, such a stupid bug should be removed long time ago...

edit: it happens on different paths, or files, when manually or by software something is added to the .gitignore - putting the gitignore paths here that broke is pointless. <- this is the bug I mentioned, not that I run some commands...

prk_001
  • 361
  • 3
  • 17
  • 2
    This isn't a `git` bug, or if it was, it _was_ fixed long long ago. Gitignore works just fine. I'd guess this is caused by your workflow. I'll add that without an example of your `.gitignore` and the paths that "stop working" it's difficult to say much of anything in particular about your problem. – erik258 Nov 04 '18 at 19:24
  • 2
    `.gitignore` is not for ignoring changes in files, that is already tracked by Git. [Documentation](https://git-scm.com/docs/gitignore#_notes): The purpose of gitignore files is to ensure that certain files not tracked by Git remain untracked.) – user4003407 Nov 04 '18 at 19:34
  • 1
    Guess what? There's no bug here! Git is working as designed and, more importantly, _as documented_. Don't blame the tool just because you don't know how to use it. Before pointing fingers and throwing blame around take five minutes to read the documentation and / or the countless questions and answers on Stack Overflow that explain this behaviour. – ChrisGPT was on strike Nov 04 '18 at 22:17
  • the bug I meant, is that the .gitignore after adding some stuff (manually, or by software) breaks - this is fact and I can tell not only happening to me. And actually it deletes the files, not only ignoring them please read again my question. – prk_001 Nov 05 '18 at 18:06

1 Answers1

4

.gitignore does not delete anything on your server. You did it!

Read your question again. You have run:

git rm -r --cached .
git add .
git commit

The first command tells Git to remove everything from the index. It basically prepares an empty working tree as the next commit.

The second command adds the working directory back to the index but, because of the lines you just have added to .gitignore, the files you want to ignore are not present in the index any more.

The third command just makes your changes permanent. This means the commit you just created does not contain the files you just added to .gitignore.

This happens because this is the purpose of .gitignore: it tells Git what files to not track (any more).

Because they have been tracked in the past, the files are not deleted from the repository, they are just not present in the last commit (and all future commits). You can recover them after you run git pull by running:

git checkout <commit_id> -- <file_path>

where <commit_id> is the hash of the last commit that contained the files (just before you added their names to .gitignore) and <file_path> is the path of one ignored file you want to get. Repeat for each ignored file.

axiac
  • 68,258
  • 9
  • 99
  • 134
  • "Because they have been tracked in the past, the files are not deleted from the repository, they are just not present in the last commit " - this is not true, when I pull this commit on server, then git removes phisically the files listed in .gitignore. This is my problem, that's why I posted my question. How to do this .gitignore fix but so it also implies to my production copy, not that it breaks it. – prk_001 Nov 05 '18 at 18:10
  • Git does not delete anything in the repository. It always adds the new and the modified files. When you pull the recent commits into another working copy it removes the files not because they are present in `.gitignore` but because you have just removed them from the last commit (`git rm --cached`). Backup the files before running `git pull` or you restore them from a previous commit as explained in the answer. Next time you run `git pull`, Git won't delete them again. – axiac Nov 06 '18 at 05:15
  • `git pull` does not read `.gitignore`, it updates the working copy to match the most recent commit on the branch. Only `git add` reads `.gitignore`; this means it applies only to the new files. – axiac Nov 06 '18 at 05:55
  • Aha. So there is no solution to this situation. You say, after I push this commit, and then the production pulls it - it always has to break, and then I have to manually restore the files on server again. You find this ok, I find this silly. But thank you for answer. – prk_001 Nov 06 '18 at 15:45
  • Additionally, I have do this separately for each ignored file? I don't think this is a professional way of working with git. My gitignore contains a lot of stuff, if some my coleague pulls this my commit then he has to manually restore his copy? Sorry but I really don't understand how this possibly can make sense. – prk_001 Nov 06 '18 at 15:51
  • `.gitignore` contains the names of the files that must not be tracked in the first place. It's not Git's fault that you have tracked them in the past and suddenly you changed your mind. Also, it's not Git's fault that your deployment process is reduced to a `git pull` command. A correct deployment script uses `git pull` to get the most recent files into an empty directory, then it adds the configuration files (that must not stay in the repo), does other preparations (depending on the project) and when all these complete successfully it replaces the live files with the ones just prepared. – axiac Nov 06 '18 at 17:04
  • 1
    *"and then the production pulls it - it always has to break, and then I have to manually restore the files on server again."* -- read the referred commend again carefully. It says *"Next time you run `git pull`, Git won't delete them again."*. It happens only the first time because the changeset since the previous `git pull` says that the ignored files were deleted. – axiac Nov 06 '18 at 17:07