Problem with win32text

[Alexis S. L. Carvalho]

Thus spake Michael Sperber:
> The problem is files that have LF line endings, not CR/LF.  This kind of
> thing often happens inadvertently on Windows boxes, where many editors
> are sloppy about line endings.  I'd think that "hg revert" should just
> normalize to CR/LF line endings (which it does), and then should be done
> with it.  However, I still see this output:
> 
> M baz
> 
> ... and get an empty patch upon commit.

The annoying thing here is that there are 2 representations of baz that
should be considered clean (with \r\n and \n).  Or maybe even more if
you end each line with a different ending...

So consider this slightly modified example:

> ================
> #!
> hg init foo
> cd foo
> echo '[extensions]' > .hg/hgrc
> echo 'win32text =' >> .hg/hgrc
> echo '[encode]' >> .hg/hgrc
> echo '** = cleverencode:' >> .hg/hgrc
> echo '[decode]' >> .hg/hgrc
> echo '** = cleverdecode:' >> .hg/hgrc
> 
> echo foo >> baz
> echo bla >> baz
> hg add baz
> hg commit -m "checkin"

cp baz baz.backup

> rm baz
> hg revert baz
> hg status

cp baz.backup baz
hg status

> ================

Ideally both "hg status" should consider baz clean, but right now we
have to choose one or the other.

And I think you don't even need revert - just put a version of baz with
different line endings in its place and you'll get a 'M'odified file
with an empty diff.

I'm not sure what's the right thing to do here.  In the example above,
making the status right after the revert show baz as clean might lead to
fewer surprises.  Hmm...

Alexis