Fixing patch import with win32text, issue 1019

[Colin Caughie]

> Patrick Mézard wrote, On 06/04/2009 12:01 AM:
> > ...
> > In the end, it does not look that horrible, even if I expect a lot
> of ugly corner cases to surface when we start hacking it.
> >
>
> I might have missed something important, but I think a simpler
> approach would work:
>
> win32text means "the working directory should contain CRLF no matter
> which EOLs are used in the repo, and when committing to repo then
> use LF instead of CRLF, thus effectively normalizing EOLs".
> Mercurial thus tries to enforce CRLFs in the working directory, but
> it really doesn't care.
>
> A consequence of that is that EOLs should be ignored when patches
> are applied; the resulting file should be normalized to CRLF
> afterwards anyway, and LFs doesn't matter when committing. And when
> patches are generated then they should patch from the repo EOLs to
> bare LFs.
>
> A consequence of that is that patches generated with win32text
> doesn't have CRLF and thus can't be shown in notepad. That might be
> surprising and annoying, but it is consistent and no big issue.
>
> And EOL-preserving changes simply can't be created with win32text.
> That's against its nature.
>
> Where is the flaw in this reasoning?

Mads I agree entirely. Perhaps the best approach here would be to fix the problems with win32text first (which should be easy for all the reasons you state). Once that's out of the way, if people have any remaining issues with patches and line endings we can tackle them in later updates.

My proposal would be to start with a "dumb" version of Patrick's algorithm where you could specify "eol=crlf" or something in a config file, and this would cause patching to always ignore input line endings and always insert crlf line endings.

A future update might add an "eol=auto" option that is smarter, but I think the dumb one would fix the problem once and for all for win32text users.

How does that sound?

Colin


Latest News at: http://www.indigovision.com/news2009.php