tags:

views:

58

answers:

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?

A: 

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.

http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273

kubi
Surely there must be some way to have git not count line ending differences?
Nathan Ridley
@Nathan Ridley: This is precisely the problem autocrlf is intended to address.
Jefromi
@Jefromi - so setting autocrlf to true should solve my problem?
Nathan Ridley
@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.
Jefromi
+4  A: 

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.

Scytale
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.
Scytale
@Scytale: 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.
Jefromi
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