[Top] [All Lists]

Re: [RFC] Handling of reviewed patch series

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [RFC] Handling of reviewed patch series
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 14 Dec 2013 10:59:52 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131213231401.GZ10988@dastard>
References: <20131213053611.GQ10988@dastard> <20131213185618.GJ1935@xxxxxxx> <20131213231401.GZ10988@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
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.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>