Request: 'hg import' should produce conflict markers

Nathan Ridge zeratul976 at
Mon Jul 6 14:12:06 CDT 2015

>> 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
   - Continue relying on an external patch tool to produce the conflict 
   - 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'.
That seems like it should be very straightforward to implement.

More information about the Mercurial-devel mailing list