Re: Retry conflicting merge with matching line endings?

[Junio C Hamano <gitster@pobox.com>]

skillzero@gmail.com 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.