Hi Beat,
On Mon, 23 Nov 2015, Beat Bolli wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
