On 4/16/08, Dmitry Potapov <dpotapov@xxxxxxxxx> 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 -- 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
