[PATCH] add support for marking changesets as dead

[Matt Mackall]

On Tue, 2011-02-01 at 21:41 -0200, Wagner Bruna wrote:
> On 02/01/2011 06:15 PM, Matt Mackall wrote:
> > On Tue, 2011-02-01 at 11:21 +0100, Martin Geisler wrote:
> >>> And that, I think, is conceptually broken. I can know that I want "1
> >>> and descendants" dead long before I know what I want to replace it
> >>> with. Having to commit an extra dummy cset (note that we actively
> >>> reject empty csets!) to have a living head at this point "sucks" from
> >>> a user POV.
> >>
> >> Sort of -- see it this way: the dead changesets are no good if you want
> >> to back up a linear track of development. They are good if you have
> >> different (concurrent!) lines of development and you want to kill one of
> >> them, in which case you already have a branch point in the past.
> > 
> > I want to focus on just one issue for a bit: your choice of direction.
> > Your proposal is about "the set of heads x and all its _ancestors_ that
> > are not ancestors of heads not in x". That's not exactly a simple rule.
> > In revset notation, it'd be something like '::dead() and not ::(heads()
> > and not dead())'. And if I want to prune back to something that's not a
> > branch point, I'm forced to introduce dummy changesets. 
> > 
> > My proposed approach is "the set of changesets x and all their
> > _descendants_" with no additional caveats ('dead()::' in revset-speak). 
> > Not only is this conceptually simpler, it allows you to precisely prune
> > a line of development at any point without adding additional changesets.
> > 
> > So, is this pruning to non-branch-points a real issue? My contention is
> > yes. First, 'branch points' are not an easily identified thing in
> > Mercurial, short of poking around at graph views. We don't have a simple
> > way of asking 'what is the first ancestor of x that's only ancestral to
> > x' without doing something like the big revset expression above. 
> > 
> > Second, it's going to be common for people to want to back out only a
> > portion of changesets after a branchpoint: "my first 5 changesets were
> > fine, but the last 5 I pushed were broken".
> > 
> > Third, people are also going to want to mark things discarded well
> > before they're ready to commit anything new: "I need to throw out the
> > junk that moron Bob committed on the stable branch today but I'm not
> > planning to commit anything else there until an actual fix for stable
> > shows up".
> > 
> > As far as I can see, you've latched onto the ancestors direction because
> > it's the obvious way to do thing when you've chosen to store the pruning
> > markers as new commits, but aside from that, it's not a good choice.
> > Given the constraint that everything is communicated in history, it
> > might be the right answer, but that constraint doesn't apply. There's no
> > good reasons for DAG pruning instruction to live in the DAG when we have
> > another channel available.
> 
> IMHO it'd be far less confusing for new users if changeset metadata were also
> used for "abandoning" topological heads, since it is very similar in concept
> (and possibly implementation) to closing named branches (to some extent,
> closing a named branch and reopening it at another point can be used right now
> for "abandoned" topological lines).

The similarity between closed and abandoned branches is very
superficial. Closed branches stay in history; abandoned ones are dropped
from history, presumably the sooner the better. We should probably make
an effort to hide abandoned changesets from users while they're still
present, in which case the only thing storing the marks as changesets
serves to do is confuse people using older hg with weird csets.

-- 
Mathematics is the supreme nostalgia of our time.