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
