2

My coworker has an issue where his commits keep including every single file in the repository instead of just the changed ones. The file contents are literally identical, but the changeset in our private Github repository shows all of the previous version's lines removed and all of the "new" version's lines added, even though there was actually no change at all. This is also happening with binary files and again, the actual files are identical from the first version to the next.

What would cause this and how can it be prevented?

Nathan Ridley
  • 33,766
  • 35
  • 123
  • 197

2 Answers2

6

Since Git identifies files by hashing their contents, truly identical files will never be stored twice.

What you are seeing may be a symptom of line ending differences between repositories. It’s hard to give precise advice without knowing more about your setup, but reading about Git’s config options core.autocrlf and core.safecrlf may probably help you.

scy
  • 7,132
  • 2
  • 27
  • 35
  • 4
    Actually, I should have mentioned that not using autocrlf at all and instead convince every contributor to use a sane text editor that will not mess up line endings would be the _real_ solution to these kinds of problems. – scy Aug 11 '10 at 14:57
  • Agreed, along with a convention about line endings for new files. And really, as far as I know, most programmers' editors are already sane - though I only know for sure about vim, emacs, and eclipse. – Cascabel Aug 11 '10 at 15:36
  • 1
    Some people edit their files on windows via samba or some other network file sharing; some use windows editors and windows git clients; others use unix editors and unix clients. It's pretty easy for line endings to become out of sync, unless someone lays down the law and says "Here are our coding standards: UNIX LINE ENDINGS ONLY. or else!" – Ether Aug 11 '10 at 16:16
0

I'm guessing, but I bet that the line endings are different between your working directory and your commits. This answer should give you what you need to fix it.

Trying to fix line-endings with git filter-branch, but having no luck

Community
  • 1
  • 1
kubi
  • 48,104
  • 19
  • 94
  • 118
  • Surely there must be some way to have git not count line ending differences? – Nathan Ridley Aug 11 '10 at 14:41
  • @Nathan Ridley: This is precisely the problem autocrlf is intended to address. – Cascabel Aug 11 '10 at 14:45
  • @Jefromi - so setting autocrlf to true should solve my problem? – Nathan Ridley Aug 11 '10 at 14:47
  • @Nathan Ridley: So reading carefully what autocrlf does and making sure it's set *consistently* for all users should solve your problem, possibly in combination with some filter-branch to fix mistakes already committed. Look at the question kubi linked, as well as this question and the links from there http://stackoverflow.com/questions/2016673/definitive-recommendation-for-git-autocrlf-settings I agree with VonC that you should ideally set it to *false* and make sure everyone's editors use linux line endings. – Cascabel Aug 11 '10 at 14:50