[Intel-gfx] Cleaning up branches in xf86-video-intel
cworth at cworth.org
Mon Mar 9 16:46:35 PDT 2009
I just created a new branch in the xf86-video-intel module with the very
unassuming name of:
This minimalist naming matches the 2.6 branch name Eric recently created
as well as tags he just made such as 2.6.2 and 2.6.3.
The branch namespace is still extremely cluttered though, and I'd like
to clean it up. Here are some things I propose to do. Please let me know
if any of these changes would cause you problems, (such as if you have
scripts that depend on the old names, it looks like I'm throwing away
real code, etc).
Rename old release-branches:
xf86-video-intel-2.6-branch becomes 2.6[*]
xf86-video-intel-2.5-branch becomes 2.5
[*] Eric already created a 2.6 branch, so just need
to delete the now-stale xf86-video-intel-2.6 branch.
Delete fully-merged branches.
The following branches contain no commits that are
unreachable from master so they have no current
use as a branch:
965-xvmc COMPOSITEWRAP STSF-CURRENT XORG-STABLE
dri2 drm-gem fbc i830-pageflip integrated-hdmi
lg3d lg3d-dev-0-6-1-current lg3d-dev-0-6-1-latest
lg3d-dev-0-6-latest lg3d-event lukas-resume master
mergedfb modesetting modesetting-gem
modesetting-rotation nonrandr-setup pfit
projective-965 restructure-outputs sco_port_update
Delete "CVS merge" branches.
The following branches each contain a small number of commits (1
to 8 or so) that appear to each capture the result of a "merge",
(presumably from CVS), though captured not as a git merge, but
instead a monolithic commit. I'm inclined to believe that there's
nothing useful here.
CYGWIN DAMAGE-XFIXES IPv6-REVIEW XACE-SELINUX
XEVIE XINERAMA_2 XORG-CURRENT XORG-RELEASE-1
XORG-RELEASE-1-STSF XORG-RELEASE-1-TM XPRINT
lg3d-dev-0-6-1 lg3d-dev-0-6-1-1 lg3d-dev-0-6-2
lg3d-dev-0-7-0 lg3d-dev-0-7-1 lg3d-master
After that, there will be about 15 branches left. I'll follow up in a
later mail with a description of each of those, (number of commits,
active committer, and most-recent commit date), so people can tell me
which are active feature branches that should stick around, and which
are old and dead and should be deleted.
And if we get all of those cleaned up, we might decide to keep future
feature branches in personal repositories rather than in the central
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/intel-gfx/attachments/20090309/16fc3dbe/attachment.pgp
More information about the Intel-gfx