This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Jason Merrill <jason at redhat 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 14:37:18 +0100
- 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>
- Reply-to: ramrad01 at arm dot com
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <email@example.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.
My 10 paise.