why abort on grafting sibling?

[Matt Mackall]

On Tue, 2012-09-25 at 23:50 +0200, Robert Figura wrote:
> Matt Mackall <mpm at selenic.com> wrote:
> > On Tue, 2012-09-25 at 20:02 +0200, Robert Figura wrote:
> 
> > > in the middle of some history ...a-b-c...
> > > i'd like to tinker with a changeset b.
> > >
> > > so i'd like to duplicate it to qimport and edit it:
> > > 
> > > $ hg up -r a
> > > $ hg graft b
> > > grafting revision b
> > > abort: nothing to merge
> > > (use 'hg update' or check 'hg heads')
> > > 
> > > Aha, graft won't allow me to duplicate b.
> 
> > But in your case, it tries to do:
> > 
> > a-b
> >  \
> >   a <- we're trying to merge with an ancestor??
> > 
> > and says "uh, sorry boss, there's nothing to merge here" and gives up.
> >  
> > Now we could make graft work anyway, and make a trivial duplicate b'.
> > But I'm going to say no to that, because it's not an intended use AND
> > it's a use case that's unusual enough that it will probably be
> > encountered more often by (painful) user error than on purpose, which is
> > not a good combination.
> 
> I understand that graft is there to allow copying through merge. I'm
> not sure i completely understand the pain in case of user error.

Spend a few years on #mercurial on IRC. Then you'll understand that
every single conceptual mistake will be made by someone somewhere and it
will ruin their day. Here, they'll attempt to graft onto the wrong
branch and instead of getting a no-op or error, they'll end up with a
mysterious unwanted duplicate (or many). They'll then spend an entire
day trying to correct the situation, probably compounding their error in
the process. So it's best to avoid making it easy to make mistakes in
the first place.

(If this were git, they would immediately know the fault lies in their
own massive uncertainty as to how git actually works. But since this is
Mercurial, the fault will lie in Mercurial for either a) not doing what
they thought was obvious or b) not working exactly like git.)

>  I also
> wonder why my workflow is so unusual because it keeps original history
> in place and that feels so natural. However, being no authority on this
> i wouldd be perfectly happy with a workaround like the one you
> suggested:
> 
> > Obvious workaround: duplicate your change by qimporting an exported
> > change.
> 
> $ hg export -r a > a
> $ hg qimport a
> $ hg qpush -f
> (working directory not at a head)
> applying a
> cleaning up working directory...done
> abort: qpush exactly duplicates child changeset
>
> But sadly, no, qimport protects me from this either. Here's my version:
> $ hg --version
> Mercurial Distributed SCM (version 2.3.1)
> 
> So: Thank you for your very detailed answer but i now have to ask:
> Why is qpushing a direct sibling *generally* bad?

First, I think you mean descendant:

  sibling
      n 1: a person's brother or sister 

Here, you run into the problem that identity=contents in Mercurial. If
you make two identical changes (including metadata like parents).. you
end up with one changeset. So you have to change.. something. Perhaps
the date.

-- 
Mathematics is the supreme nostalgia of our time.