Re: [PATCH] merge-file: consider core.crlf when writing merge markers

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 24, 2015, 08:21 UTC
Message-ID: <alpine.DEB.1.00.1511240844380.1686@s15462909.onlinehome-server.info>
In-Reply-To: <1448314332-15581-1-git-send-email-dev+git@drbeat.li>

Hi Beat,

On Mon, 23 Nov 2015, Beat Bolli wrote:

Show 5 quoted lines

> When merging files in repos with core.eol = crlf, git merge-file inserts
> just a LF at the end of the merge markers. Files with mixed line endings
> cause trouble in Windows editors and e.g. contrib/git-jump, where an
> unmerged file in a run of "git jump merge" is reported as simply "binary
> file matches".

Wow, what a beautiful contribution!

I wonder how difficult it would be to make this work with gitattributes, i.e. when .gitattributes' `eol` setting disagrees with core.eol.

I imagine that we could use convert.c to do all the hard work, e.g. by adding a function

	const char *eol_for_path(const char *path, const char *contents)
	{
		enum eol eol;
		struct conv_attrs ca;
		struct text_stat stats;

		convert_attrs(&ca, path);
		eol = output_eol(ca.crlf_action);
		if (eol != EOL_CRLF)
			eol = EOL_LF;
		else if (!*contents || (crlf_action != CRLF_AUTO &&
				crlf_action != CRLF_GUESS)
			eol = EOL_CRLF;
		else {
			ca.crlf_action = input_crlf_action(ca.crlf_action,
					ca.eol_attr);
			if (crlf_action == CRLF_GUESS && stats.cr > stats.crlf)
				eol = core_eol;
			else if (stats.crlf)
				eol = EOL_CRLF;
			else
				eol = EOL_LF;
		}

		return eol == EOL_CRLF ? "\r\n" : "\n";
	}

Of course you could also make that function return `enum eol` instead of `const char *`; that would probably make the changes to xdiff/xmerge.c less invasive (and closer to what you have already).

Ciao, Dscho