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

[Marek Olšák]

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.

Marek