On 03/29/2016 10:12 PM, David Turner wrote: > On Sun, 2016-03-27 at 07:22 +0200, Michael Haggerty wrote: >> On 03/24/2016 07:47 AM, David Turner wrote: >>> [...] >>> I incorporated your changes into the lmdb backend. To make merging >>> later more convenient, I rebased on top of pu -- I think this >>> mainly >>> depends on jk/check-repository-format, but I also included some >>> fixes >>> for a couple of tests that had been changed by other patches. >> >> I think rebasing changes on top of pu is counterproductive. I believe >> that Junio had extra work rebasing your earlier series onto a merge >> of >> the minimum number of topics that it really depended on. There is no >> way >> that he could merge the branch in this form because it would imply >> merging all of pu. >> >> See the zeroth section of SubmittingPatches [1] for the guidelines. > > I'm a bit confused because > [PATCH 18/21] get_default_remote(): remove unneeded flag variable > > doesn't do anything on master -- it depends on some patch in pu. And > we definitely want to pick up jk/check-repository-format (which doesn't > include whatever 18/21 depends on). > > So what do you think our base should be? I think the preference is to base a patch series on the merge of master plus the minimum number of topics in pu (ideally, none) that are "essential" prerequisites of the changes in the patch series. For example, the version of this patch series that Junio has in his tree was based on master + sb/submodule-parallel-update. Even if there are minor conflicts with another in-flight topic, it is easier for Junio to resolve the conflicts when merging the topics together than to rebase the patch series over and over as the other patch series evolves. The goal of this practice is of course to allow patch series to evolve independently of each other as much as possible. Of course if you have insights into nontrivial conflicts between your patch series and others, it would be helpful to discuss these in your cover letter. Michael -- 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