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
this discussion?
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.
Right.

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.
Seems reasonable.

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.

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

Reply via email to