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

On Wed, Mar 30, 2016 at 1:05 PM, David Turner [off-list ref] wrote:

On Wed, 2016-03-30 at 08:37 +0200, Michael Haggerty wrote:

quoted

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

quoted

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.

If I am reading this correctly, it looks like your series also has a
few more sb submodule patches, e.g. sb/submodule-init, which is
responsible for the code that 18/21 depends on.

I think jk/check-repository-format is also  good to get in first,
because it changes the startup sequence a bit and it's a bit tricky to
figure out what needs to change in dt/refs-backend-lmdb as a result of
it.

But I can't just merge jk/check-repository-format on top of 71defe0047
-- some function signatures have changed in the run-command stuff and
it seems kind of annoying to fix up.

So I propose instead that we just drop 18/21 for now, and use just
jk/check-repository-format as the base.

By 18/21 you mean
[PATCH 18/21] get_default_remote(): remove unneeded flag variable
in builtin/submodule--helper.c?
You could drop that and I'll pick it up in one of the submodule series',
if that is more convenient for you.

Does this seem reasonable to you?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html