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

[Kenneth Graunke]

On Monday, February 22, 2016 12:20:02 PM PST Jose Fonseca wrote:
> On 22/02/16 02:59, Eric Anholt wrote:
> > Brian Paul  writes:
> >
> >> On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand 
> >> wrote:
> >>
> >>>
> >>> On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
> 
>  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..)
> >>>
> >>> I agree. Sometimes something big comes up that's not ready for merging
> >>> such as amdgpu or our recently pushed Vulkan driver.  However, those 
should
> >>> only be temporary and removed once the work is complete.  I saw a
> >>> "broadwell" branch in there which is probably at least 2 years old and
> >>> completely subsumed by master.  We don't want to be archiving random 
junk
> >>> in the main tree.
> >>>
> >>> I'd be fine with a timeout system where non-release branches get the 
boot
> >>> after a certain amount inactivity. If you want to archive something, 
that's
> >>> what personal git repos are for.
> >>>
> >>
> >> I'm OK with deleting old branches too.
> >>
> >> I don't know much about git under the hood- would deleting old branches
> >> actually delete the objects on those branches and make the database
> >> smaller?  If so, I'm guessing it probably wouldn't amount to much.
> >
> > People pulling down the repository fresh wouldn't get any objects that
> > existed only in the old branches.  For those of us with existing clones,
> > the tracking branch would stay around until we do a git prune, and then
> > the objects would stay around until git gc.
> >
> > There's an argument for keeping branches that aren't merged, in case
> > someone wants to pick the work back up again.  But then, almost all
> > branches of that type are in personal repositories, anyway.
> 
> I don't disagree, but one problem of using personal repos for 
> development history is that personal directories on fdo.org aren't being 
> backed up.

I thought that changed after the great data loss of 2009, and things are
actually backed up now.  I'd have to ask in #freedesktop to confirm
though...

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jose Fonseca]

On 22/02/16 02:59, Eric Anholt wrote:

Brian Paul  writes:


On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand 
wrote:



On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:


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..)


I agree. Sometimes something big comes up that's not ready for merging
such as amdgpu or our recently pushed Vulkan driver.  However, those should
only be temporary and removed once the work is complete.  I saw a
"broadwell" branch in there which is probably at least 2 years old and
completely subsumed by master.  We don't want to be archiving random junk
in the main tree.

I'd be fine with a timeout system where non-release branches get the boot
after a certain amount inactivity. If you want to archive something, that's
what personal git repos are for.



I'm OK with deleting old branches too.

I don't know much about git under the hood- would deleting old branches
actually delete the objects on those branches and make the database
smaller?  If so, I'm guessing it probably wouldn't amount to much.


People pulling down the repository fresh wouldn't get any objects that
existed only in the old branches.  For those of us with existing clones,
the tracking branch would stay around until we do a git prune, and then
the objects would stay around until git gc.

There's an argument for keeping branches that aren't merged, in case
someone wants to pick the work back up again.  But then, almost all
branches of that type are in personal repositories, anyway.


I don't disagree, but one problem of using personal repos for 
development history is that personal directories on fdo.org aren't being 
backed up.




> I wouldn't

miss topic branches that have been left around in the main tree.



FWIW, I'm deleting a bunch of llvmpipe branches and other branches I 
worked on that have no value.



Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Anholt]

Brian Paul  writes:

> On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand 
> wrote:
>
>>
>> On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
>> >
>> > 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..)
>>
>> I agree. Sometimes something big comes up that's not ready for merging
>> such as amdgpu or our recently pushed Vulkan driver.  However, those should
>> only be temporary and removed once the work is complete.  I saw a
>> "broadwell" branch in there which is probably at least 2 years old and
>> completely subsumed by master.  We don't want to be archiving random junk
>> in the main tree.
>>
>> I'd be fine with a timeout system where non-release branches get the boot
>> after a certain amount inactivity. If you want to archive something, that's
>> what personal git repos are for.
>>
>
> I'm OK with deleting old branches too.
>
> I don't know much about git under the hood- would deleting old branches
> actually delete the objects on those branches and make the database
> smaller?  If so, I'm guessing it probably wouldn't amount to much.

People pulling down the repository fresh wouldn't get any objects that
existed only in the old branches.  For those of us with existing clones,
the tracking branch would stay around until we do a git prune, and then
the objects would stay around until git gc.

