0

I have my Git repository hosted at github.com. I would like to push updates and such to github.com and then log into my Windows server and do a git pull to get my changes (that are verified to work on my local machine. Ideally I should have another server setup as my local machine settings are different from the live server. But I'm cheap.).

It seems like whenever I try to do a git pull on the server, the files seem to get modified somehow since the last pull. And so I am unable to get the update as git says I need to commit my local (Windows server) changes.

How can I use git like I want to? Or is there a better way?

Chris
  • 1,731
  • 4
  • 18
  • 28
  • 1
    That is not how it should be working. Are you sure you aren't modifying files that are included in the Git repository? For example, your database and other things that are dynamic are not contained the the repository.? – alternative Jun 09 '10 at 22:30
  • What is the nature of the change? Is it a "mode change" (difference between 644 and 755)? – Yann Ramin Jun 09 '10 at 22:38
  • if `autocrlf` is involved, see http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlftrue-in-git/2825829#2825829 and http://stackoverflow.com/questions/2333424/distributing-git-configuration-with-the-code/2354278#2354278 – VonC Jun 10 '10 at 03:47

2 Answers2

1

Is it possible you change the git core.autocrlf flag after cloning the repository?

Issue 83 on the google code project form msysGit goes deeper in on this topic.

If that it the case, doing a new clone should fix the problem (as long as the flag is not touched).

Peter Tillemans
  • 34,983
  • 11
  • 83
  • 114
  • I would always strongly suggest running with autocrlf off. Its evil and shouldn't be the default in msysGit. – Yann Ramin Jun 09 '10 at 22:46
  • I agree, I weeded out all programs which could not deal with UNIX line endings in text files from my Windows systems a long time ago. I much prefer that my Word/OpenOffice/Images etc remain intact than that I can edit my files in notepad. – Peter Tillemans Jun 09 '10 at 22:59
1

Are you using the Git GUI or Git Bash?

For some reason, Git GUI on Windows does not have core.autocrlf configured by default when cloning a repo, even after attempting to set core.autocrlf in the global configuration using Git Bash (might be GUI setting or environment issue that if corrected, could make the GUI a viable option).

Also, for some reason Git GUI in some cases seems to think it's better to make a master branch in the new repo rather than using the existing branches in the repo being cloned. After Git GUI makes this master branch, it then does a checkout of this master branch immediately after the clone. Since you're using a pull and having issues, this might only have been the issue if you initially cloned using Git GUI.

Most likely, it you're core.autocrlf setting. The following steps should set up a repo for you and ensure the proper crlf settings...

Steps to Clone without Modified File Garbage:

Using the following command in Git Bash from the Windows folder clones the repo as a full copy without making an initial checkout of a branch.

git clone –n --no-hardlinks

By not checking out the branch when cloning, you now have the ability to verify your .git/config file has the correct settings for autocrlf before checking out the branch. You might want to add safecrlf just to be safe ;) To update these settings crlf settings, execute the following commands from your newly cloned Windows repo using Git Bash:

git config core.autocrlf true

git config core.safecrlf warn

To verify the changes made it correctly, open your .git/config file and you should see:

autocrlf = true

safecrlf = warn

PLEASE NOTE: You want autocrlf set to input in your Linux repo... setting to true is for your Windows repo. Also, I only use warn on safecrlf, you may want to use true.

Once you have your crlf configuration set, you can finally checkout the branch normally using git checkout .

If there are still modified files in your new local Windows clone, it's likely due to having CRLF instead of LF in your Linux repo. This can be verified by using a hex editor on the files in your Linux repo and searching to see if 0D0A is present, or if everything is just 0A as it should be.

Hazok
  • 5,373
  • 4
  • 38
  • 48