selectively applying changesets

Eric Hopper hopper at
Mon Sep 26 11:30:07 CDT 2005

On Mon, Sep 26, 2005 at 09:23:41AM +0200, Jan Hudec wrote:
> And what about trying to do it the other way round? Heads are marked
> non-exported (NOT non-exportable!) and pull/push transfers all exported
> heads + all changesets in their ancestry.

Yes, that makes a lot of sense.

> It should not be non-exportable, but non-exported. Now the changes are
> needed, so they get exported nevertheless.

Yes, that with marking the heads instead of arbitrary lower down
changesets makes a bunch of sense and neatly solves a bunch of problems.

I was actually thinking of a 'visibility level' attribute that could be
3-state.  Fully visible, non-exported, and invisible.  The invisible
state would be the same as the non-exported state except that the
changesets wouldn't show up when you did a log, or certain other
commands.  You could of course add an option to force all changesets
visible, even the invisible ones, but it would be a way to declutter
your view of branches you had abandoned.

This would also work well with marking heads.

Of course, depending on how you implemented it, it may make the
changeset number (not the identifier) change for a particular changeset
in a repository.  That would be an interesting effect.  Actually, from
what I know of the code, that wouldn't happen without a lot of effort,
and it probably shouldn't either.

Have fun (if at all possible),
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the Mercurial mailing list