8

Usually when I have to commit my daily work I use: 

git add * 
git commit -m "my commit message"
git push origin master

This commands are very base. But I've notice that deleted file are not deleted from my remote repo. In fact if I delete a generic file "example.txt" (on my local folder)after push changes on Github the file still remain.

Tecnically with git add * the deleted files should be recognized, or not? How can I remove from my remote repo the deleted file?

Thanks

Arpit Solanki
  • 9,567
  • 3
  • 41
  • 57
Aso Strife
  • 1,089
  • 3
  • 12
  • 31
  • You have an answer below, but I would recommend that you just use `git status` and then copy/paste the files which you want to stage for the commit. This will force you to review what you are actually doing, rather than blanketing with `git add .` – Tim Biegeleisen Aug 13 '17 at 14:23
  • Look at this link for a deep understanding of git add arguments: https://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add – Samuel Aug 13 '17 at 17:26

3 Answers3

6

git add * does not track the deleted files it only includes modified or new added files. You have to use

$ git add . --all

to track all files (deleted files included)

Refs: docs

Arpit Solanki
  • 9,567
  • 3
  • 41
  • 57
  • Try `git status` and check the tracked files. The method mentioned above is pretty standard mentioned in docs. – Arpit Solanki Aug 13 '17 at 14:27
  • Using `git status` I read: Sul branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working tree clean – Aso Strife Aug 14 '17 at 13:19
  • You have nothing to commit now. All your changes are in your remote repository now. Do some changes or delete a file if you want to try the method. Then use the method above to add and commit then push and check the changes on remote repository – Arpit Solanki Aug 14 '17 at 13:30
  • 1
    @ArpitSolanki `git add . --all` does not track deleted files. What it does is makes sure the index matches the working tree exactly. If the working tree is missing a file, then that file will be removed from the index. The default behaviour (without the `--all` flag) is to only stage file modifications, and file creations, not deletions. – instantepiphany Aug 15 '17 at 12:38
  • from docs of git when --all is used `all files in the entire working tree are updated `. [This link](https://git-scm.com/docs/git-add#git-add---all) will certainly help you clear your doubt. One more point of having --all option is that you don't always delete files manually sometimes a program deletes file in your repo. So certainly you can't use rm that time. You have to go for --all option. @instantepiphany – Arpit Solanki Aug 15 '17 at 12:43
  • @ArpitSolanki to be clear, I was pointing out that the `add` command does not **track** deleted files. It removes them from the index (which is in a way, the opposite of tracking files). – instantepiphany Aug 15 '17 at 12:47
  • yeah it does if you use add with --all option – Arpit Solanki Aug 15 '17 at 12:47
  • Regarding your quote of the scm docs, that part is not written especially clearly - it doesn't mean that the files in the working tree are changed, it means that git checks all of the files in the working tree for updates, and if it finds any, it copies those to the index. – instantepiphany Aug 15 '17 at 12:48
  • A better explanation can be found on this page: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository Look for the heading "Removing Files", and note where it says: "To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that, and also removes the file from your working directory so you don’t see it as an untracked file the next time around." – instantepiphany Aug 15 '17 at 12:50
  • we all know what git rm does but that's not the point. Suppose If your programs itself creates and deleted files then you won't be able to use git rm. --all is a generic way. Under the hood both persists same functionaltiy – Arpit Solanki Aug 15 '17 at 12:52
  • I am not going to comment further as this is verging on debate and not helpful to the original question. `git add . --all` does *not* track files that have been deleted in the working directory, in fact it *untracks* them. That is what I am trying to clear up. Have a good day Arpit! – instantepiphany Aug 15 '17 at 12:56
6

git add does not by default record file deletions. Passing the --all flag will tell it to also look for deleted files.

As Tim Biegeleisen suggested, it is worth combining the use of git status to see the changes in your working directory, and then using git add <filename> to add them one by one. This way you have more visibility and control over what you add to the staging area. You can also use git add <directory> to add a whole directory at once, or git add -i which will ask git to walk you through each file change and let you choose to stage it or ignore it.

Arpit Solanki
  • 9,567
  • 3
  • 41
  • 57
instantepiphany
  • 179
  • 8
2

Not exactly, from this web

Use git rm

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…​

Description:

Remove files 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.) The files being removed have 
to be identical to the tip of the branch, and no updates to their 
contents can be staged in the index, though that default behavior can be 
overridden with the -f option. When --cached is given, the staged content 
has to match either the tip of the branch or the file on disk, allowing 
the file to be removed from just the index.
Christopher Díaz Riveros
  • 275
  • 1
  • 6
  • This is the correct answer. However, I sense @aso may expect expect there to be NO TRACE of the file in the repository. It will remain in the 'history'. The `git rm` and then commit simply changes the *state* of that commit (point in history). – Thom Parkin Aug 14 '17 at 15:09
  • @ThomParkin You might want to look into git docs you will see that both rm and add with --all works for deleting files and updating into remote repos. [this](https://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add) will be helpful also – Arpit Solanki Aug 14 '17 at 15:48
  • 1
    @ThomParkin you almost have it - `git rm` doesn't change the state of the commit when the file was added. It records a files removal in the index/cache/staging area. Then when you run `git commit`, the new commit removes that file from the repository. However, you make a good point about it still being in history - you wouldn't want to just `git rm` a file containing a password, for example, as anyone could see that file by looking (for example) at the parent of the commit generated after running `git rm; git commit`. – instantepiphany Aug 15 '17 at 12:35