commit: Fix specifier inheritance behavior

[Stephen J. Turnbull]

Michael Sperber writes:
 > 
 > "Stephen J. Turnbull" <stephen at xemacs.org> writes:
 > 
 > > (1) I don't want to see merge turds.  The commit bot should be diffing
 > > against the parent of the commit, not against the previous revision.
 > > They're typically different in the case of merges.
 > 
 > I guess I still don't understand what you're trying to accomplish: A
 > merge commit has *two* parents.

The problem I'm worried about now is not the merge, it's the commit
that creates a new head, which requires a merge or you can't push.
That commit only has one parent.  In my repo, if I do

$ xemacs somefile
$ hg commit
$ hg push     # fails because not up-to-date
$ hg pull
$ hg merge
$ hg push

and the current rev is N, then the patch I want to review is locally
"hg diff -r (N-3) -r (N-2)" because the state of my repo is "...0BAM"
where 0 is the common ancestor, B is my commit, A is the concurrent
work that got committed before mine and M is the merge commit.
However, the public repo has state "...0ABM".  So the patch I want to
see from the commit 'bot is "hg diff -r (N-3) -r (N-1)".  But ... only
if it's going to be followed by a merge.  If no merge was needed, I
would want just "hg diff -r (N-1) -r N" (nb: the relevant patch is not
"covered" by a merge, so it's N, not N-1, here).  You'd hope that this

hg diff -r`hg log -r REV --template='{parents}\n'` -r REV

would work, but it doesn't: Mercurial returns the empty string if
there's only one parent.

The 'bot currently delivers "hg diff -r (N-2) -r (N-1)", which makes
it look like that commit removed the patch A and added B.

This is followed by "hg diff -r (N-1) -r N" which adds patch A back in
(but we already saw that commit when A was committed in the first
place).  For the merge itself, I'd want to see that only if the merge
was nontrivial and required human intervention.  Something like

diff -U0 <(hg diff -r (N-3) -r (N-2)) <(hg diff -r (N-1) -r N)

would do, I guess.