There's an argument for keeping branches that aren't merged, in case
someone wants to pick the work back up again.  But then, almost all
branches of that type are in personal repositories, anyway.  I wouldn't
miss topic branches that have been left around in the main tree.



signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Steven Newbury]

On Sat, 2016-02-20 at 13:41 -0800, Jason Ekstrand wrote:
> On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
> > 
> > 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..)
> 
> I agree. Sometimes something big comes up that's not ready for
> merging such
> as amdgpu or our recently pushed Vulkan driver.  However, those
> should only
> be temporary and removed once the work is complete.  I saw a
> "broadwell"
> branch in there which is probably at least 2 years old and completely
> subsumed by master.  We don't want to be archiving random junk in the
> main
> tree.
> 
> I'd be fine with a timeout system where non-release branches get the
> boot
> after a certain amount inactivity. If you want to archive something,
> that's
> what personal git repos are for.
> --Jason
> 
I think it makes sense to have a publicly accessible archive repo for
nuked feature branches otherwise potentially useful code could just be
lost.



signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Brian Paul]

On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand 
wrote:

>
> On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
> >
> > 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..)
>
> I agree. Sometimes something big comes up that's not ready for merging
> such as amdgpu or our recently pushed Vulkan driver.  However, those should
> only be temporary and removed once the work is complete.  I saw a
> "broadwell" branch in there which is probably at least 2 years old and
> completely subsumed by master.  We don't want to be archiving random junk
> in the main tree.
>
> I'd be fine with a timeout system where non-release branches get the boot
> after a certain amount inactivity. If you want to archive something, that's
> what personal git repos are for.
>

I'm OK with deleting old branches too.

I don't know much about git under the hood- would deleting old branches
actually delete the objects on those branches and make the database
smaller?  If so, I'm guessing it probably wouldn't amount to much.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Clark]

On Sat, Feb 20, 2016 at 4:41 PM, Jason Ekstrand  wrote:
> On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
>>
>> 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..)
>
> I agree. Sometimes something big comes up that's not ready for merging such
> as amdgpu or our recently pushed Vulkan driver.  However, those should only
> be temporary and removed once the work is complete.  I saw a "broadwell"
> branch in there which is probably at least 2 years old and completely
> subsumed by master.  We don't want to be archiving random junk in the main
> tree.
>
> I'd be fine with a timeout system where non-release branches get the boot
> after a certain amount inactivity. If you want to archive something, that's
> what personal git repos are for.

fwiw, I would totally ack a plan to automatically delete inactive
topic branches after N months of inactivity (where I'd be fine with
N==2 or even as high as N==12 but I think you'd have a hard time
convincing me for N>12)

Bonus points if someone wanted to archive old branches somewhere.. but
I don't care strongly about that..

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Sat, Feb 20, 2016 at 5:36 PM, Rob Clark  wrote:

> On Sat, Feb 20, 2016 at 4:41 PM, Jason Ekstrand 
> wrote:
> > On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
> >>
> >> 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..)
> >
> > I agree. Sometimes something big comes up that's not ready for merging
> such
> > as amdgpu or our recently pushed Vulkan driver.  However, those should
> only
> > be temporary and removed once the work is complete.  I saw a "broadwell"
> > branch in there which is probably at least 2 years old and completely
> > subsumed by master.  We don't want to be archiving random junk in the
> main
> > tree.
> >
> > I'd be fine with a timeout system where non-release branches get the boot
> > after a certain amount inactivity. If you want to archive something,
> that's
> > what personal git repos are for.
>
> fwiw, I would totally ack a plan to automatically delete inactive
> topic branches after N months of inactivity (where I'd be fine with
> N==2 or even as high as N==12 but I think you'd have a hard time
> convincing me for N>12)
>
> Bonus points if someone wanted to archive old branches somewhere.. but
> I don't care strongly about that..
>

Chad has some nifty way of archiving branches where they still exist and
have names but are hidden.  I don't remember how it works though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Feb 20, 2016 1:19 PM, "Rob Clark"  wrote:
>
> 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..)

I agree. Sometimes something big comes up that's not ready for merging such
as amdgpu or our recently pushed Vulkan driver.  However, those should only
be temporary and removed once the work is complete.  I saw a "broadwell"
branch in there which is probably at least 2 years old and completely
subsumed by master.  We don't want to be archiving random junk in the main
tree.

