I\'ve had a look at all similar questions. However, I\'ve double checked and something strange is definitely happening.
On one server (Solaris with Git 1.8.1) I clon
You did not really ask an actual question, but since this is a general use case I'm using quite often here's what I do. You may try this yourself and see if the error persists.
My assumption on your use case:
You have an existing directory containing files and directories and now want to convert it into a Git repository that is cloned from some place else without changing any data in your current directory.
There are really two ways.
Clone repo - mv .git
- git reset --hard
This method is what you did - to clone the existing repository into an empty directory, then move the .git
directory into the destination directory. To work without problems, this generally requires you then to run
git reset --hard
However, that would change the state of files in your current directory. You can try this on a full copy/rsync of your directory and study what changes. At least afterwards you should no longer see discrepancies between git log
and status
.
Init new repository - point to origin
The second is less disturbing: cd
into your destination, and start a new repository with
git init
Then you tell that new repository, that it has an ancestor some place else:
git remote add origin original_git_repo_path
Then safely
git fetch origin master
to copy over the data without changing your local files. Everything should be fine now.
I always recommend the second way for being less error-prone.
For me, it had something to do with file permissions. Someone with Mac/Linux on my project seems to commit some files with non-default permissions which my Windows git client failed to reproduce. Solution for me was to tell git to ignore file permissions:
git config core.fileMode false
Other insight: How do I make Git ignore file mode (chmod) changes?
git diff -a
treats all file as text and it works for me.