<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 20, 2016 at 5:36 PM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Feb 20, 2016 at 4:41 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On Feb 20, 2016 1:19 PM, "Rob Clark" <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
>><br>
>> fwiw, I think a *small* number of topic branches in certain cases<br>
>> makes sense..  I'm definitely in support of a TTL limit (ie.<br>
>> automatically nuke topic branches with no activity in N months, or<br>
>> similar..)<br>
><br>
> I agree. Sometimes something big comes up that's not ready for merging such<br>
> as amdgpu or our recently pushed Vulkan driver.  However, those should only<br>
> be temporary and removed once the work is complete.  I saw a "broadwell"<br>
> branch in there which is probably at least 2 years old and completely<br>
> subsumed by master.  We don't want to be archiving random junk in the main<br>
> tree.<br>
><br>
> I'd be fine with a timeout system where non-release branches get the boot<br>
> after a certain amount inactivity. If you want to archive something, that's<br>
> what personal git repos are for.<br>
<br>
</span>fwiw, I would totally ack a plan to automatically delete inactive<br>
topic branches after N months of inactivity (where I'd be fine with<br>
N==2 or even as high as N==12 but I think you'd have a hard time<br>
convincing me for N>12)<br>
<br>
Bonus points if someone wanted to archive old branches somewhere.. but<br>
I don't care strongly about that..<br></blockquote><div><br></div><div>Chad has some nifty way of archiving branches where they still exist and have names but are hidden.  I don't remember how it works though. <br></div></div><br></div></div>