I have a repository that is a fork. At some point i needed to merge changes from upstream and I did so. There were some conflicts and I fixed them. I don't remember well but I think I unstage some of the files during fixing conflicts. After everything is done I start to face something strange and i can't fix it.
The problem is there are six files always there as modified no matter what I do(checkout doesn't affect them). I thought it may fix so I removed my fork and reforked but when I clone and change branch from master to the branch I was creating pull requests I had the same issue again.
I can provide more details if needed
You have a case sensitivity issue : when git tries to checkout both files foo and Foo on disk, since your filesystem is case insensitive, one of the files "wins" and overwrites the content of the other.
Often : one of the filenames is "wrong" and you can get rid of it.
If this is your case : just run
git rm --cached Foo # the variant with the incorrect casing
and check that the file on disk is named with the correct variant of the name(*).
You also want to get the correct content for your files : you can see what was stored for foo and Foo in the HEAD commit using git show :
git show HEAD:foo
git show HEAD:Foo
# overriding the content of 'foo' with 'HEAD:Foo' :
git show HEAD:Foo > foo
# dumping into two temp files for comparison and cmd+C/cmd+V :
git show HEAD:foo > foo.tmp.lo
git show HEAD:Foo > Foo.tmp.up
Once you have sorted out how files should be named in git and what there correct content is, you can commit or commit --amend.
(*) one common gotcha: case-insensitive filesystems tend to treat mv Foo foo as a no-op, and will leave you with a file named Foo on your computer.
A quick workaround is to first rename to a temp name, e.g:
mv Foo foo.tmp
mv foo.tmp foo