Why is Git falsely noting that my files are up-to-date?
I have two folders—A and B—in my file directory that link up to the same Git repository.
I created a file in folder A called index.html
. I then create a different file also called index.html
in folder B. I then add index.html
in folder B, commit, and push B's contents.
When I pull from folder A, Git claims that my files are "Already up-to-date." However both folders clearly have different index.html
files. What is going on?
git pull
's job is to fetch
new commits and merge
them into the current branch. If the current branch is not outdated compared to the one you pull from, pull will say Already up-to-date.
even if you have local changes in your working directory. git pull
is concerned with branches, not the working tree — it will comment on the working tree only if there are changes which interfere with the merge.
Your description is insufficient to explain why it's not objecting to the existing index.html
, but you should not take Already up-to-date.
as meaning git thinks you have no changes. Instead, use git status
to obtain a summary.
In order to understand the state of your branches, git branch -v
is useful (it shows the commit ID and relation to each branch's upstream branch), or gitk --all
for a graphical view of all commits.
If I understand correctly the following script should reproduce your issue:
mkdir test cd test git init --bare test.git git clone test.git a git clone test.git b echo a > a/index.html echo b > b/index.html cd b git add index.html git commit -m add git push origin master cd ../a git pull
The last git pull
prints:
remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/cyrus/tmp/test/test * [new branch] master -> origin/master
And the content of index.html
has been silently overwritten:
cyrus:~/tmp/test/a$ cat index.html b
Remember one thing about git
- it tracks content, not files.
Internally, all of the content the repository keeps, is a blob somewhere. What you consider to be a file, git
considers to be a name pointing to a blob. What you consider to be two files with the same content, git
considers to be two names linked to the same blob. So, since none of the blobs have changed, then the repository has not changed.
You're expecting git to work like your filesystem does (or maybe like most other version control systems do) - git
is actually more space-efficient in this regard. The book explains this concept pretty well - specifically, the Git Object Model.