On Mon, Mar 21, 2022 at 10:03 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Neeraj K. Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > * Rebase onto 'seen' at 0cac37f38f9. > > That's unfortunate. Having to depend on almost everything in 'seen' > is a guaranteed way to ensure that the topic would never graduate to > 'next'. > > For this topic, ns/core-fsyncmethod is the only thing outside of > 'master' that the previous round needed, so I did an equivalent of > > $ git checkout -b ns/batch-fsync b896f729e2 > $ git merge ns/core-fsyncmethod > > to prepare fd008b1442 and then queued the patches on top, i.e. > > $ git am -s mbox > > > This work is based on 'seen' at . It's dependent on ns/core-fsyncmethod. > > "at ."? > > In any case, I've applied them on 0cac37f38f9 and then re-applied > the result on top of fd008b1442 (i.e. the same base as the previous > round was queued), which, with the magic of "am -3", applied > cleanly. Double checking the result was also simple (i.e. the tip of > such an application on top of fd008b1442 can be merged with > 0cac37f38f9 and the result should be identical to the result of > applying them directly on top of 0cac37f38f9) and seems to have > produced the right result. > > \Thanks. Thanks Junio. I was worried about how to properly represent the dependency between these two in-flight branches without waiting for ns/core-fsyncmethod to get into next. Now ns/core-fsyncmethod appears to be there, so I'm assuming that branch should have a stable OID until the end of the cycle. Should I base future versions of this series on the tip of ns/core-fsyncmethod, or on the merge point between that branch and 'next'? I guess it doesn't really matter if the merge is clean. Thanks, Neeraj
