10

Issue: Bitbucket shows that the entire file has changed even though I dont see any differences. And there are no merge conflicts in these files.

Details: I created a sprint branch (named "sprintbranch") and the developers created a feature branch(named "featurebranchX") from the sprint branch. I started merging feature branches back to the sprint branch as and when features were implemented. Now there are two scenarios where I face an issue:

  1. Developer creates a pull request to merge featurebranch1 into sprintbranch
  2. If there are merge conflicts, developer merges sprintbranch into featurebranch1 and creates a pull request to merge featurebranch1 into sprintbranch.

Both times bitbucket shows that the entire file has changed. And there are no merge conflicts.

When this happens, I cannot do a code review since I dont know what specific lines have been modified by the developer. Also I lose history at this point - looking back I wont be able to figure out what was implemented or merged into the sprint branch.

My guess is that the issue is with line endings. Something to do with CRLF. But when I commit my work I do see that the appropriate line endings are being used automatically (either by git or by the tool like SmartGit)

How do I resolve this so it doesnt keep happening?

Update:

I just found out that I can append a query string w=1 at the end of a url of a pull request to ignore cr lf differences.

But these files are still there in the commit and when I do merge it back, it will include those differences right?

shravanp
  • 227
  • 2
  • 4
  • 12

1 Answers1

15

Even though Bitbucket can ignore whitespace in diffs (using the w=1 query parameter), those changes will still be included in the merge.

But you can configure git to convert all line endings to either LF or CRLF. Your team should first decide which option it will be, and then set the text property in the .gitattributes file accordingly, like so:

* text eol=lf

This Github help page shows more information. (The information is for git in general, not specifically Github.)

You also need the global configuration option git config --global core.autocrlf input (Mac & Linux) or git config --global core.autocrlf true (Windows).

# Make sure you won't lose your work in progress......
$ git add . -u
$ git commit -m "Saving files before refreshing line endings"

# Remove every file from the git index
$ git rm --cached -r .

# Rewrite the git index
$ git reset --hard

# Prepare all changed files for commit
$ git add .
# It is perfectly safe to see a lot of messages here that read
# "warning: CRLF will be replaced by LF in file."

# And commit.
$ git commit -m "Normalize all the line endings"

More information is available in the Github article.

Philip
  • 323
  • 3
  • 13
Arjan
  • 9,784
  • 1
  • 31
  • 41
  • 3
    I added a .gitattributes with `* text eol=lf` (and committed it) and expected that a lot of files would automatically be modified and the line endings be fixed. That did not happen. When do the changes to the line endings get reflected in my repo? – shravanp Apr 19 '16 at 22:07
  • 1
    I guess you also need to set the (global) configuration option `core.autocrlf`, then follow the steps as described on the github help page. – Arjan Apr 19 '16 at 22:32
  • 1
    From what I understand, the issue with global config is that you have to make sure every developer adheres to it. To remove the dependency on the developer, they have the .gitattributes. But their guide does say "After you've set the core.autocrlf option and committed a .gitattributes file, you may find that Git wants to commit files that you have not modified". I tried adding ony the .gitattributes. I'll try with both and see what happens. – shravanp Apr 20 '16 at 03:30
  • 1
    Yep, I was missing the `git config --global core.autocrlf true`. Once I included that, all existing files were modified and their line endings were changed to what I had set. Thanks Arjan! – shravanp Apr 21 '16 at 20:41
  • @Arjan - could you please answer a related question ? thanks https://stackoverflow.com/questions/58442791/git-end-of-line-characters-causing-fake-diffs – Erran Morad Oct 18 '19 at 01:49
  • @shravanp - adding query string ?w=1 at the end of my PR or diff url does not work. I have a `^M` at the end of each line in the PR. – Erran Morad Oct 18 '19 at 01:54