EOL extension

[Paul Moore]

2009/12/1 timeless <timeless at gmail.com>:
> I'd assume that push hooks wouldn't discriminate by user but by
> content. The rule should probably be that no added changesets can have
> bad line endings.
>
> what should happen is that you're forced to:
> # first victim
> hg qimport -r first_bad:tip
> loop:
>  fix-line-endings
>  hg qref
>  hg qpop && goto loop
> hg qpush -a
> hg qfinish -a
> hg push
>
> # later victims after first victim has fixed upstream repository
> hg qimport -r first_bad:tip
> hg qpop -a
> hg pull --update
> loop:
>  [ -z "`hg qun`"] && goto done
>  hg qpush || (hg qguard -- `hg qtop` +rejected)
>  goto loop
> done:
> hg qfinish -a
>
> Note that at some point you have to do something about the qguarded
> patches. Initially I was going to use hg qdelete in my example, but I
> decided that it's a bad idea because you could have normal conflicts.

I doubt that mandating use of mq will work. I'm not sure if you are
mandating mq, or just using it as an example, but I'd probably
understand your suggestion better if you used core Mercurial commands.

I'm in agreement with Mark (I think! I may have misunderstood his point) that

1. Server-side hooks won't work, as I could commit all sorts of damage
locally and then push, and even if the final result is clean, there
could be any amount of clutter in between. Or would the server side
hook stop the intermediate csets? If so, I could have work that I
couldn't push without rewriting my local history. That's nasty. (Is
that why you need mq above?)

2. Commits to fix EOL breakage are icky. Not least because diffs that
show lines changing but the only change is to EOL format are also
icky. Let's aim to avoid EOL breakage getting into the repo in the
first place.

It seems to me that the extension (as described in its documentation -
I haven't tried it) does what is needed for most usages. To be sure it
works as we want, we need to understand precisely how it will be used.
There was a proposal for how the extension would be configured for
Python - I can't remember where it was, but that would be a good
start: how would Python developers be expected to configure things,
and how would working with the Python sources then look.

Mark has some use cases that concern him. To take one, the developer
who creates a new file with CRLF endings (because that's what his
editor does by default) - how would that be an issue? If I assume that
he's creating a C or Python source file, then the *.c = native or *.py
= native setting in the standard .hgeol file contained in the Python
repository would fix that. The only risk I can see is if it's a
completely new type of file, not picked up by the existing rules. In
that case, I guess a CRLF format file ends up in the repository.
That's bad, but I can't quite see what the impact would be (presumably
at some point where the .hgeol setting gets added, there'd be a cset
which normalises all the line endings - icky, as I said above, but
probably rare and likely not avoidable).

Can we list through various other such concerns and check that the
outcome is OK? The various cases (and the correct behaviour) would
make a good set of tests for the extension.

By the way, I'm a Windows developer, but the code I work on generally
only has me as developer, and I don't hit these types of issues. I
could probably simulate them, but so could any Unix developer (with
the above one, you can create a CRLF file just as easily on Unix as
Windows, it's just not the default there). So although I appreciate
that the Unix guys want input from us Windows people, it honestly
isn't any easier for us (on our small personal or test projects) to
demonstrate the issues than it is for you :-)

BTW, one thing that came up in the Python migration discussions was
the suggestion that the eol-extension settings needed to be mandated
for ALL developers - Windows as well as Unix. There was what I recall
as a sensible reason for why this was important, but I can't locate it
now - if that could be found and re-posted here, it might help clarify
why this is not "just a Windows problem".

Paul.

PS One point that hasn't been really looked at yet - what's the
recommended workflow? It seems to me that the EOL issue is at its most
serious if a "pull from developer repos" model is used. Mercurial
itself works on a contribution via patch model, and I think that irons
over many EOL issues (I know my contribution to Mercurial didn't cause
EOL issues, even though locally I was using an editor which could have
introduced such issues). If Python works in such a way (I doubt it
will!) then EOL issues may not be such a problem...