Brian Paul <brian.e.p...@gmail.com> writes: > On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > >> >> On Feb 20, 2016 1:19 PM, "Rob Clark" <robdcl...@gmail.com> wrote: >> > >> > fwiw, I think a *small* number of topic branches in certain cases >> > makes sense.. I'm definitely in support of a TTL limit (ie. >> > automatically nuke topic branches with no activity in N months, or >> > similar..) >> >> 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. >> >> 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. >> > > I'm OK with deleting old branches too. > > 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.
People pulling down the repository fresh wouldn't get any objects that existed only in the old branches. For those of us with existing clones, the tracking branch would stay around until we do a git prune, and then the objects would stay around until git gc. There's an argument for keeping branches that aren't merged, in case someone wants to pick the work back up again. But then, almost all branches of that type are in personal repositories, anyway. I wouldn't miss topic branches that have been left around in the main tree.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
