I will happily remove the branch after the kernel driver lands. I also wonder why all Mesa developers can force-push branches in Mesa but not libdrm.
Marek On Mon, Jun 22, 2015 at 5:39 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Jun 22, 2015 at 11:30 AM, Christian König > <deathsim...@vodafone.de> wrote: >> On 22.06.2015 15:41, Ilia Mirkin wrote: >>> >>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard <t...@stellard.net> wrote: >>>> >>>> On Mon, Jun 22, 2015 at 12:23:54PM +0200, Marek Olšák wrote: >>>>> >>>>> On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin <imir...@alum.mit.edu> >>>>> wrote: >>>>>> >>>>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <mic...@daenzer.net> >>>>>> wrote: >>>>>>> >>>>>>> On 22.06.2015 00:31, Ilia Mirkin wrote: >>>>>>>> >>>>>>>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov >>>>>>>> <emil.l.veli...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote: >>>>>>>>>> >>>>>>>>>> Ilia Mirkin <imir...@alum.mit.edu> writes: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> There are a *ton* of branches in the upstream mesa git. Here is a >>>>>>>>>>> full list: >>>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>> is there >>>>>>>>>>> any reason to keep these around with the exception of: >>>>>>>>>>> >>>>>>>>>>> master >>>>>>>>>>> $version (i.e. 9.0, 10.0, mesa_7_7_branch, etc) >>>>>>>>>> >>>>>>>>>> Instead of outright deleting old branches, it would be possible to >>>>>>>>>> set >>>>>>>>>> up an "archive" repository which mirrors all branches of the main >>>>>>>>>> repository. And then delete "obsolete" branches only from the main >>>>>>>>>> repository. Ideally, you would want a git hook to refuse to create >>>>>>>>>> a new >>>>>>>>>> branch (in the main repository) if a branch by that name already >>>>>>>>>> exists >>>>>>>>>> in the archive repository. Possibly with the exception that >>>>>>>>>> creating a >>>>>>>>>> same-named branch on the same commit would be allowed. >>>>>>>>>> >>>>>>>>>> (And the same for tags, of course) >>>>>>>>>> >>>>>>>>> Personally I am fine with either approach - stay/nuke/move. But I'm >>>>>>>>> thinking that having a mix of the two suggestions might be a nice >>>>>>>>> middle >>>>>>>>> ground. >>>>>>>>> >>>>>>>>> Write a script that nukes branches that are merged in master (check >>>>>>>>> the >>>>>>>>> top commit of the branch) and have an 'archive' repo that contains >>>>>>>>> everything else (minus the stable branches). >>>>>>> >>>>>>> Sounds good to me, FWIW. >>>>>>> >>>>>>> >>>>>>>> That still leaves a ton around, and curiously removes mesa_7_5 and >>>>>>>> mesa_7_6. >>>>>>> >>>>>>> I think the latter is expected, we were using a different branching >>>>>>> model back in those days. >>>>>>> >>>>>>> >>>>>>>> origin/amdgpu >>>>>>> >>>>>>> Note that this is a currently active branch, to be merged to master >>>>>>> soon. >>>>>> >>>>>> Perhaps there's something I don't understand, but why is a feature >>>>>> branch made available on the shared tree? In my view of things the >>>>>> only branches on the shared mesa.git tree should be the version >>>>>> branches. >>>>> >>>>> As you can see, a lot of feature branches are in the shared tree >>>>> already, so there is a precedent. Sharing a branch among people in >>>>> this way sometimes tends to be more convenient. >>>>> >>>>> The reason here is that it's the only mesa repository where most >>>>> people from our team have commit access. >>>>> >>>> Also, the shared git tree supports https access, which means it is >>>> accessible when behind a firewall. >>> >>> OK, well if that's the prevailing attitude, then I'm on a fool's >>> errand, and I'll just drop this. >> >> >> I still think it would be a good idea to archive the branches after a while, >> cause the current status is rather confusing if you search for something >> specifc. > > Yeah, but if the policy is "create random branches whenever you feel > like on the upstream mesa tree", then this same current situation will > happen again, so it's not really worth fixing now (at least for me). > I'm not aware of any other major project with this sort of branching > policy, but I guess there's always a first! > > I don't really see why you wouldn't just use a shared tree in > someone's ~/foo, chgrp'd to mesa or some other convenient group, or > how https plays into things, but I'm sure there's some reason for it. > [Or why those amdgpu patches are on a branch in the first place rather > than in master.] If the final state isn't a tree with a policy of not > adding (non-release) branches, I don't think I'm particularly > interested in doing the legwork. > > Cheers, > > -ilia > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
