commit: Fix specifier inheritance behavior

[Stephen J. Turnbull]

Didier Verna writes:
 > Mike Spreber writes:

 > > Opinions differ on that:
 > >
 > > http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html

Bah.

John Goerzen has been, uh, less than perceptive since at least 2003.
Darcs is fundamentally all about rebasing.  The thing is, that's not
apparent because Darcs's fundamental data structures and algorithms
are designed for rebasing implicitly.  The problem with Darcs is that
Darcs is pretty bad at rebasing anything interesting (the exponential
merge problem), and doesn't provide a way to do it manually.

As a comment to that blog points out

$ git update-ref refs/heads/temp topic
$ git rebase somewhere temp
$ do-something-with-temp

is perfectly safe.  The reason why git-rebase isn't implemented that
way is that people want to manipulate a topic branch as if it were a
patch in a patch queue.  That's the primary use-case, and you want to
get rid of refs to the previous commit list to keep the namespace
clean.  Long-lived branches, on the other hand, pull from the mainline
rather than being rebased onto the mainline.

 > Thanks for the pointer. It's actually a good answer for a post of mine
 > to which nobody replied anything (<muxabmgabo2.fsf at uzeb.lrde.epita.fr>) :-)

Where did you post that?  I don't see it locally.

 > But I'm still not quite convinced. Although option 2 is obviously more
 > convenient (for instance if you've done a lot of work unplugged), it
 > still feels wrong to me...

A "good" VCS would make them look equivalent, as Darcs does.