[PATCH 0 of 4] A Branch Closing patch series

John Mulligan phlogistonjohn at asynchrono.us
Wed Jan 7 14:55:44 CST 2009


On Tue, Jan 06, 2009 at 04:19:57PM -0600, Matt Mackall wrote:
> On Tue, 2009-01-06 at 16:42 -0500, John Mulligan wrote:
> > On Sat, Jan 03, 2009 at 09:30:57PM +0100, Dirkjan Ochtman wrote:
> > > On 23/12/2008 20:31, John Mulligan wrote:
> > >> Feedback is very welcome.
> > >
> > > Matt, any more comments, or is this good to go?
> > >
> > > Cheers,
> > >
> > > Dirkjan
> > 
> > Ditto. (Just trying to see what the status is.)
> 
> This all looks good so far, but I haven't dug into it deeply enough yet.

Thanks for the update. (and for hg in general!)

> 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. 
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.

> - 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.

> - 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.


> - is the new cache format good enough?

I hope so. :-) But you have better judgement about it so I won't
complain.

> 
> These are exactly the sorts of things people should include in their
> changelogs to make reviewing easier. Otherwise, I need to spend a lot
> more time going over the patch figuring out whether it's the right
> thing, which increases the odds that something shiny will come along and
> distract me.

I apologize if I didn't put enough detail in my original patch series. I
hope my notes above help clear up some of what my thought processes
were when I made the changes. 

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 


More information about the Mercurial-devel mailing list