<br><br><div class="gmail_quote">On Fri, Nov 13, 2009 at 9:02 AM, Jesse Glick <span dir="ltr">&lt;<a href="mailto:jesse.glick@sun.com">jesse.glick@sun.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dirkjan Ochtman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Closed branches should be pushable with no flag at all<br>
</blockquote>
<br></div><div class="im">
This works well today, with hg 1.3.1, by using --close-branch and then<br>
merging the closing commit into some other branch.<br>
</div></blockquote>
<br>
Assuming &quot;some other branch&quot; means &quot;default&quot;, that&#39;s no good because it makes the default branch dependent on all the closed branches. These are probably no longer critical to have except for archival purposes. So if someone does &#39;hg clone -r default&#39; they will get all of these closed branches by way of dummy merges.<br>

<br>
I suppose you could have a special branch called &quot;void&quot; whose sole purpose was to serve as a (dummy) merge point for closed branches. But it seems simpler, nicer, and more intuitive to just close a branch and have it disappear from view unless someone is really looking for it.<div>
<div></div><div class="h5"><br></div></div></blockquote></div><br>I definitively would be very unhappy with having to merge closed branches, as that would break the initial use case that started this thread: &quot;how do I list all changes since the last release&quot;.<br>
<br>Yes, you can prune out the &quot;last release&quot; part, but you would then also need to prune out all the previous releases (which requires you to remember them all).<br><br>Also, I like how they (the closed heads) stand out in the revision graph. As a general principle, we should avoid &quot;faking&quot; things just to get a system to work...<br>
--<br>cg<br>