Upon pull (into a clean production-type repo) all the changesets come across and cause the files to appear modified and needing a commit. The git lo
As illustrated in this Git project, this can happen when Git tries to adjust eol style for projects developed on Unix, and cloned on Windows:
via msysgit Troubleshooting
run command in git bash:
git config --global core.autocrlf false
if this is not done then git svn rebase reports "needs update" thinking that changes have been made to the source May run into troubles with the commit
See this SO answer for more.
How I got out of the mess:
As I kept pulling to test my solutions I had to make use of...
git reset --hard
which moves you back to the most recent commit in the log.
git clean -fd
which kills off the untracked files since the more recent commit in the log.
Eventually I decided I needed to change the offending settings file to chmod 777
and commit the permission change. Another option would have been to change Git into permission agnostic mode with git config core.filemode false
Read more here: How do I make Git ignore file mode (chmod) changes?
Then I did a pull to merge the changes and have the log update along with the files, changed the permission of the offending file back to 644 and commit that... and pushed it back to the working master (glad that's allowed.)
Seems like this is a bug that having a permission failure allows the file changesets to be merged but the log history doesn't reflect the commits!!!
BTW: My git --version
is git version 1.5.6.5