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

["Avery Pennarun" <apenwarr@gmail.com>]

On 4/16/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Thu, Apr 17, 2008 at 12:07:27AM +0100, Nigel Magnay wrote:
>  > 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...

However, it doesn't check that before it marks the file as unmodified
right after checkout.  That is, the problem is hidden until the file's
mtime changes.

Is there a way to quickly check that every file in the repo is "sane",
ie. the input filter is the proper inverse of the output filter and
will put each file back in the repo?  This is pretty important for
anyone designing any kind of input filter, or bugs will go undetected
until some later time when they're confusing.

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

Can you give a set of steps for how to import "correctly" using git-svn?

Remember that a given svn repository might have long ago been
configured to store CRLF (actually, to store files without changing
their line endings), since that is the svn default.  Also remember
that the svn:eol-style flag may be set differently on various files in
svn, and may have changed in different svn revisions over time.

Thanks,

Avery