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

[Marek Olšák]

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.

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