This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gnu dot org" <gcc at gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 21 Aug 2015 10:26:22 +0200
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com> <55D61B23 dot 3000309 at redhat dot com> <55D63403 dot 4000603 at redhat dot com>
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill <firstname.lastname@example.org> wrote:
> On 08/20/2015 02:23 PM, Jeff Law wrote:
>> 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.
> Jakub: How about using git bisect instead, and identify the compiler
> binaries with the git commit sha1?
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good, the future bad) - I've tried to find a change that was _fixing_
a problem, something that doesn't seem to be supported. Heh. Well,
just "fixed" the test script.
>>> 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.
> Makes sense.
Well, I think that all public branches should follow the trunk model - if only
to make merging a dev branch to trunk possible without introducing messy
>> 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?
> Currently such branches are at the top level, but I think it would make
> sense to categorize them more, including moving many existing branches into
> subdirectories indicating that they were either merged or abandoned. We
> might want to delete some old branches entirely.
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in namespace $user? And make those
not automatically pulled?
So require some super-powers to create a toplevel branch?
>> 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.
> Absolutely, a non-fast-forward push is anathema for anything other people
> might be working on. The git repository already prohibits this; people that
> want to push-rebase-push their own branches need to delete the branch before
> pushing again.
> There are many opinions about best practices, but I don't think any of them
> are enough better than what we already do to justify a change.
> 'git help workflow' describes how development of git itself works: they have
> "maint", "master" and "next" branches that would roughly correspond to our
> latest release branch, trunk, and next-stage-1-trunk. Having a "next"
> branch could be useful, but I think we deliberately don't have one currently
> in order to focus people on release preparation during stage 3 rather than
> it always being stage 1 somewhere.
Yep. I'd like to keep that "feature" (even though it doesn't really work).
> One interesting thing that they do is to keep earlier branches merged into
> later branches, so 4.9 into 5, 5 into trunk, trunk into next. This is an
> interesting discipline, but I'm not sure it is of much practical value.
So to forward port fixes? We're usually working the other way around,
fix trunk first, then backport. I don't think we want any merges across