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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
