skillzero@xxxxxxxxx writes:
> I've been running into a lot of merge conflicts due to line endings
> changing. For example, I branch from master when a file has CRLF line
> endings (incorrectly) then somebody fixes a bug in that file (still
> has CRLF line endings) on master then I realize the file should have
> LF line endings so I change them. When I try to rebase on master
> later, I get a merge conflict because it looks like every line has
> changed and it conflicts with that other bug fix.
>
> Would it be reasonable that if you get a conflict during a merge and
> the line endings of the two commits are different then change the line
> endings to match, retry the merge of that file, then apply the line
> ending change commit?
This is not specific to fixing line ending but applies any "global token
replacement" (e.g. you renamed a variable) operation in general.
Suppose the conflicted path is hello.c when you were merging branch
"other", e.g.
$ git merge other
$ git ls-files -u
100644 b040a96e50... 1 hello.c
100644 6b9c715d21... 2 hello.c
100644 1c57d4c958... 3 hello.c
You can first extract the blobs involved into plain files, apply such
"global token replacement" (be it fixing the line ending or renaming a
variable) to the common ancestor version and the other's version, and run
three-way file-level merge.
$ git cat-file blob :1:hello.c | replacement_filter >ancestor
$ git cat-file blob :2:hello.c >mine
$ git cat-file blob :3:hello.c | replacement_filter >theirs
$ git merge-file mine ancestor theirs
where replacement_filter would be whatever global replacement you did to
your version since the ancestor (e.g. dos2unix).
The "mine" file merge-file leaves will hopefully have much smaller
conflicts, as it won't have to see your line endings change. If it looks
Ok, cat it into hello.c and "git add" it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
