Re: [RFC] Handling of reviewed patch series

[Dave Chinner <david@fromorbit.com>]

On Sat, Dec 14, 2013 at 10:14:01AM +1100, Dave Chinner wrote:
> On Fri, Dec 13, 2013 at 12:56:18PM -0600, Ben Myers wrote:
> > On Fri, Dec 13, 2013 at 04:36:11PM +1100, Dave Chinner wrote:
> > > like the -next tree, it is a branch that can be rebased without
> > > impacting the history of the code in the topic branches because
> > > it's just a merge target.
> > > 
> > > What this means is that development can be done against the
> > > master branch without fear of conflicting with other changes
> > > that are being done. Testing, however, can target the for-next
> > > branch, and local integration testing can be done simply by
> > > merging a local topic branch into a local for-next branch....
> > 
> > I'm not too keen on rebasing a published branch, mostly because I
> > tend to log test results by commit id.  If there is a way to keep
> > the initial commit id stable and in the repo so it can be
> > referenced later it would be better.  e.g.  In the [unlikely]
> > event that the for-next branch does need to be rebased, tag it
> > first.
> 
> Well, I'd be surprised if we have to rebase the for-next branch very
> often. If we plan things correctly (e.g. delay disruptive topic
> branchs to the next release, and merge them immediately after an
> -rc1 update) I think we can effectively avoid rebases. The
> difference is that if we ever need to do a rebase, we can.

FWIW, I just realised that this isn't a huge problem. Rebasing the
for-next branch by remerging topic branches is not going to change
the commit IDs of the commits in the topic branches - it only
changes the commit ID of the merge commits. Hence if you are
tracking commit IDs of the patches rather than the merges, a
for-next rebase won't affect your tracking at all.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs