On 4/16/08, Nigel Magnay <nigel.magnay@xxxxxxxxx> wrote: > Why does it think in this instance that there is a change? It's CRLF > in the repo, it's CRLF in the working tree, and the checkout in either > mode ought to be identical ?? We got quite confused by this here too. I'm pretty sure git's autocrlf feature is buggy, as you've noticed. Combined with that, svn has its *own* kind of autocrlf feature (svn:eol-style property on each file) that acts completely differently. As an added bonus, I don't know if you've run into this yet, but cygwin's "patch" command seems to unconditionally strip CR from patches *before* trying to apply them at all, *even if* the target file is CRLF, so patches just never apply to CRLF files ever. Ha ha! I managed to make the two systems stop stomping on each other, in our case, by using svn:eol-style of "native" (which means when git-svn checks out the file, it gets only LF, since it seems to always claim to be Unix) and not using git's autocrlf at all. However, this isn't optimal since then Windows git users end up with LF instead of CRLF in their files, which confuses them. On the other hand, the conflicts and the random-newline-changing diffs go away, as svn fixes things up at checkin time no matter how badly they got mangled by the windows user (most commonly, they run a program that resaves the whole file as CRLF). Obviously a working git autocrlf feature would be better, but I haven't looked into it closely enough to say where the problem actually lies. Have fun, Avery -- 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
