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

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Apr 17, 2008, 00:46 UTC
Message-ID: <20080417004645.GK3133@dpotapov.dyndns.org>
In-Reply-To: <320075ff0804161607p3f9e983ehb75aae4e0bfe8837@mail.gmail.com>

On Thu, Apr 17, 2008 at 12:07:27AM +0100, Nigel Magnay wrote:

Show 13 quoted lines

> >  > 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...

Show 7 quoted lines

> 
> 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