12

I have my personal small git repository on my laptop. I have just commited the changes and checked that I have nothing to commit - every staged and modified file has been commited.

After that I have copied all the files from this repo to another location and boom! I have uncommitted changes.

I believe I am missing some fundamental git rules. Can anyone suggest me on that ?

CharlesB
  • 75,315
  • 26
  • 174
  • 199
Patryk
  • 18,244
  • 37
  • 110
  • 212
  • Do you intend the new copy to be a git repository as well? – bluesman Jul 16 '12 at 14:29
  • 2
    You should include the information that the original repo was on Windows and the copy is on Ubuntu. That makes a big difference. Given this info, I believe parrhoyts' answer is correct. – suvayu Jul 16 '12 at 14:31
  • Does `git diff` show you actual differences? Or are you just seeing `git status` saying you have changes? You might be running into the fact that the index stores some metadata about each file - the copy has different timestamps than the original, so `git` might report that those files no longer match what the index thinks should be there, even though the contents of the files may still be identical. – twalberg Jul 16 '12 at 15:32
  • @twalberg `git diff` shows that whole files are different - marking all of the lines with `+` and again with `-`. I assume that the problem with line endings. – Patryk Jul 17 '12 at 12:17
  • Facing the same problem, I simply stashed every file sees as modified (the whole app actually) and then trashed it. – theFreedomBanana Jan 07 '16 at 09:28

6 Answers6

14

What I did, run

git diff | grep -B 2 @@ | grep +++

to get the actually changed files, then do revert on all others

xlecoustillier
  • 15,451
  • 14
  • 56
  • 79
Erik Romson
  • 141
  • 1
  • 2
  • Worked for me. Shows the files that were actually changed. Then checkout the ones that are listed via git status that don't appear in the git diff – Ian Lunn Jun 21 '14 at 13:44
  • that didn't work for me for some reason, but I was pretty confident no other whitespace changes would exist, so a `git diff -w` did the trick – Hashbrown Feb 15 '21 at 04:26
10

Your files on windows probably have carriage-return line-feed line endings and you likely have core.autocrlf true on your windows box. Don't copy it like that between different platforms. Instead create a new git repository on the linux box and pull from the the Windows box. You can either use git bundle or git daemon on the Windows machine to expose the repository. Or you could make a bare repo on the linux box and git push --mirror to it from the Windows machine then clone that where you want the final version to end up.

Or - quite likely you can already just do a git reset --hard HEAD and fix it on the linux box as-is. Possibly you should delete everything except the .git folder first to ensure a completely clean working tree.

patthoyts
  • 29,437
  • 2
  • 54
  • 84
2

Do the permissions between the folders change? Git will register the change of permissions.

leighman
  • 191
  • 6
  • 1
    Well I don't know exactly what do you mean but I have copied files from Win7 machine to Ubuntu if that matters. – Patryk Jul 16 '12 at 14:15
  • Which file permissions does git track? [This question](http://stackoverflow.com/questions/1071241/how-does-git-handle-folder-permission) suggests it doesn't. Where does your information come from? – simont Jul 25 '12 at 10:53
  • It tracks the executable bit which I think can be set or unset automatically if you access Windows file systems from Ubuntu/linux – leighman Sep 17 '12 at 14:00
  • This is correct. It happens due to [permission changes](https://github.com/Microsoft/WSL/issues/184/#issuecomment-209777689). – Sujit Kumar Singh May 27 '19 at 05:40
1

Copying from Windows to Linux introduces a difference in file rights, these changes are also tracked by git.

Peter van der Does
  • 12,574
  • 3
  • 34
  • 42
1

I am facing the same problem. However I have copied files from the host linux system to a Virtual Box guest system. Some links get deleted, while some file permissions got changed, which I could fix by doing git config core.filemode false.

Prachee
  • 11
  • 1
1

If you have nothing on stash to lose, do:

git checkout .

This will revert the working tree to your previous commit

Bruno Peres
  • 2,295
  • 1
  • 18
  • 18