On Wed, 2019-01-23 at 10:42 +0000, Eric Engestrom wrote: > On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote: > > On Wed, 2019-01-23 at 10:14 +0000, Daniel Stone wrote: > > > Hi, > > > > > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom < > > > eric.engest...@intel.com> wrote: > > > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote: > > > > > Sending MRs from the main Mesa repository increase clutter in > > > > > the > > > > > repository, and decrease visibility of project-wide branches. > > > > > So > > > > > it's > > > > > better if MRs are sent from forks instead. > > > > > > > > > > Let's add a note about this, in case its not obvious to > > > > > everyone. > > > > > > > > Yes please, we already have way too many dead branches in the > > > > main > > > > repo > > > > without adding that kind of things to it. > > > > > > > > One other thing is that (last time I checked) the scripts > > > > propagating > > > > the repo to github et al. don't propagate branch deletions, > > > > which > > > > means > > > > the clutter never gets cleaned there. > > > > > > They're propagated from gitlab.fd.o to git.fd.o, as the hook is > > > run > > > within regular post-receive, but you're right that pushing from > > > git.fd.o to GitHub doesn't notice old branches, as it just pushes > > > everything present in the git.fd.o repo to GitHub, and doesn't > > > notice > > > any branches no longer present. > > > > Yeah, and then add the problem that forking in Github copies *all* > > branches as well (not just the default branch), means that these > > branches keeps getting replicated over there. It gets nasty > > quickly. > > > > Perhaps we should do a manual spring cleaning in the repo soon, > > moving > > old, stale branches out to some historical repo and making sure > > official forks don't have any cruft? > > I looked at that a year or two ago, but I quickly gave up. You're > welcome > to give it a go, but be aware that there's a very large number of > very old > branches.
Looks quite managable to me. There's really only a few branches that I think should be kept int he main repo, and I think they can be enumerated like this: git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" | grep -E "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- 9]+\.[0-9]+$" Those seems to be *actual* release-branches. There's some other "almost release-branches", like these: $ git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" | grep -vE "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- 9]+\.[0-9]+$" | grep -E "^mesa_[0-9]+_branch$|^staging/|^[0-9]+\.[0- 9]+" 18.1-proposed 7.8-gles mesa_20040127_branch mesa_20040309_branch mesa_20050114_branch staging/18.2-ci I suppose to be conservative we could include these as well. But perhaps someone like Emil could chime in here? Personally, I think we could go as far as removing all "closed" release branches as well; we can just branch out from the most recent tag if we need to back-port something in the future. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
