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. -Tom > Marek > _______________________________________________ > 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
