0

I have been developing a site locally (Laravel 7) and I have a repo on GitHub.

Every time I made a change locally, I pushed to the repository and from the VPS where the site is (via SSH) I did git pull. I realized that some folders previously placed in .gitignore were actually not being ignored. Then I saw that it was possible to clear the git cache. I did it that way and the next push actually ignored what I wanted it to ignore:

git rm -rf --cached .
git add .
git commit -am "cleaning git cache"
git push

Now I have a terrible doubt. I have, for example, this in the file .gitignore

/storage
/storage/*/*

When I do git pull on the VPS, will the storage folder I have there (which is full of useful files that should not be deleted at all) be deleted? I can't afford that.

EDIT : I read contradictory responses. And that's not reassuring....

EDIT 2 : I retraced my steps in this way and everything went back to the way it was.

Locally: git reset HEAD~1 git add . git commit -m "Today's commit" git push -f origin master

On VPS: git pull

Situation restored. Thanks anyway

marco987
  • 87
  • 2
  • 14
  • `git pull` won't delete those files, but since they're important to you, you should ensure they are backed up regularly. – ceejayoz Feb 12 '21 at 16:40
  • also relevant, and possibly a duplicate: https://stackoverflow.com/questions/5798930/git-rm-cached-x-vs-git-reset-head-x – Daemon Painter Feb 12 '21 at 17:42
  • 1
    Unfortunately, the answer really is *maybe*. There have been long ongoing discussions over many years, on the Git mailing list, for what to do about this. The situation in which such deletions happen is not very common, but when it strikes, it's bad. If you have regular backups, that's the way to recover, if it does happen. – torek Feb 13 '21 at 15:11
  • Note that once the files *aren't* being saved in Git (as they shouldn't be), you do need backups anyway. Think of the backups as "what to do in case the machine catches fire, burns to a crisp, and must be replaced" (which is why backups should be stored at a separate physical location). – torek Feb 13 '21 at 15:14
  • Thank you @torek . Can I go back to the previous state (previous commit)? That's how I solve everything. – marco987 Feb 13 '21 at 15:17
  • You can; see both `git revert` and `git reset`, and note that they do different things: you need to decide whether you want to (and it is OK to) *discard* history, or just add new history that restores the previous state. It's still probably best to not-store-in-Git those things that should be not-stored-in-Git, and to do regular backups, though. – torek Feb 13 '21 at 15:19
  • Let's just say I don't care that there is any trace of this mess left! The important thing is that I return to my previous state. For example, can I do this? `git reset --soft HEAD~1` – marco987 Feb 13 '21 at 15:23
  • your question was "does it delete", and the answer is maybe. Some are good answers, other less. But your question should have been "how do I solve it"? Because apparently you are interested in that. – Daemon Painter Feb 15 '21 at 08:37

5 Answers5

1

The git pull command will delete any file or folder that is deleted by the upstream commits. That is, if you colleagues have deleted some files, then these will be deleted in your local copy. It does not matter if these files are in .gitignore.

Anyhow, you should not panic. Unless you delete the history, these files can be recovered. I am assuming that these files were versioned in your git repo.

Still, if you delete the history, with the git reflog command you can restore old commits that do not exist anymore (unless the garbage collector has been active).

Daemon Painter
  • 3,208
  • 3
  • 29
  • 44
carnicer
  • 494
  • 3
  • 9
  • assuming that the content of those files is never updated on the VPS working copy, which apparently doesn't push nor commits, and might be content generated by the users of the website and so on and so forth. – Daemon Painter Feb 12 '21 at 17:32
  • Please help me understand it better? I am a junior developer – marco987 Feb 13 '21 at 10:02
  • Learning git requires time. I needed practice to get used to branching, merging and remotes. You may want to practice all these commands with some tutorials and with some dummy repos. I just learned that a project called gitless exists, which seems to provide a simpler UI over git, while being compatible with it. – carnicer Feb 16 '21 at 07:49
1

With that sequence of commands? The files will get deleted because the branch you are merging is getting rid of them. Sure, when the files were deleted, the person who does it tells git hey, keep the files on my working tree (with git rm --cached) but when a merge of that revision is attempted on another repo (say, with a pull), git won't be able to know that the files had to be kept in the working tree and so they will be gone.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
0

I performed such things many times a specially lately. Nothing were ever deleted.

This

git rm -rf --cached .
git add .
git commit -am "cleaning git cache"
git push

Only deletes files from git index.

IVN
  • 241
  • 1
  • 3
  • 13
0

TLDR; yes, you are going to remove the content you just removed, when you git pull from the VPS.

Let's analyze the situation here.

Every time I made a change locally, I pushed to the repository and from the VPS where the site is (via SSH) I did git pull.

So this goes three ways, GitHub is your central repository, you develop locally, back it up remotely on GitHub for distribution, and pull from the VPS to deploy the website.

I realized that some folders previously placed in .gitignore were actually not being ignored.

This is a normal and well documented behavior. If the files were already added and committed prior their introduction in .gitignore, they'll continue to be tracked. Also note that on the VPS, a git pull command won't remove those file, but simply continue to ignore them.

Then I saw that it was possible to clear the git cache. I did it that way and the next push actually ignored what I wanted it to ignore:

git rm -rf --cached .
git add .
git commit -am "cleaning git cache"
git push

You have now created a commit to specifically remove those files and stop tracking them, since they are added to the -gitignore. From this point onwards, if you put a file which matches the ignore parameters in the working folder, it will be ignored. Not deleted, simply not mentioned for version control.

I have, for example, this in the file .gitignore

/storage
/storage/*/*

