On 06/22/2015 10:40 AM, Marek Olšák wrote: > 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.
That's probably just historical. We probably ought to restrict that on Mesa as well. It sounds like you guys have some requirements for a shared repo. It seems like a repo on fd.o could work. I think you'd just need a "amddevs" group and make the repo group rwx. I thought fd.o GIT did https (maybe just SSH?). > 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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
