Re: Moving to git

[Jason Merrill <jason at redhat dot com>]

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?

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

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

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

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.

Jason