This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Jeff Law <law at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>, "gcc at gnu dot org" <gcc at gnu dot org>
- Date: Thu, 20 Aug 2015 12:23:31 -0600
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com>
On 08/20/2015 11:57 AM, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more information about
Our current workflow translates over to a git master pretty easily:
basically, in the current git-svn workflow, replace git svn rebase and
git svn dcommit with git pull --rebase and git push.
It should be pretty straightforward to use the existing git mirror as
the master repository; the main adjustment I'd want to make is rewriting
the various subdirectory branches to be properly represented in git.
This is straightforward, but we'll want to stop SVN commits to
subdirectory branches shortly before the changeover.
I think we also need to convert our SVN hooks into git hooks, but
presumably that'll be easy.
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
binaries he keeps around for very fast bisection. I think when we
talked about it last year, he just needs an increasing # for each
commit, presumably starting with whatever the last SVN ID is when we
make the change.
Presumably for branch/tag creation the primary concern is the namespace?
I think if we define a namespace folks can safely use without getting
in the way of the release managers we get most of what we need.
It would be good to have a more explicit policy on branch/tag creation,
rebasing, and deletion in the git world where branches are lighter
weight and so more transient.
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient branch,
push-rebase-push on that branch, then later remove it, I tend to think,
why not let them.
Do we want a namespace for branches which are perhaps not as transient
in nature, ie longer term projects, projects on-ice or works-in-progress
that we don't want to lose?
As far as the trunk and release branches, are there any best practices
out there that we can draw from? Obviously doing things like
push-rebase-push is bad. Presumably there's others.