Initialize Git in a dirty directory at specific commit

Question

I have a Git repo locally and its files are uploaded on a server over FTP. I don't want to upload files one by one, so I'm trying to set up Git on the server as well. This would allow me to simply SSH and git pull the files from GitHub instead.

Since I already have the latest version of the files on the server, I want to initialize the repository at the latest commit and Git should be doing nothing with the files because they're the same. However, that's not the case:

ssh myserver
cd /path/to/project
git init
git remote add origin https://github.com/user/repo
git fetch
git checkout master

The last command outputs:

error: The following untracked working tree files would be overwritten by checkout:

...

Please move or remove them before you switch branches.

Aborting

Why does that happen? The files that Git wants to overwrite and their contents are exactly the same. Shouldn't the checkout happen without problems?

This may happen due to some changed/untracked files were in the local repo or you are in a different branch in your local repo and when you try to checkout master, it's trying to overwrite those files. Better to use `git clone` and then you can use git pull to track the working tree with remote repo. — Senal Weerasinghe, Dec 13 '19 at 12:09
When you run `git diff` you will probably see the issue in this question. Check it out: https://stackoverflow.com/questions/1257592/how-do-i-remove-files-saying-old-mode-100755-new-mode-100644-from-unstaged-cha — emremrah, Dec 13 '19 at 13:37

score 1 · Accepted Answer · answered Dec 13 '19 at 22:01

The key part of this error is the word "untracked":

error: The following untracked working tree files would be overwritten by checkout:

This is because the Git repository you have created (git init) has an index, but that index is currently empty.¹ Hence every file in your work-tree is untracked. Git doesn't go on to compare contents: it is sufficient, in Git's view, for the files to be untracked, to cause the problem.

The trick is to fill the index. One easy way to do it, given that you want the proposed next commit² to contain the files in the commit currently identified by the name origin/master, is:

git read-tree origin/master

You can now git checkout master to create branch master from origin/master, leaving the work-tree files in place.

(You can also fill the index from the work-tree as it stands, using git add. Either method is fine as long as the work-tree's files and their content actually match the content in the commit identified by origin/master.)

¹A truly empty index is very different from the situation in which the index matches the HEAD commit. With an empty index, the next commit will snapshot the empty tree. Successfully checking out an empty tree will remove all tracked files from the work-tree, and now there will be no tracked files at all.

²Except when it takes on an expanded role during merges, the index is probably best described as your proposed next commit. A git checkout operation fills in the index with the files that are in the commit you are checking out, and in the process, also copies those files to the work-tree.

We are about to fill the index from a commit without copying the files to the work-tree.

Initialize Git in a dirty directory at specific commit

1 Answers1