This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Jason Merrill <jason at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, ramrad01 at arm dot com
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Jeff Law <law at redhat dot com>, "gcc at gnu dot org" <gcc at gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 21 Aug 2015 10:32:14 -0400
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com> <55D61B23 dot 3000309 at redhat dot com> <55D63403 dot 4000603 at redhat dot com> <CAJA7tRahuaA36w76YD0nE+6ur1Y8T1ThZ8ssSmGgRmzT9bUcBA at mail dot gmail dot com> <CAH6eHdTcMMgHBax=x42aAE+LdRyKnzNhaLxvc_VcPQVP_P7nog at mail dot gmail dot com> <CAJA7tRYwEMxTrFmFNYg0Mh9QTLyNOtVPH7kjjSTzS82RPyXHfQ at mail dot gmail dot com> <CAMe9rOpV3G_=ZFWiyRk9bThXEA=_JUJrqEi8hmqLW0hKZLUhqg at mail dot gmail dot com>
On 08/21/2015 09:47 AM, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <firstname.lastname@example.org> 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
On the FSF trunk and the main release branches - I agree this is a
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
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.