On 08/21/2015 09:47 AM, H.J. Lu wrote:
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
That is, all pushes to official branches must be fast-forward.
b. no git merges from feature branches.
I think that's right at least initially, but I would note that git merge
--squash doesn't count as a merge for this rule and is indeed the
recommended way to merge a feature branch.
Jason
