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

On 03/29/2016 10:12 PM, David Turner wrote:

On Sun, 2016-03-27 at 07:22 +0200, Michael Haggerty wrote:

quoted

On 03/24/2016 07:47 AM, David Turner wrote:

quoted

[...]
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