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

[Rob Clark]

fwiw, I think a *small* number of topic branches in certain cases
makes sense..  I'm definitely in support of a TTL limit (ie.
automatically nuke topic branches with no activity in N months, or
similar..)

BR,
-R

On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák <maraeo at gmail.com> wrote:
> It's not so important now that the amdgpu driver is about to be merged.
>
> Speaking of other branches, I think removing the old feature branches
> is a good idea.
>
> Marek
>
> On Mon, Jun 22, 2015 at 8:02 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> 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
>>>
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev