It's not so important now that the amdgpu driver is about to be merged. Speaking of other branches, I think removing the old feature branches is a good idea.
Marek On Mon, Jun 22, 2015 at 8:02 PM, Ian Romanick <i...@freedesktop.org> wrote: > 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
