Request: 'hg import' should produce conflict markers

[Jordi Gutiérrez Hermoso]

On Fri, 2015-07-03 at 21:45 +0000, Nathan Ridge wrote:
> I often need to apply patch files with 'hg import' without knowing
> exactly which ancestor revision they apply to.

Can you fix this part? How are you producing these patch files to
begin with? I doubt that it's absolutely impossible to know where a
patch file came from. Without knowing where a patch file came from,
there are some things that we can't do.

The thing is that you're fundamentally trying to do 3-way merges with
hg import. This is logically impossible. We can try to have whatever
`patch --merge` does (some sort of ad-hoc and undocumented 2-way
merge), but it cannot work in the way the rest of Mercurial works.

I know you hate working with .rej files, and we all do. But there
really isn't anything more that can be done in general without more
context. We can't have conflict markers, because the whole problem
when a hunk fails to apply is that we have no clear idea of where to
apply it. Thus it's fundamentally impossible in general to know what
to do with a failing hunk, so we fall back to doing nothing at all.

What you *should* be doing is producing patches with hg export, which
records where the patch should be applied to, and if you really must
pass patches around instead of pushing and pulling, apply them with
`hg import --exact` and then rebase the result. When you rebase you
can have all that you want: store the commit message, conflict
markers, a 3-way merge, a list of resolved and unresolved files.

I really feel like you're trying really hard to fit a square peg into
a round hole.

We *could* make the round hole a little bit bigger so square pegs
could fit in. We could modify Mercurial so the working directory can
be in some sort of special merge state when there is only one parent
commit instead of there being two. It just seems like a lot of hard
work in the wrong direction.