2

we have some files originally created under Windows with EOL (CRLF) and others with Linux (LF), sometimes the IDE (or a bad configured Git after a fresh reinstall) changed those EOL overriding and making us lose the entire history of the files (blame is completely useless, just with -w works).

I tried tracking the last time the file was ok, before the switch of EoL and replacing it but didn't work, retrieving that file from another branch. Since the file always had minimal changes I didn't notice this problem after several commits and merges, I have a 6 months old branch with the original EOL.

How can I fix these files?

Obsidian
  • 3,719
  • 8
  • 17
  • 30
FiruzzZ
  • 661
  • 1
  • 6
  • 21

2 Answers2

1

You need to run blame with -w:

git blame -w some-file

There are other options to control this, and -w means "do not consider spaces/tabs/new line changes".

Just in case, you should not have these EOL changes in the first place. They are a pain to deal with long term.

Self-promotion warning: this "article" (for lack of a better word) talks about EOL changes when merging. It also points to a recipe to fix EOL problems... but with a few considerations to use the script.... you might develop something from that (no tracking, no monetization). http://www.ezconflict.com/en/conflictsse16.html#x80-1200003.2

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • I know the option `-w`, I mentioned it in my post, must repositories (Assembla, Github) doesn't allow this option by default either allow to use it. I am looking for a solution. you already help me once https://stackoverflow.com/questions/64246336/how-to-fix-losing-git-blame-feature-after-commit-eol-conflict but as you mentioned, it doesn't work with merged branches – FiruzzZ May 07 '21 at 14:40
  • 2
    Solution? You need to avoid changing EOL changes on revisions. If there's an MR/PR that changes EOL of a file, you reject it. – eftshift0 May 07 '21 at 14:42
  • Just read your article, great read, thanks for writing this up. I'll stop accepting PRs that change EOLs! And I'll start making sure that when I nag team members about their wrong EOLs, I do it before the branch is merged in, or just live with it if I missed it at first. – joanis May 07 '21 at 15:03
  • You can also do a single "normalize/fix all EOL" commit and if you ever hit that commit during `git blame`, skip over it (there's a blame option for this). So there are a lot of tricks for this. – torek May 08 '21 at 04:42
0

Blame uses your text conversions, so you can run any prepass you want on the content.

echo itssamsfault.c diff=demanglenewlines >>.git/info/attributes
git -c diff.demanglenewlines.textconv="sed 's,\r+$,,'" blame itssamsfault.c
jthill
  • 55,082
  • 5
  • 77
  • 137
  • hmmm... I don't know that does that script but didn't work, now I have a message ``'s,\r+$,,' is not a valid attribute name: .git/info/attributes:1`` – FiruzzZ May 10 '21 at 12:03
  • I think you must have typo'd, `'s,\r+$,,'` shouldn't be in .git/info/attributes, it's a config value, here supplied on the command line for the blame. This works for me, when I change the sed to `sed 's,$,hithere,'` the blame shows hithere at the end of every line. – jthill May 10 '21 at 12:31