This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to git

On 2015.08.21 at 06:47 -0700, H.J. Lu wrote:
> On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
> <> wrote:
> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <> 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 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]