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

[Ilia Mirkin]

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