Subject: Re: [PATCH 00/21] replacement for dt/refs-backend-lmdb v7 patch 04/33

From: Michael Haggerty <[email-masked]>
Date: Wed, 30 Mar 2016 08:37:48 +0200

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