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