This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: ramrad01 at arm dot com
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, 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 06:47:50 -0700
- 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>
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
> 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.
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?