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. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