I'd be fine with a timeout system where non-release branches get the boot
after a certain amount inactivity. If you want to archive something, that's
what personal git repos are for.
--Jason

> BR,
> -R
>
> On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák  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 
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 
wrote:
>  On Mon, Jun 22, 2015 at 11:30 AM, Christian König
>   wrote:
> > On 22.06.2015 15:41, Ilia Mirkin wrote:
> >>
> >> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard 
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 <
imir...@alum.mit.edu>
>  wrote:
> >
> > On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <
mic...@daenzer.net>
> > wrote:
> >>
> >> On 22.06.2015 00:31, Ilia Mirkin wrote:
> >>>
> >>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov
> >>>  wrote:
> 
>  On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
> >
> > Ilia Mirkin  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
> 

Re: [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  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  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  wrote:
 On Mon, Jun 22, 2015 at 11:30 AM, Christian König
  wrote:
> On 22.06.2015 15:41, Ilia Mirkin wrote:
>>
>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard  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 
 wrote:
>
> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer 
> wrote:
>>
>> On 22.06.2015 00:31, Ilia Mirkin wrote:
>>>
>>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov
>>>  wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
>
> Ilia Mirkin  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 

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

[Ilia Mirkin]

On Mon, Jun 22, 2015 at 11:30 AM, Christian König
deathsim...@vodafone.de wrote:
 On 22.06.2015 15:41, Ilia Mirkin wrote:

 On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu
 wrote:

 On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:

 Ilia Mirkin imir...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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 imir...@alum.mit.edu wrote:
 On Mon, Jun 22, 2015 at 11:30 AM, Christian König
 deathsim...@vodafone.de wrote:
 On 22.06.2015 15:41, Ilia Mirkin wrote:

 On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu
 wrote:

 On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:

 Ilia Mirkin imir...@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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Christian König]

On 22.06.2015 15:41, Ilia Mirkin wrote:

On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu wrote:

On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:

On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:

Ilia Mirkin imir...@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.


Regards,
Christian.



   -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ian Romanick]

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 imir...@alum.mit.edu wrote:
 On Mon, Jun 22, 2015 at 11:30 AM, Christian König
 deathsim...@vodafone.de wrote:
 On 22.06.2015 15:41, Ilia Mirkin wrote:

 On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu
 wrote:

 On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:

 Ilia Mirkin imir...@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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com 
 wrote:
 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
 Ilia Mirkin imir...@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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

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 i...@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 imir...@alum.mit.edu wrote:
 On Mon, Jun 22, 2015 at 11:30 AM, Christian König
 deathsim...@vodafone.de wrote:
 On 22.06.2015 15:41, Ilia Mirkin wrote:

 On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu
 wrote:

 On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:

 Ilia Mirkin imir...@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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

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

[Ilia Mirkin]

On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard t...@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 imir...@alum.mit.edu wrote:
  On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com wrote:
  On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
  Ilia Mirkin imir...@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.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Tom Stellard]

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 imir...@alum.mit.edu wrote:
  On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com 
  wrote:
  On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
  Ilia Mirkin imir...@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.

-Tom

 Marek
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
 Ilia Mirkin imir...@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).

On a mildly related topic - does anyone know what the 'mesa-test' repo
is all about ? There is a similar one for xorg-server, both of which
seems like a temporary experiment, which someone forgot to delete. There
hasn't been any response on #freedesktop on the topic.

Cheers
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ilia Mirkin]

On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
 Ilia Mirkin imir...@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).

That still leaves a ton around, and curiously removes mesa_7_5 and mesa_7_6.

$ diff -u (git branch -r | grep origin) (git branch -r --no-merged
origin/master | grep origin)
--- /dev/fd/63  2015-06-21 11:29:30.537590950 -0400
+++ /dev/fd/62  2015-06-21 11:29:30.537590950 -0400
@@ -14,24 +14,15 @@
   origin/9.0
   origin/9.1
   origin/9.2
-  origin/965-glsl
   origin/965-ttm
-  origin/HEAD - origin/master
   origin/R300_DRIVER
   origin/amdgpu
   origin/arb_copy_buffer
   origin/arb_fbo
-  origin/arb_fbo_cleanup
   origin/arb_fbo_indirect
   origin/arb_geometry_shader4
