> > 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.
On the FSF trunk and the main release branches - I agree this is a complete no-no. A push-rebase-push development model is possible / may be useful when the developers collaborating on that branch agree on that model. git config branch.<branch-name>.rebase true - tells git to rebase instead of merging when pulling into <branch-name> branch. In private development branches, instead of creating bazillion branches and deleting them for ever for something like this - when trying to maintain a set of patches on top of trunk it's been useful in the past to allow for a push rebase push style workflow. While rebasing in this flow, what we also did was to create tags for each of the rebase points which essentially meant that at any point of time it was possible to have a linear view of history for everything on that particular branch. This was useful in cases where we had particularly long running branches. However when we transitioned to this there was a bit of pain in that every developer working on those branches needed to mark the appropriate branches as rebase only. Given current practice of merging development branches into mainline being effectively a "rebase" which allows for the linear history on mainline to be retained, we should document very clearly how git merge should be used on mainline from development branches. > > 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. The "next" name seems to be abused in many tools around git. This suggestion from git workflow is one, the other use of "next" I've seen is with gerrit, where "next" refers to a "next" commit that's been put up for code review. > > 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. I don't see how that fits with our development model. regards Ramana > > Jason >
