Re: crlf with git-svn driving me nuts...

[Dmitry Potapov <dpotapov@gmail.com>]

On Thu, Apr 17, 2008 at 12:07:27AM +0100, Nigel Magnay wrote:
> >  > The bit I really don't understand is why git thinks a file that has
> >  > just been touched has chnaged when it hasn't,
> >
> >  Actually, it did change in the sense that if you try to commit this
> >  file now into the repository, you will have a different file in Git!
> >  So, it is more correct to say that Git did not notice this change until
> >  you touch this file, because this change is indirect (autocrlf causes
> >  a different interpretation of the file).
> >
> 
> Okay - at the very least this behaviour is really, really confusing.
> And I think there's actually a bug (it should *always* report that the
> file is different), not magically after it's been touched.

I don't think there is a simple way to correct that without penalizing
normal use cases. Usually, people do not change autocrlf during their
normal work. Besides, you can have your own input filters and they may
cause the same effect. So, Git works in the assumption that input filters
always produce the same results...

> 
> But fixing that minor bug still leads to badness for the user. Doing
> (on a core.autocrlf=true machine) a checkout of any revision
> containing a file that is (currently) CRLF in the repository, and your
> WC is *immediately* dirty. However technically correct that is, it
> doesn't fit most people's user model of an SCM, because they haven't
> made any modification.

IMHO, the only sane way is never store CRLF in the Git repository.
You can have whatever ending you like in your work tree, but inside
of Git, LF is the actually marker of the end-of-line.

> And if 1 person makes a change along with their
> conversion, and the other 'just' does a CRLF->LF conversion,

If you imported correctly in Git, it should not have CRLF for text
files. So, there is no conversion that a user does expliciltly.

> And because the svn is
> mastered crlf (well, strictly speaking, it's ignorant of line endings)
> this is gonna happen a lot.

Not really. SVN has its own setting for EOL conversion. If you have
'svn:eol-style' set to 'native' for any text file then SVN will
checkout text files accordingly to your native EOL (you can specify
your native EOL using the --native-eol option when it is necessary).

> Can't git be taught that if the WC is byte-identical to the revision
> in the repository (regardless of autocrlf) then that ought not to be
> regarded as a change?

Why should not it? If a file is different as long as Git repository is
concern then then it *is* a change. Git binary compare files _after_
applying all specified filters (and you can have your own filters, not
only autocrlf).

> Is there a way I can persuade the diff / merge mechanisms to normalise
> before they operate? (e.g if core.autocrlf does lf->crlf/crlf->lf,
> then an equivalent that does crlf->lf/crlf->lf before doing the merge
> )?

I am not sure if there is a standard option for that, but it is
certainly possible to define your own merge strategy.

> 
> In a perfect world I'd be able to switch all files int he repo to LF,
> but that's not going to happen any time soon because of the majority
> of developers, still on svn, still on windows.

Well, I don't see any problem here if everything is configured properly.
How files are stored inside and what you have in your work tree does
not have to be the same. So, storing everything inside with LF is
certainly possible. Actually, I believe it is exactly what CVS does
(unless you added a file with '-kb'), and people use CVS on Windows.
Importing files with CRLF in Git, it is like putting files as _binary_
in CVS.

Dmitry