<div dir="ltr">On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On Feb 20, 2016 1:19 PM, "Rob Clark" <<a href="mailto:robdclark@gmail.com" target="_blank">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..)</p>
<p dir="ltr">I agree. Sometimes something big comes up that's not ready for merging such as amdgpu or our recently pushed Vulkan driver.  However, those should only be temporary and removed once the work is complete.  I saw a "broadwell" branch in there which is probably at least 2 years old and completely subsumed by master.  We don't want to be archiving random junk in the main tree.</p>
<p dir="ltr">I'd be fine with a timeout system where non-release branches get the boot after a certain amount inactivity. If you want to archive something, that's what personal git repos are for.<br>
</p></blockquote><div><br></div><div>I'm OK with deleting old branches too.<br><br>I don't know much about git under the hood- would deleting old branches actually delete the objects on those branches and make the database smaller?  If so, I'm guessing it probably wouldn't amount to much.<br><br></div><div>-Brian<br> <br></div></div><br></div></div>