Re: Moving to git

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill <jason@redhat.com> 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
history.

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

Richard.

> Jason
>