[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