feature request: replicate stripping of revisions
Georg
gwk.rko at googlemail.com
Fri Dec 7 17:47:25 UTC 2007
What a thread I initiated...
There seem to be quite a few users liking the idea to rebase/combine changes
and strip the original ones.
I join in to that interest, but I'd like to have more.
What about abandoning work that didn't yield anything? Yes, it's good to
keep your mistakes around, but ... see below.
What's the definition of "has been published"? If I push from one of my
private repos to another one, is that publishing?
If I push to a colleague whom I happen to work with on one particular
project, is that publishing? If he happens to do
a wildcard push into a repo on a server which includes my patch I had
previously pushed to him, is that publishing?
IMHO the notion of publishing and any decision being based on published or
not does not help us in any way. Hg is a
peer to peer approach, there is nothing like public or private. Every peer
is equally important, equally "published".
So consequently we should look at a more generic approch I think.
Since we cannot control or even define what has been published, and also
cannot control whether the pushed versions
have been _used_ by someone else (meaning someone has derived a new child
off of it), that pretty much rules out
any attempt to destructively strip.
We're back to Matts postulation that history should be append only.
We can still do something I believe. We can hide away the revs that we
don't want to see any longer. They are still there,
nothing is lost if anyone has used them. They just don't show (maybe unless
a special flag is given to the hg command line).
They will not be available for 'hg up' (again unless giving that special
flag) or 'hg merge'. They will not clutter 'hg log', hgweb, or hgk.
The information which revs should be hidden can be pushed and pulled similar
to how we push and pull tags. It is completely
non-destructive.
What do you think?
--
Regards,
Georg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20071207/ceaa7d37/attachment-0001.html>
More information about the Mercurial
mailing list