Stephen Haberman <stephen@xxxxxxxxxxxxxxxx> writes: > (I also have a test comment typo and test_expect_failure change to make > to rebase-i-p from Junio's feedback and would like to know the > preferred way to submit those--e.g. a patch on top of your pu, a patch > on top of the existing series, or a new series all together. Given it > is not next, I'm guessing a new series all together.) You guessed it right. As sh/maint-rebase3 is about a pure fix, while the other -i-p is a more involved enhancement, I am guessing Shawn decided not to queue the latter for 1.6.0.X, and I agree with that. The final shape of the history should look like: * maint will eventually get sh/maint-rebase3 to be in 1.6.0.X, which in turn will eventually be merged to master; * master will eventually get sh/rebase-i-p. When two series have dependencies like this, it is generally the easiest and cleanest to prepare them to match such a final shape of the history. Hence, we would want two series built like this: * sh/maint-rebase3 applicable to the tip of 'maint' (this is already done; what is in sh/maint-rebase3 is exactly that); * apply the above locally to 'maint', merge the result locally to 'master', and prepare sh/rebase-i-p series applicable on top of that merge. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
