6

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 log does not show the commits that should have caused these changes... the changes just pull without the log notes so it believes it's out of sync.

The result of the pull shows "needs update" messages for each file.

doublejosh
  • 5,548
  • 4
  • 39
  • 45
  • 2
    Are you using git on windows? Usually these things happens when the conversion between lineendings (crlf/lf) don't work correctly. What is the output of git diff? If it's only lines replaced by identical lines it's most likely the line ending that is changed. – Stein G. Strindhaug Jun 07 '11 at 09:16
  • Nope. On on mac. I should have also provided that this is a simple master to master pull. I've been working with this repo for some time. – doublejosh Jun 07 '11 at 18:19
  • I've seen this behavior when there's a conflict. Git attempts (and fails) to merge the remote changes, and instead shows ALL of the changes (including the aforementioned remote changes) as one big local change. – Chris Eberle Jun 07 '11 at 18:27
  • Believe I may have tracked this down to a permission problem during the pull (a change to my protected settings file.) I get a "error: unable to unlink old 'MY_SETTINGS_FILE.php' (Permission denied)" However, even with the problem the changes come through and cause this weird mismatched. Having to do a lot of `git reset --hard` and `git clean -fd` to repull and clean things up. Still can't figure out how to allow this file to change as I've done chmod on the file and my .git folder – doublejosh Jun 07 '11 at 20:55
  • Actually in a funny place now where I can't: change the file permissions or it will actually be a change I need to commit OR pull because the permission denies it. Cripes. – doublejosh Jun 08 '11 at 00:16

2 Answers2

6

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

Community
  • 1
  • 1
doublejosh
  • 5,548
  • 4
  • 39
  • 45
  • BTW: This related to file permissions. Believe that sometimes Git is doesn't think it has permissions and stalls even thought the actual change did take place... so it gets into an incorrect state. – doublejosh Feb 27 '12 at 21:36
5

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Sorry and thank you, but I don't think this is it. I'm on a mac and the changes that come across are the actual changes to the files (real edits) but the git log does not update with the history so it complains as out of sync. OOORRR maybe I just don't understand your answer yet :) – doublejosh Jun 07 '11 at 18:20
  • @doublejosh: no, you seem to have understood my answer just fine. Maybe Chris's comment will help? – VonC Jun 07 '11 at 19:11