Re: Bug-ish: CRLF endings and conflict markers

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 11 Jan 2007, Shawn O. Pearce wrote:
> 
> > That said I don't really care about this problem that much. The problem 
> > that I care about is its far too easy to convert the lineendings in a 
> > file (e.g. CRLF->LF, LF->CRLF).  This causes the entire file to differ, 
> > making merges very difficult.  I really should just fix it (in the one 
> > place where it matters to me) by modifying the pre-commit hook to look 
> > for such a case and abort.
> 
> Why not just introduce a config variable, and do the conversion in-flight?

That's a lot of work and goes very much against the Git mindset that
we never alter content, just store it as-is.  If Linus sees this
thread I'm suspecting he will jump in and point out that altering
content transparently like this just wrong.  I think he's stated
something like that in the past.  :-)

All I want is to make the user realize what they have done.  "Hey
dummy, you just changed the entire file and the only difference I see
for most lines is simply the addition/removal of a CR.  You shouldn't
do that!".  The pre-commit hook is the perfect place for that.

It should be pretty easy to do.  For every line in the diff stuff
it into a perl hash after removing any trailing CR.  If both an
add and a delete for the exact same line of text appear in the diff
(with the only difference being the CR on the end) and the number
of such lines number is at least 50% of the modified lines in the
file, something's amiss.  Smack the user and tell them to fix the
file.
 
> Or, alternatively, do the merge ignoring white space? (Of course, this is 
> somewhat pointless when merging whitespace fixes...)

Lets not go down that road.  That's just asking for trouble.
And it sounds like a lot of work from what you pointed out in
another message.

-- 
Shawn.