When I do git pull on the VPS, will the storage folder I have there (which is full of useful files that should not be deleted at all) be deleted?

One should point out that, since /storage contains /storage/*/*, the second line in your .gitignore is redundant. But, alas. Back to the matter at hands: it doesn't matter on the content of .gitignore. As we already know, those files will be ignored.

However, caveats are due:

  1. If you committed the removal of those files, then those files will be removed (it appears though you did this).
  2. If you clone the repository a-new on the VPS, that is if you purge your current website and git clone from GitHub, you'll probably never get the content of storage this way.
  3. It seems to me that you don't want to put storage under version control, and yet the data is important to you. Back it up somewhere else.

The point is not .gitignore in your case, but rather the fact that you explicitly committed the removal of those files.

Now, let me assume that the content of storage is being updated only on the VPS and never committed nor pushed to GitHub. More caveats:

  1. git doesn't know about that content
  2. If you delete it, will be gone forever, from a git perspective
  3. If you are in this situation because the content was already committed once, and it never changes, and I am correct in both assumptions, then you should be able to find it in your repository history in a previous commit. But this goes a little bit out of scope for the answer.

After reading carefully the other answers, I'd like to link the docs (emphasis mine):

Remove files matching pathspec from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.)

And you queued that with recursive, force, and cached:

Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.

But, you override the up-to-date check with force.

Daemon Painter
  • 3,208
  • 3
  • 29
  • 44
  • Right now, yours is definitely the most articulate answer. But I didn't get it. Or rather, I understood some of the steps, but I didn't understand how to apply it to my case. – marco987 Feb 13 '21 at 09:39
  • @marco987 then by all means: I am a human being, ask questions and I'll be glad to clarify. I don't write papers for the sake of it. – Daemon Painter Feb 15 '21 at 08:35
-1

No, the files will not be deleted with git pull.

If you make this:

 git reset --hard origin/master;

then yes, the directory will be set the same as in the repository and the storage directory will be emptied.

But please, make backup. You should not have a directory that you cannot afford to lose.

JoseLinares
  • 775
  • 5
  • 15
  • well, if I commit the removal of a file, the file is removed upon the next git pull... You may test this by moving a file into a folder and commit the operation. It should be recorded as a deletion and the addition of a new file. – Daemon Painter Feb 12 '21 at 17:29