[Mesa-dev] abundance of branches in mesa.git

Mon Jun 22 11:23:23 PDT 2015

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 <idr at 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 <imirkin at alum.mit.edu> wrote:
>>> On Mon, Jun 22, 2015 at 11:30 AM, Christian König
>>> <deathsimple at vodafone.de> wrote:
>>>> On 22.06.2015 15:41, Ilia Mirkin wrote:
>>>>>
>>>>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard <tom at 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 <imirkin at alum.mit.edu>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <michel at 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.velikov at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Ilia Mirkin <imirkin at 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>