1

I started to see that in some commits of my colleges, the files they changed a few lines are "marked" as if they modified them completely. We are losing the possibility to use Git Blame on these files to see "who changed which line"

I can't figure it what they are doing "wrong" to override the file and to make Git lose the capability of Blame, could it be related to rebasing? or rebase -i and squashing?, is it a bug related to a Git version?, they use Linux and I use Windows I created a secondary account on our git repository (Assembla) and tried to reproduce this but I couldn't

Before

before commit, or previous version

After

after_commit

FiruzzZ
  • 661
  • 1
  • 6
  • 21
  • Please don't edit your answer into your question. Instead, post it as an answer so that others may vote on it. – Robert Columbia Oct 07 '20 at 18:28
  • @RobertColumbia I didn't answer my question, just added some knowledge and the cause of the problem but not how to solve it – FiruzzZ May 06 '21 at 23:51

1 Answers1

3

It's more than likely because the files are getting an EOL-format change. Why? It could be because the developers are not being careful with that (IDE messing them up?)... or, most likely, that you have set up git to change EOL format of the files (core.autocrlf rings a bell?). You can still see through those revisions using git blame -w. My best advice: rewrite history of the branches so that the EOL format never happens (it has a price tag.... in terms of effort, just in case)... and do not set up git to change eol formats.

PS I am writing a guide on how to deal with conflicts and I am currently working on a script to be able to, kind of painlessly, rewrite the history of a branch so that the EOL format changes are corrected.... but it will be ready in a few days till I release it. I can write an update here if you want. The guide is here http://www.ezconflict.com/ (no tracking, no monetizing).

PS2: Script to correct EOL changes. It assumes (actually checks) that what you are asking to correct is a straight branch, no merges. Provide the last revision that had correct EOL formats, the tip of the branch (branch name, or revision) and the list of files that need to be corrected.

https://github.com/eantoranz/conflict_book/blob/main/scripts/correct_eol.sh

By the way, still hot from the oven. Use with caution (it won't move any branches, just in case).

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • thanks for that `blame -w` but I am pretty sure that I need `core.autocrlf`because I use Windows and the CRLF need to be replaced for LF, Git Docum suggests to do this, and the installation of Git also recommend this setting on Windows environment. I will check with my team, because not always happens and sometimes affect some files and another not – FiruzzZ Oct 07 '20 at 14:54
  • If you don't use it (say, do not tell git to change any EOL formats) then git won't mess with the files and then it's up to the text editors that you use for the files to not change the EOL format (decent editors keep the preexisting EOL format of files, no matter the OS). – eftshift0 Oct 07 '20 at 15:57
  • in some cases, Netbeans apparently change them, but more important, is it a way to revert this? can I restore these files? I read about `add -renormalize .` but it really didn't change much, just 20/900 files were affected, and in these 20 I can't use `blame` without -w anymore – FiruzzZ Oct 08 '20 at 11:56
  • I will have a working prototype of my script during the weekend. – eftshift0 Oct 08 '20 at 12:55
  • Just added the URL to the script to correct the EOL format changes. – eftshift0 Oct 09 '20 at 05:27
  • 2
    Just pushed the explanation of the consequences of busting EOL-format on files on my guide on merge conflicts, if anybody cares to read it (no tracking, no monetizing): http://www.ezconflict.com – eftshift0 Oct 11 '20 at 06:42