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

[Ian Romanick]

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
>