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

["Nigel Magnay" <nigel.magnay@gmail.com>]

>  >
>  > I'm saying it ought to be something like
>  >
>  > isDirty = ( wc.file.mtime > someValue ) && (sha1(repository.file) !=
>  > sha1(wc.file) ) && ( repository.file != filter(wc.file) )
>
>  I don't think it is reasonable. Files inside of the repository and
>  in the work are not meant to be the same. What if I have $Id$ expansion
>  or something else. What could make sense is to add an additional check:
>   && convert_to_work_tree(repository.file) != wc.file
>  but it should be optional, so it will not penalize those who do need
>  or do not want this extra check.
>

Ah, yes - you're right (I was only thinking about check-in filters,
not check-out).

I agree it ought to be optional; I suggest it ought to be turned on
(be default) in the $Id$ expansion and the core.autocrlf=true
scenarios (I.E when there's some filter in place).

>
>  > >  > ...
>  Maybe, you can teach git-svn to be smarter... I mean storing text files
>  in Git repo with CRLF is stupid, so, perhaps, git-svn can do a better
>  job converting CRLF<->LF when it exports and imports from/to SVN.
>

Yar - maybe there's some options there. Maybe it isn't so bad - all
svn projects probably *ought* to be using eol=native, but it isn't
default; so maybe it's just easier to coax those projects into fixing
their svn repos (but of course it's not really an issue for them, so
it might be a bit of a hard sell).

I may add some detail to the wiki docs to point this out - if I'd done
it up front to our local projects, my life would be easier!

>  ...
>  You can use Git and have CRLF in your work tree. You just need to
>  have autocrlf=true for that. _Inside_ of Git, only LF is the end
>  of line. How you store in SVN, it is a separate issue with git-svn.
>  I guess, git-svn needs improvement in this area...
>

Yes, in the sense that git is primarily a *nix tool, so it treats LF
as canon and CRLF as somehow 'stupid' (I.E you could make an equally
valid argument for the reverse position, it just depends on your
perspective ;-)) ; but then again, it's only an issue because I'm now
merging in git *waaay* more often and it's uncovering a problem that
might actually be there already (modulo the fact that svn merging may
ignore line endings anyway - but I don't know because all merges there
seem to inevitably end up in conflicts anyway..).