Re: [XFS SUMMIT] Ugh, Rebasing Sucks!

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Fri, May 29, 2020 at 08:39:32AM +1000, Dave Chinner wrote:
> On Wed, May 27, 2020 at 07:44:10PM -0700, Darrick J. Wong wrote:
> > On Thu, May 28, 2020 at 10:03:51AM +1000, Dave Chinner wrote:
> > > From my perspective, an update from for-next after the -rc6 update
> > > gets me all the stuff that will be in the next release. That's the
> > > major rebase for my work, and everything pulled in from for-next
> > > starts getting test coverage a couple of weeks out from the merge
> > > window.  Once the merge window closes, another local update to the
> > > -rc1 kernel (which should be a no-op for all XFS work) then gets
> > > test coverage for the next release. -rc1 to -rc4 is when
> > > review/rework for whatever I want merged in -rc4/-rc6 would get
> > > posted to the list....
> > 
> > <nod>
> > 
> > My workflow is rather different -- I rebase my dev tree off the latest
> > rc every week, and when a series is ready I port it to a branch off of
> > for-next.
> 
> I do actually update the base kernel quite frequently - usually
> every monday after a -rc is released. This is easy, and rarely
> causes rebase issues because all the XFS changes in the base tree
> have already been in the for-next tree. i.e. my typical weekly
> "rebase" is:
> 
> git remote update
> for each git branch:
> 	guilt pop -a
> 	git reset --hard origin/master # latest Linus tree
> 	git merge linux-xfs/for-next
> 	<merge any dependencies>
> 	loop {
> 		guilt push -a
> 		<fix patch that doesn't apply>
> 	} until all patches applied
> 
> If there's no significant change in for-next, then this is all easy
> and is done in a few minutes. But if there's substantial change to
> for-next, then the problems occur when pushing the patches back
> onto the stack...
> 
> I've always based my dev work on the for-next branch (or equivalent
> dev tree tip) because that way I'm always testing the latest dev
> code from everyone else and I know my code works with it.

<nod>

> > Occasionally I'll port a refactoring from for-next into my
> > dev tree to keep the code bases similar. 
> 
> Yup, that's the "<merge any dependencies>" in the process above.
> i.e. someone has posted a cleanup patchset that's going to be merged
> into for-next before the work I'm doing. That's where all the recent
> problems have been coming from - the pain either occurs at the next
> for-next update, or I take it when it's clear it's going to be
> merged soon...

<nod> I guess the difference is that I don't generally merge for-next
wholesale into my dev tree, so that's probably why I didn't see quite as
much for-next-churn troubles. :/

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com