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

From: Nigel Magnay <nigel.magnay@gmail.com>
Date: Apr 17, 2008, 10:09 UTC
Message-ID: <320075ff0804170309h4232463fk984f362e6cf0a259@mail.gmail.com>
In-Reply-To: <20080417094342.GM3133@dpotapov.dyndns.org>

Show 13 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

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