[PATCH 0 of 4] A Branch Closing patch series

Matt Mackall mpm at selenic.com
Fri Jan 9 19:58:31 CST 2009


On Wed, 2009-01-07 at 15:55 -0500, John Mulligan wrote:
> > My remaining concerns are things like:
> > 
> > - are there behavioral changes to hg branches? (I assume so?)
> > - should there be? (probably yes)
> > - should we keep the 'old' notion of inactive heads?
> 
> branches has been changed so that both branches with closed heads and 
> headless branches are treated as inactive. I figured, better not change
> the output of the command unless it is specifically requested. My other
> thought was to print "(closed)" or "(inactive/closed)" on an explictily 
> closed branch as opposed to it being displayed the same as a "buried" 
> branch. 

We should probably make a distinction between closed and inactive here
to avoid future confusion.

> IMO, the old inactive heads should be kept: merging is still a valid
> way to "end" a branch especially if you really are folding it into
> another branch. And it is good to know that I once had 
> a add-feature-foo branch in case I need to refer to it.

Inactive branches are slightly annoying as they have a way of
disappearing unexpectedly (where'd my stable branch go?). But we can
defer the question until later.

> > - are there behavioral changes to hg heads? (unclear)
> > - should there be? (probably not?)
> 
> I'm not sure if adding an option counts. Without an option heads should
> behave as it always did, this includes displaying closed heads. Iff you
> pass the --active option it will not display closed heads, users who
> never want to see closed heads can add it to their rc.

Ok, seems good.

> > - what's the new cache format?
> 
> The format of an individual line is the same as before: '{node} {branchtag}\n'. 
> Every head is recorded in an oldest -> tipmost order.

Great.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list