feature request: replicate stripping of revisions
Russ Brown
pickscrape at gmail.com
Wed Dec 5 13:43:24 UTC 2007
Matt Mackall wrote:
>
> Making an hg rebase that did either "transplant + strip" or "qimport;
> qpop; qpush; qdel" would give us something very like rebase, modulo
> handling of merge changesets.
>
> If people really want something more like rebase, we can probably make
> that happen.
>
Sorry to jump in here in the middle of a conversation, but I had a
thought last night about this.
I'm currently evaluating Mercurial as an svk replacement having just
evaluated git. Rebase in git seemed like a really clean way to do merges
when it's appropriate. The problem is knowing when it's appropriate, and
what happens if you rebase when it's *not* appropriate.
The impression I got is that you should *never* rebase changes that have
been published, and it's basically left up to the user to ensure that it
never happens. This is scary to me, because then I'm relying on other
people to follow that rule or I could find myself with problems.
My though is that if you implement this with Mercurial, you could add
add mechanisms to prevent incorrect use into the system. The idea is to
not allow the rebasing of any revision that has been 'published'. By
that I mean:
* Was pulled in from somewhere else
* Has been pushed somewhere else
* Has been pulled away by some other user
So only commits to the repo direct from the local working copy would be
allowed to be rebased. Of course, you might want to add a 'force' flag
for those situations when for example you *know* that the repository you
pushed to has now gone or was never really publicly viewable anyway.
Having said all of that, maybe Mercurial's internals are sufficiently
different that rebasing with wild abandon wouldn't cause the same
problems that it does in git. Can anyone offer any thoughts on whether
this might be the case?
I don't know, I've only just come to the party. :)
--
Russ
More information about the Mercurial
mailing list