Request: 'hg import' should produce conflict markers

[Matt Mackall]

On Mon, 2015-07-06 at 19:12 +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. 
> >
> > [...]
> >
> > What you *should* be doing is producing patches with hg export, which
> > records where the patch should be applied to, and [...] apply them with
> > `hg import --exact` and then rebase the result.
>  
> This issue comes up most frequently during my work on a large open-
> source project (Mozilla). Typically, someone has posted some patches,
> and I need to apply them to 1) review them more effectively, or 2) test 
> them, or 3) develop on top of them.
>  
> There are two main reasons why 'hg import --exact' rarely works:
>  
>   1) The project's main mercurial repository has a git mirror.
>       Many developers choose to use the git mirror, and produce 
>       patches where the parent SHA is a git SHA.
>  
>   2) Even if the patch was produced by hg, often the developer who
>       produced the patch also has  other patches applied locally. I 
>       would have to track them all down (if they're even all posted 
>       somewhere, often they're private debugging patches), and apply 
>       each of them in sequence to be able to apply them to my tree 
>       with 'hg import --exact'.
>  
> > if you really must
> > pass patches around instead of pushing and pulling
>  
> There is work underway to put in place a repository-based review system,
> but it will be a while until it's in good enough shape for everyone to use it.
>  
> > 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.
>  
> Let me propose something more modest then, that would still help me
> tremendously:
>  
>    - Continue relying on an external patch tool to produce the conflict 
>      markers.
>  
>    - If the patch tool exits with exit code 0, perform the commit (this
>      is already done).
>  
>    - If the patch tool exits with an nonzero exit code, remember the
>      commit metadata, and perform the commit upon 'hg import --continue'.

Continuable commands are a serious headache, both from a UI perspective
and from an architecture one. We do it in some places, of course, but
those commands are basically useless without it.

Odds of us making import continuable after 10 years just to work with
patch --merge are just about nil. We'd need a much larger increment in
functionality to justify the complexity and demand is not particularly
high.

You can do this today:

 - write a script that does your patch --merge + exit 0
 - do hg import with that 
 - hg commit --amend after you fix up

-- 
Mathematics is the supreme nostalgia of our time.