why abort on grafting sibling?

[Robert Figura]

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. 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?

Many thanks and kind regards
  - Robert Figura

-- 
http://teslawm.org/