This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed gfortran development branch
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- Cc: Toon Moene <toon at moene dot org>, Richard Guenther <richard dot guenther at gmail dot com>, Jerry DeLisle <jvdelisle at verizon dot net>, fortran at gcc dot gnu dot org, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Thu, 19 Mar 2009 14:24:33 -0700
- Subject: Re: Proposed gfortran development branch
- References: <1237423478.8965.8.camel@eeepc> <84fc9c000903190306p2eeefd2cu6b374e2398960840@mail.gmail.com> <49C2930D.2000405@moene.org> <20090319191433.GD22388@ins.uni-bonn.de>
- Reply-to: janis187 at us dot ibm dot com
On Thu, 2009-03-19 at 20:14 +0100, Ralf Wildenhues wrote:
> * Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
> > Richard Guenther wrote:
> >>
> >> Note that merging the branch will be painful (as in, please dissect
> >> the branch into the individual patches again to make bisecting the
> >> trunk SVN possible).
>
> > I agree about the bisecting-in-case-of-bugs issue.
>
> For what little the opinion of a mostly-lurker is worth here, but I
> disagree on the bisecting-in-case-of-bugs issue. Today, there exist
> version control systems that can deal with bisecting over nonlinear
> histories, as well as temporarily linearizing a history (in case the
> merge point, rather than a single patch on a merged branch is at fault).
> It even works, too.
>
> That's only tangent to the real issue here, of course.
I'll continue along that tangent to point out that after a reghunt
for a GCC patch identifies a merge from a branch it's easy to set up
a new reghunt of that branch.
Janis