This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Moving to git
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: ramrad01 at arm dot com, 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 15:59:58 +0200
- 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 2015.08.21 at 06:47 -0700, H.J. Lu wrote:
> On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
> <ramana.gcc@googlemail.com> wrote:
> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <jwakely.gcc@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?
The Linux kernel uses merges all the time, yet "git bisect" works
without any issues. So this not a reason to forbid merges.
BTW while I have your attention: Why are you constantly creating
(rebasing) and deleting branches? Why not simply use a local git tree
for this purpose?
--
Markus