Git on Windows vs Git on Unix/Linux

Okay, so I’ve been trying out Git for a week or two, and it’s taken me a bit to get the hang of it (because I’m not used to operating from the command line). However, I purchased Pro Git, because I was looking it up online so often, and have been fairly good since.

However, now I’m trying it on Windows. I personally use a MacBook, and run Windows in VMware Fusion, so I had been running Git from the Unix terminal. However, in order to make sure the programming team can use it, I need to test it on Windows. I chose msysgit, rather than cygwin, because it looked simpler to install and use.
So I install it and get it running, and cd to my repository, and run git status.
And it tells me every single file in my repository has been modified.
(I haven’t tried committing, because I don’t want to corrupt my repository.)

So I go back to the Unix terminal, and try git status, and it tells me there have been no changes.

Will this happen every time I switch between Windows and Unix? Or is there something wrong with my install?

Would I be better off with cygwin?

I just exported a git repo from my Windows box to my Ubuntu 9.10. Works perfect for me, probably your config… Git has an IRC channel…

#git
irc.freenode.net

After all Git was created by Linus Torvalds which is one of the core fathers of Linux - I would think it would work better on Linux.

most likely
vs
issues
use Notepad++ (or equiv) and see if it is unix or dos/windows encoded
My expertise is SVN (and subclipse, no Command line needed) but you might want to check the mode: text or binary. It needs to be text or
will not be translated to
automatically (and vice versa and same for \r mac)

My guess is that it is because of the difference in windows / unix line endings and automatic conversions because of that difference. See http://code.google.com/p/msysgit/issues/detail?id=271

If that’s the case the relevant setting would be core.autocrlf = true

I’ve been trying that, and it doesn’t seem to make a big difference.
So, I tried committing it, and we’ll see if it creates any problems with LabVIEW.