-  origin/arb_half_float_vertex
-  origin/arb_map_buffer_range
   origin/arb_robustness
-  origin/arb_sampler_objects
   origin/arb_sync
-  origin/arb_vertex_array_object
-  origin/asm-shader-rework-1
-  origin/asm-shader-rework-2
   origin/asm-shader-rework-3
   origin/auto-cherry-for-8.0
   origin/autoconf
@@ -39,15 +30,12 @@
   origin/cxx-1-branch
   origin/d3d1x-addons
   origin/direct_state_access
-  origin/draw-instanced
   origin/draw-ply
   origin/dri2-swapbuffers
-  origin/drm-gem
   origin/egl-drm
   origin/embedded-1-branch
   origin/embedded-2-branch
   origin/experimental-1
-  origin/ext-provoking-vertex
   origin/flex-and-bison-required
   origin/floating
   origin/fp64_floor
@@ -55,60 +43,37 @@
   origin/gallium-0.1
   origin/gallium-0.1-dri
   origin/gallium-0.1-dri2
-  origin/gallium-0.2
   origin/gallium-array-textures
   origin/gallium-buffer-usage-cleanup
   origin/gallium-clip-state
   origin/gallium-compute
-  origin/gallium-context-transfers-2
   origin/gallium-cylindrical-wrap
   origin/gallium-double-opcodes
-  origin/gallium-drm-driver-descriptor
-  origin/gallium-dynamicstencilref
   origin/gallium-fb-dimensions
   origin/gallium-float--format
-  origin/gallium-format-cleanup
-  origin/gallium-front-ccw
   origin/gallium-gpu4-texture-opcodes
   origin/gallium-integer-opcodes
   origin/gallium-llvmpipe
   origin/gallium-mesa-7.4
-  origin/gallium-msaa
-  origin/gallium-new-formats
-  origin/gallium-newclear
   origin/gallium-no-nvidia-opcodes
-  origin/gallium-no-rhw-position
   origin/gallium-no-texture-blanket
-  origin/gallium-nopointsizeminmax
   origin/gallium-render-condition-predicate
   origin/gallium-resource-sampling
   origin/gallium-resources
-  origin/gallium-sampler-view
   origin/gallium-softpipe-winsys
-  origin/gallium-st-api
-  origin/gallium-st-api-dri
   origin/gallium-stream-out
   origin/gallium-sw-api
   origin/gallium-tgsi-semantic-cleanup
-  origin/gallium-userbuf
   origin/gallium-util-format-is-supported
-  origin/gallium-vertexelementcso
-  origin/gallium_draw_llvm
   origin/gallivm-call
-  origin/glapi-reorg
   origin/gles3
-  origin/glsl-compiler-1
   origin/glsl-continue-return
   origin/glsl-continue-return-7-5
   origin/glsl-pp-rework-1
-  origin/glsl-pp-rework-2
   origin/glsl-to-tgsi
-  origin/glsl2
   origin/glsl2-llvm
   origin/glsl2-lower-variable-indexing
-  origin/graw-tests
   origin/hw_gl_select
-  origin/i915tex-pageflip
   origin/i915tex-zone-rendering
   origin/i915tex_branch
   origin/i915tex_privbuffers
@@ -117,21 +82,15 @@
   origin/intel-2008-q3
   origin/intel-2008-q4
   origin/kasanen-post-process
-  origin/kasanen-post-process-v2
-  origin/llvm-cliptest-viewport
   origin/llvm-context
   origin/llvmpipe-duma
   origin/llvmpipe-rast-64
   origin/llvmpipe-wider-regs
-  origin/loader-v4
   origin/lp-line-rast
-  origin/lp-offset-twoside
-  origin/lp-setup-llvm
   origin/lp-surface-tiling
   origin/map-tex-branch
   origin/map-texture-image-v4
   origin/map-texture-image-v5
-  origin/master
   origin/mesa
   origin/mesa_20040127_branch
   origin/mesa_20040309_branch
@@ -148,45 +107,27 @@
   origin/mesa_7_2_branch
   origin/mesa_7_4_branch

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

[Michel Dänzer]

On 22.06.2015 00:31, Ilia Mirkin wrote:
 On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov emil.l.veli...@gmail.com 
 wrote:
 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
 Ilia Mirkin imir...@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.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ilia Mirkin]

