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

Christian König deathsimple at vodafone.de
Mon Jun 22 08:30:35 PDT 2015

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.


>    -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list