On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <jwakely....@gmail.com> > wrote: >> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: >>>> >>>> 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. >> >> Teams following a different model could use a separate repo shared by >> those developers, not the gcc.gnu.org one. It's much easier to do that >> with git. > > Yes you are right they sure can, but one of the reasons that teams are > doing their development on a feature branch is so that they can obtain > feedback and collaborate with others in the community. People wanting > to adopt more aggressive uses of git should be allowed to do so in > their private branches as long as they are not able to mess up the > official branches in the repository. > > If there is no way to have some branches in a repo allow rebasing and > others not, that's fine but I'd like to know that's the case. > > Adopting restrictions on the official branches is quite right (list > below not extensive but it sounds like) ... > > a. no rebase / rewriting history > b. no git merges from feature branches.
One very frustrating thing for me is "git bisect" doesn't always work. I think cherry-pick is OK, but probably not rebase nor merge. Can we enforce that "git bisect" must work on official branches? -- H.J.
