This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to git


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]