Git pull says 'everything is up to date'

Question

I am working on a project with a few friends, and we are uploading everything to git. At first everything worked good, but at my local repository i deleted some files, online these files are still existing, so I tried

git pull

only, because i deleted that folders, they aren't coming back. Git says 'everything is up to date', but it isn't. Another stackoverflow-questioner had the same problem, and in a comment someone said he should use

git checkout HEAD

aand yes, there are the files i was looking for, but (I guess) that's just checking out, and they are not in my file system. How can i solve this problem?

In general: I guess there must be a command that updates everything?

Thanks!

Answer 1

You were likely getting an 'everything is up to date' because a pull is literally a fetch followed by a merge and as far as git can tell your fetch IS up to date. git reset --hard HEAD~1 does work but like Abibullah mentioned you should be careful with it. You could also git clone or pull to a new directory/repository.

Answer 2

From your comments it looks like you might have committed the deleted changes,

Try this,

git reset --hard HEAD~1
git pull origin branchname  OR git checkout HEAD

Normally, git reset --hard HEAD~1 should be used with care as it will remove your local commit by one. But if you want the deleted changes and u dont care about the modifications then this is a good idea.

I hope this helps. :)

Answer 3

Changes to your local file system that have not been committed are viewed by git as "Not having happened yet". What git is doing it managing your history. When you commit changes (adding files, removing files, changing files), you are recording that state in the history of the working copy.

What git pull and git push do are "get a copy of all the changes that have happened on the remote" and "tell the remote the changes that have happened". When you do a git pull, you are taking any commits that you do not know about locally and applying them to your repository. If no new commits are ever pushed to that remote, not matter how many times you pull, after the first time you will always receive the message that "Everything is up to date".

What it sounds like has happened is that you have made changes to your local working copy and want to revert it to a state that exists on your remote (in this case being GitHub). You have a couple of options that you can do. If you have not committed the code, what git checkout HEAD will do is revert the state of any tracked files back to the state of the last commit (you can also achieve this with git checkout -- .). What that will do is revert the files to the last commit that is on your current branch. If you have made commits that you want to remove, you can use git revert. If you look at your git log and find the first commit after the one you want to be using, you can use git revert <SHA of first commit after your good commit>, what this will do is change all the files back to the state the were in before the SHA you provided, then make a commit of that. This has the added benefit of giving you another commit to revert if the revert you just performed was the wrong step to take.

Answer 4

The key point that you are missing is that Git considers deleting a local file to be a modification to your working copy. As much as possible, Git tries not to undo changes that you have made to your working copy. When you run git pull, the remote is merged into your current branch. Since there wasn't anything to do in the merge, and therefore the merge didn't affect your modified (deleted) files, Git leaves them deleted.

When you use git checkout HEAD, you are telling Git that you want to throw away the change (undelete) the files that you deleted previously.

If you had committed the deletion of those files (therefore telling Git you wanted to keep that change), then this question would have an entirely different answer.