On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer mic...@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.veli...@gmail.com 
 wrote:
 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
 Ilia Mirkin imir...@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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eirik Byrkjeflot Anonsen]

Ilia Mirkin imir...@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)

eirik
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Christian König]

Hi Ilia,

oh, yes please. Especially since some people tend to completely mirror 
the mesa master repository including all those old branches.


This sometimes creates quite a mess.

Regards,
Christian.

On 20.06.2015 02:10, Ilia Mirkin wrote:

Hello,

There are a *ton* of branches in the upstream mesa git. Here is a full list:

   origin/10.0
   origin/10.1
   origin/10.2
   origin/10.3
   origin/10.4
   origin/10.5
   origin/10.6
   origin/7.10
   origin/7.11
   origin/7.8
   origin/7.8-gles
   origin/7.9
   origin/8.0
   origin/9.0
   origin/9.1
   origin/9.2
   origin/965-glsl
   origin/965-ttm
   origin/HEAD - origin/master
   origin/R300_DRIVER
   origin/amdgpu
   origin/arb_copy_buffer
   origin/arb_fbo
   origin/arb_fbo_cleanup
   origin/arb_fbo_indirect
   origin/arb_geometry_shader4
   origin/arb_half_float_vertex
   origin/arb_map_buffer_range
   origin/arb_robustness
   origin/arb_sampler_objects
   origin/arb_sync
   origin/arb_vertex_array_object
   origin/asm-shader-rework-1
   origin/asm-shader-rework-2
   origin/asm-shader-rework-3
   origin/auto-cherry-for-8.0
   origin/autoconf
   origin/broadwell
   origin/cxx-1-branch
   origin/d3d1x-addons
   origin/direct_state_access
   origin/draw-instanced
   origin/draw-ply
   origin/dri2-swapbuffers
   origin/drm-gem
   origin/egl-drm
   origin/embedded-1-branch
   origin/embedded-2-branch
   origin/experimental-1
   origin/ext-provoking-vertex
   origin/flex-and-bison-required
   origin/floating
   origin/fp64_floor
   origin/frontbuffer-removal
   origin/gallium-0.1
   origin/gallium-0.1-dri
   origin/gallium-0.1-dri2
   origin/gallium-0.2
   origin/gallium-array-textures
   origin/gallium-buffer-usage-cleanup
   origin/gallium-clip-state
   origin/gallium-compute
   origin/gallium-context-transfers-2
   origin/gallium-cylindrical-wrap
   origin/gallium-double-opcodes
   origin/gallium-drm-driver-descriptor
   origin/gallium-dynamicstencilref
   origin/gallium-fb-dimensions
   origin/gallium-float--format
   origin/gallium-format-cleanup
   origin/gallium-front-ccw
   origin/gallium-gpu4-texture-opcodes
   origin/gallium-integer-opcodes
   origin/gallium-llvmpipe
   origin/gallium-mesa-7.4
   origin/gallium-msaa
   origin/gallium-new-formats
   origin/gallium-newclear
   origin/gallium-no-nvidia-opcodes
   origin/gallium-no-rhw-position
   origin/gallium-no-texture-blanket
   origin/gallium-nopointsizeminmax
   origin/gallium-render-condition-predicate
   origin/gallium-resource-sampling
   origin/gallium-resources
   origin/gallium-sampler-view
   origin/gallium-softpipe-winsys
   origin/gallium-st-api
   origin/gallium-st-api-dri
   origin/gallium-stream-out
   origin/gallium-sw-api
   origin/gallium-tgsi-semantic-cleanup
   origin/gallium-userbuf
   origin/gallium-util-format-is-supported
   origin/gallium-vertexelementcso
   origin/gallium_draw_llvm
   origin/gallivm-call
   origin/glapi-reorg
   origin/gles3
   origin/glsl-compiler-1
   origin/glsl-continue-return
   origin/glsl-continue-return-7-5
   origin/glsl-pp-rework-1
   origin/glsl-pp-rework-2
   origin/glsl-to-tgsi
   origin/glsl2
   origin/glsl2-llvm
   origin/glsl2-lower-variable-indexing
   origin/graw-tests
   origin/hw_gl_select
   origin/i915tex-pageflip
   origin/i915tex-zone-rendering
   origin/i915tex_branch
   origin/i915tex_privbuffers
   origin/index-swtnl-0.1
   origin/indirect-vbo
   origin/intel-2008-q3
   origin/intel-2008-q4
   origin/kasanen-post-process
   origin/kasanen-post-process-v2
   origin/llvm-cliptest-viewport
   origin/llvm-context
   origin/llvmpipe-duma
   origin/llvmpipe-rast-64
   origin/llvmpipe-wider-regs
   origin/loader-v4
   origin/lp-line-rast
   origin/lp-offset-twoside
   origin/lp-setup-llvm
   origin/lp-surface-tiling
   origin/map-tex-branch
   origin/map-texture-image-v4
   origin/map-texture-image-v5
   origin/master
   origin/mesa
   origin/mesa_20040127_branch
   origin/mesa_20040309_branch
   origin/mesa_20050114_branch
   origin/mesa_3_2_dev
   origin/mesa_3_3_texture_env_combine2
   origin/mesa_3_4_branch
   origin/mesa_4_0_branch
   origin/mesa_5_0_branch
   origin/mesa_6_0_branch
   origin/mesa_6_2_branch
   origin/mesa_6_4_branch
   origin/mesa_7_0_branch
   origin/mesa_7_2_branch
   origin/mesa_7_4_branch
   origin/mesa_7_4_idr_staging
   origin/mesa_7_5_branch
   origin/mesa_7_6_branch
   origin/mesa_7_7_branch
   origin/nv50-compiler
   origin/nvc0
   origin/openchrome-branch
   origin/opengl-es
   origin/opengl-es-v2
   origin/openvg-1.0
   origin/outputswritten64
   origin/pipe-video
   origin/primitive-restart
   origin/r300-bufmgr
   origin/r500-support
   origin/r6xx-r7xx-support
   origin/r6xx-rewrite
   origin/radeon-rewrite
   origin/remove-copyteximage-hook
   origin/remove-driver-date
   origin/remove-max-width
   origin/remove-max-width-2
   origin/remove-redundant-helpers
   origin/renderbuffer-cleanups-v2
   origin/shader-file-reorg
   origin/shader-work
   origin/softpipe_0_1_branch
   

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

