EOL extension and patch.eol

[Colin Caughie]

> -----Original Message-----
> From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
> bounces at selenic.com] On Behalf Of Mark Hammond
> Sent: 06 December 2009 02:11
> To: Martin Geisler
> Cc: mercurial-devel at selenic.com
> Subject: Re: EOL extension and patch.eol
>
> On 5/12/2009 9:20 PM, Martin Geisler wrote:
> > Hi guys,
> >
> > I've pushed this test case to Bitbucket:
> >
> >    http://bitbucket.org/mg/hg-eol/changeset/ef070315d614/
> >
> > As the commit message says, I believe it is wrong since it cannot
> handle
> > the case where we have to change patch.eol in a single patch. The
> code
> > will actually normalize all EOLs to whatever the platform native
> setting
> > it, also in binary files.
> >
> > I searched back a bit and found
> >
> >    http://selenic.com/hg/rev/ac92775b3b80
> >
> > which introduces the patch.eol setting. I also found
> >
> >    http://markmail.org/message/acmrduwld75drnw3
> >
> > by Colin which looks superior since I believe it does apply the
> filters
> > on a per-file basis. I believe that is the root problem: the
> patch.eol
> > setting is global to all files in a single imported patch.
> >
> > Does anybody have a suggestion?

I think you can guess what my suggestion would be... :)

> I'm not the familiar with all the issues, but I think a reasonable
> underlying assumption is that regardless of the line-endings in a
> patch,
> the intention will be for the patch to be applied as EOL agnostic
> "text"
> - I think it is the truly exceptional case where a patch should be
> applied such that it causes mixed line-endings - and in those cases,
> it
> would be reasonable to expect things have been configured such that
> the
> file is treated as "binary".

That's what I originally thought as well, but after discussing the problem with others on this list and on IRC I realized that there are all sorts of special cases, mainly involving repos with mixed line endings. I still think that using the filters when patching solves most of them though.

> In particular, if my working tree uses CRLF line endings and I send
> a
> patch to a non-Windows user, both me and that user will expect the
> patch
> to be applied by ignoring the EOL in the patch.  Similarly in
> reverse.
>
> So this leads to me 2 observations:
>
> * It should not be necessary to set various different options to get
> the
> correct behaviour, so I don't like the apparent requirement in the
> first
> patch to set a [patch] option.  This should "just work",
> particularly
> for people on Linux who have ignored all EOL issues (ie, not
> configured
> the EOL extension, let alone the [patch] option), but receive
> patches
> from people who have.

Yes, if the filters are used both when creating and importing patches, this will indeed "just work", since all patches will be in repository-native (and therefore OS-agnostic) format. Patches are applied to the repository files, not the EOL-translated working copies. (If there are uncommitted changes the patch would be applied to whatever _would_ be in the repository if the files were committed).

> * It seems reasonable to me that hg "unconditionally" ignore the EOL
> in
> a patch itself, except for files which are "binary".  Thus, looking
> at
> the EOL convention of each individual file doesn't seem necessary.
> It
> may be desirable for implementation reasons, but it shouldn't affect
> the
> outcome of the patch operation.
>
> IOW - it seems there is one "obvious" outcome when applying a patch
> to
> text files - that the file will have the same EOL before and after.
> Except when trying to clean up the mess in a mixed EOL repo
> though... :)

I think that was the basic argument against -- ignoring line endings fails if you have a patch that changes line endings, or that operates on a file with mixed line endings.

Colin


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