This is the mail archive of the 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 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.


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