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

Reply via email to