I am using Git to cooperate with other users, but today I cannot get the latest change on some files using "git pull
", and I cannot see the changes in "git log
".
What could be the issue?
I am using Git to cooperate with other users, but today I cannot get the latest change on some files using "git pull
", and I cannot see the changes in "git log
".
What could be the issue?
what worked for me is ,
.git
folder.git
from other repogit checkout
Before Removing , You can try
git fetch --all
git reset --hard origin/master
You will need to replace master
with the appropriate branch, which now defaults to main
.
What worked for me,
git reset --hard origin/master
It showed me that some file names were too long for git to pull them from my repo and hence the mismatch and incorrect builds.
So I ran following to fix and did a hard reset again.
git config --system core.longpaths true
Thankfully it worked.
In my case the issue was me having an index.lock
file in my .git
folder. I removed that, and pull worked.
Check your current branch.
git status
git branch
If you are not in a branch, you are in a detached HEAD mode and git pull
wouldn't merge anything.
git log --all --branches
That git log
will help make sure you see if there are any new commits on fetched branches (that is, the remote tracking branches).
I use that git log alias to display those commits as a graph.
You could have an unfinished merge that prevents the pull. Check if you have a commit in progress.
It worked for me:
Instead of
$ git pull
Use
$ git pull [remote] [local-branch>
I just wanted to add another case where this could happen. I was using a sparse checkout. For some reason I had a directory in my working tree that I thought was included in the sparse checkout (I thought it was listed in .git/info/sparse-checkout
) but wasn't (I had removed it from .git/info/sparse-checkout
for some reason I now forget.) So it was just being ignored by pull
or checkout
or reset
or any other commands. It was very confusing until I started replicating the sparse checkout configuration in a new, fresh clone and realized the error.
This would only happen to you if you are using a sparse checkout. If you are not using a sparse checkout, it couldn't happen. (Check git config to see if sparseCheckout is enabled, and check for the existence of .git/info/sparse-checkout, but you would know if you were doing this since I think it has to be set up manually by the user anyway.) (Google it if you're curious what it is-- its just a simple mechanism to omit files and directories from a checkout that would otherwise be tracked/pulled/fetched etc.)
I had the same issue with our enterprise Gitlab repo which recently changed from HTTPS to SSH. As my repo still used HTTPS, any git pull
got silently ignored.
After changing the origin to SSH, everything went smooth again.
git remote set-url origin git@gitlab.yourdomain.com:username/repo.git
(To get the SSH URL just click the "Clone" button in your Gitlab/Github web interface and select "Clone with SSH")
There are 2 possible sceanrios:
1. If you have any account in Bitbucket, gitlab and etc.
You might have to synchronise with your fork directory first and then perform git pull on your local branch. Basically you have to rebase your fork copy to get in sync with remote master and perform git pull in your local copy.
2. Just try to rebase your local work copy to be in sync with remote master.
git reset --hard origin/master
works for me but you have to go inside the folder and then use this command not only on the parent folder.
for me it was commits that I made locally. These commits modify something I want to pull. So git pull doesn't get the file from origin
For me the FETCH_HEAD file did not have all the branches, because my newest branch was not tracked So I:
To force delete a branch (from outside that branch)
git branch -D <branch_name>
To create a new branch from a given branch
git fetch origin <remote_branch>:<local_branch>
To make the remote branch a tracking branch
git push --set-upstream origin <branch_name>
then to test it with git fetch
, I noticed my FETCH_HEAD file was now correctly updated.
In my case, the FETCH_HEAD was broken somehow.
When I checked it using git branch -avv
, my branch was tracking the wrong commit. Even using a commit from months before.
I solved it using git reset --hard [commit hash]