On Wed, 23 Jan 2019 at 17:21, Erik Faye-Lund <[email protected]> wrote: > > On Wed, 2019-01-23 at 17:03 +0000, Emil Velikov wrote: > > Hi all, > > > > In case the patch is still outstanding, feel free to add > > Reviewed-by: Emil Velikov <[email protected]> > > > > Thanks, pushed. > > > On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund > > <[email protected]> wrote: > > > 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 < > > > > > > [email protected]> 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. > > > > > Before we start removing things I think we should consider: > > - what extra size savings are we talking about > > If it's something like, say 10MiB personally I would not bother. > > > > - but most importantly, what the goal is - a) remove merged work, b) > > reduce size c) list only active branches, d) other > > Personally a) and b) sound perfectly reasonable, while c) seems like > > bike shedding. > > I'm not sure that's the correct use of the term "bike shedding". You > might think that it's vanity? > Agreed, vanity is closer to what I was thinking off.
> Anyway, the goal isn't really either of those, but it's more closely > related to c) than any of the other points. > > The goal is really to make it easier to browse the repository. Having > everyone's pet branch around in the main repo doesn't really make sense > now that forking is literally a press of a button. And it clutters up > the repository, making browsing the branches harder. > Fwiw gitlab already groups active and stale branches [1]. If listing all branches in the drop-down at the main page [2] is too much, gitlab could (patch needed?) reuse the same logic. > So yes, arguably it *is* very much a vanity thing, but I don't think it > is in a bad way; we're not losing any data, but we *are* moving some > historical data. I doubt anyone will care apart from it being easier to > find what you're looking for. > I often git log, although only on the master branch. Thus such change won't affect me. Then again, I rarely click on the gitlab branches drop-down list either :-) Hence I don't see the interest, but if people think it has value - go ahead. > > If people want to go with c) the first regular expression from Erik, > > that lists all the release branches, feels list the best solution. > > OK, thanks for clarification. If we end up doing this, it'll always be > an option to move branches incorrectly moved back again anyway, so I'm > not too worried. > > > Considering memory serves me right, for [very] old release branches > > the history/tags is non-linear and some tags are detached. Hence > > dropping them sounds like a bad idea. > > Hmm, interesting. Anyway, I wasn't suggesting removing any tags, I've > never had an issue with them. > Indeed, it was pre-emptive information, since tags was likely to come up. Especially, since we had reports of "issues" flagged by git fsck [for some old tags]. In general, I'm neutral on the topic. HTH Emil [1] https://gitlab.freedesktop.org/mesa/mesa/branches [2] https://gitlab.freedesktop.org/mesa/mesa _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
