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
