Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: >> Good timing. I was planning to kick split-under-lock and any of its >> dependents temporarily out of 'next', so that fixes can choose not >> to be incremental, and dependent topics can be rebased on top of the >> fixed fondation. Even if we do incremental, [4] is not sufficient >> material for me to write a log message for. >> >> So people who reviewed what has been in 'next' can revisit [4] and >> give review comments, while I could just pick up the history >> mentioned there, i.e. >> >> git checkout pu >> git pull git://github.com/mhagger/git +split-under-lock:mh/split-under-lock >> >> and we can start from there? > > Sure. The branches in my GitHub fork already include all of the > improvements and fixes that I know of, and the only outstanding issue is > the one that Lars mentioned in this thread (which I believe to be a > problem in git-p4). > > BTW, there are still no conflicts between these branches > (split-under-lock, update-ref-errors, ref-iterators, and ref-store) and > current master. Therefore, I don't see a need to rebase them onto > master. But if you would prefer that I do so, just let me know. If the updated split-under-lock itself can build on the same upstream commit, then there is no reason to rebase it on top of v2.9 or anything newer. Your other topics queued in my tree build on the version of split-under-lock I have (e.g. mh/ref-store uses ref-iterators and split-under-lock). When split-under-lock gets updated, they need to be rebuilt on top of the updated version, and that is what I meant by "dependent topics can be rebased on top". -- 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