[Ilia Mirkin]

Hello,

There are a *ton* of branches in the upstream mesa git. Here is a full list:

  origin/10.0
  origin/10.1
  origin/10.2
  origin/10.3
  origin/10.4
  origin/10.5
  origin/10.6
  origin/7.10
  origin/7.11
  origin/7.8
  origin/7.8-gles
  origin/7.9
  origin/8.0
  origin/9.0
  origin/9.1
  origin/9.2
  origin/965-glsl
  origin/965-ttm
  origin/HEAD - origin/master
  origin/R300_DRIVER
  origin/amdgpu
  origin/arb_copy_buffer
  origin/arb_fbo
  origin/arb_fbo_cleanup
  origin/arb_fbo_indirect
  origin/arb_geometry_shader4
  origin/arb_half_float_vertex
  origin/arb_map_buffer_range
  origin/arb_robustness
  origin/arb_sampler_objects
  origin/arb_sync
  origin/arb_vertex_array_object
  origin/asm-shader-rework-1
  origin/asm-shader-rework-2
  origin/asm-shader-rework-3
  origin/auto-cherry-for-8.0
  origin/autoconf
  origin/broadwell
  origin/cxx-1-branch
  origin/d3d1x-addons
  origin/direct_state_access
  origin/draw-instanced
  origin/draw-ply
  origin/dri2-swapbuffers
  origin/drm-gem
  origin/egl-drm
  origin/embedded-1-branch
  origin/embedded-2-branch
  origin/experimental-1
  origin/ext-provoking-vertex
  origin/flex-and-bison-required
  origin/floating
  origin/fp64_floor
  origin/frontbuffer-removal
  origin/gallium-0.1
  origin/gallium-0.1-dri
  origin/gallium-0.1-dri2
  origin/gallium-0.2
  origin/gallium-array-textures
  origin/gallium-buffer-usage-cleanup
  origin/gallium-clip-state
  origin/gallium-compute
  origin/gallium-context-transfers-2
  origin/gallium-cylindrical-wrap
  origin/gallium-double-opcodes
  origin/gallium-drm-driver-descriptor
  origin/gallium-dynamicstencilref
  origin/gallium-fb-dimensions
  origin/gallium-float--format
  origin/gallium-format-cleanup
  origin/gallium-front-ccw
  origin/gallium-gpu4-texture-opcodes
  origin/gallium-integer-opcodes
  origin/gallium-llvmpipe
  origin/gallium-mesa-7.4
  origin/gallium-msaa
  origin/gallium-new-formats
  origin/gallium-newclear
  origin/gallium-no-nvidia-opcodes
  origin/gallium-no-rhw-position
  origin/gallium-no-texture-blanket
  origin/gallium-nopointsizeminmax
  origin/gallium-render-condition-predicate
  origin/gallium-resource-sampling
  origin/gallium-resources
  origin/gallium-sampler-view
  origin/gallium-softpipe-winsys
  origin/gallium-st-api
  origin/gallium-st-api-dri
  origin/gallium-stream-out
  origin/gallium-sw-api
  origin/gallium-tgsi-semantic-cleanup
  origin/gallium-userbuf
  origin/gallium-util-format-is-supported
  origin/gallium-vertexelementcso
  origin/gallium_draw_llvm
  origin/gallivm-call
  origin/glapi-reorg
  origin/gles3
  origin/glsl-compiler-1
  origin/glsl-continue-return
  origin/glsl-continue-return-7-5
  origin/glsl-pp-rework-1
  origin/glsl-pp-rework-2
  origin/glsl-to-tgsi
  origin/glsl2
  origin/glsl2-llvm
  origin/glsl2-lower-variable-indexing
  origin/graw-tests
  origin/hw_gl_select
  origin/i915tex-pageflip
  origin/i915tex-zone-rendering
  origin/i915tex_branch
  origin/i915tex_privbuffers
  origin/index-swtnl-0.1
  origin/indirect-vbo
  origin/intel-2008-q3
  origin/intel-2008-q4
  origin/kasanen-post-process
  origin/kasanen-post-process-v2
  origin/llvm-cliptest-viewport
  origin/llvm-context
  origin/llvmpipe-duma
  origin/llvmpipe-rast-64
  origin/llvmpipe-wider-regs
  origin/loader-v4
  origin/lp-line-rast
  origin/lp-offset-twoside
  origin/lp-setup-llvm
  origin/lp-surface-tiling
  origin/map-tex-branch
  origin/map-texture-image-v4
  origin/map-texture-image-v5
  origin/master
  origin/mesa
  origin/mesa_20040127_branch
  origin/mesa_20040309_branch
  origin/mesa_20050114_branch
  origin/mesa_3_2_dev
  origin/mesa_3_3_texture_env_combine2
  origin/mesa_3_4_branch
  origin/mesa_4_0_branch
  origin/mesa_5_0_branch
  origin/mesa_6_0_branch
  origin/mesa_6_2_branch
  origin/mesa_6_4_branch
  origin/mesa_7_0_branch
  origin/mesa_7_2_branch
  origin/mesa_7_4_branch
  origin/mesa_7_4_idr_staging
  origin/mesa_7_5_branch
  origin/mesa_7_6_branch
  origin/mesa_7_7_branch
  origin/nv50-compiler
  origin/nvc0
  origin/openchrome-branch
  origin/opengl-es
  origin/opengl-es-v2
  origin/openvg-1.0
  origin/outputswritten64
  origin/pipe-video
  origin/primitive-restart
  origin/r300-bufmgr
  origin/r500-support
  origin/r6xx-r7xx-support
  origin/r6xx-rewrite
  origin/radeon-rewrite
  origin/remove-copyteximage-hook
  origin/remove-driver-date
  origin/remove-max-width
  origin/remove-max-width-2
  origin/remove-redundant-helpers
  origin/renderbuffer-cleanups-v2
  origin/shader-file-reorg
  origin/shader-work
  origin/softpipe_0_1_branch
  origin/sprite-coord
  origin/st-mesa-per-context-shaders
  origin/st-vbo
  origin/texfilter_float_branch
  origin/texformat-xrgb
  origin/texman_0_1_branch
  origin/texmem-1.0
  origin/texmem_0_2_branch
  origin/texmem_0_3_branch
  origin/texture_rg
  origin/texture_rg-2
  origin/thalloc
  origin/vbo_0_1_branch
  origin/vtx-0-1-branch
  origin/vtx-0-2-branch
  origin/xa_branch

The vast, vast, *vast*, majority of these appear to be old