You are right about the transplant case, I was generalizing too fast

I still disagree; the current behavior is unconditionally incorrect. If there is
a changeset in one repository that I am trying to transplant to another
repository, and there is no inherent reason for a merge conflict to arise,
Mercurial should just do it. What newline convention I happen to using for
checked-out files should be completely irrelevant; the files in the repository
storage are in LF format in the old and new revisions and I want the exact same
change applied in the new changeset. I did not ask to have anything done to my
checked-out files beyond whatever would happen upon running 'hg up' if someone
else had done the transplant on my behalf. If Hg even requires me to have a
checkout at all when running the transplant command, that should be just an
artifact of the command's implementation.

> Windows users expect that their text files will be present on disk in CRLF
format and that all version control operations work transparently under that
assumption.

Well, as a former Windows user working on Mercurial sources (LF only), I
disagree. I often move files back or forward with MacOSX and do not want to
think about CRLF conversions. I expect my files to be in whatever line-endings
is enforced by the project I am working on.

I agree the behaviour you describe should be made *really* easy to configure and
Windows packager may enable it by default. But correctness wrt line-endings is
valuable.

I don't think you should need to set a special option just to make transplant or
other patch-based operations work. Windows users expect that their text files
will be present on disk in CRLF format and that all version control operations
work transparently under that assumption.

Yes, win32text definitely breaks a lot of tools including transplant and mq.

One possibility is to add a patch option to decide how strict should be line
endings handling. In strict mode (default current mode), line endings are
preserved. Otherwise, line endings are sampled from target file, then target and
patch ones are unified to the sampled value. If mixed line endings are found in
target, just bail out.

What do you think ?

Using Hg 1.0 on XP, with mercurial.ini specifying

[encode]
{}**=cleverencode:
[decode]
{}**=cleverdecode:

if you make a trivial repository with one file and three revisions (the two
diffs being in different areas of the file), clone from the first revision into
another, cd to the other, and run

hg transplant -s ..\original 2

you will just get a *.rej file and the transplant will fail.

I know of no such problem on Linux, so I am assuming that usage of win32text is
to blame.