On 10/07/2015 09:20 PM, David Turner wrote:
> On Wed, 2015-10-07 at 20:31 +0200, Michael Haggerty wrote:
>> [...]
>> I'm really happy about your work.
>>
>> Regarding strategy: I think a good approach would be to get as much of
>> the preparatory work as possible (the abstraction and separation of
>> refs-be-files) to the point where it can be merged before there is too
>> much more code churn in the area. That work is not very controversial, I
>> think, and letting it wait for a long time will increase the likelihood
>> of conflicts with other people's changes. The refs-be-lmdb patches, on
>> the other hand, (1) will take longer to get polished, (2) will take
>> longer to review because other people are not familiar with LDMB, and
>> (3) won't bitrot very fast anyway because they don't overlap as much
>> with areas that other people are likely to work on. So I would advocate
>> working on those at a more deliberate pace and planning for them to be
>> merged as a separate batch.
>
> Works for me.
>
> Would you like me to start sending those as a separate series, or shall
> I keep it as one series and let you split it as you choose?
That's really up to you, as the convenience tradeoff is mostly on your
side. If you keep it as one series it is a tad easier for everybody to
see the whole idea as a continuous story. But it means that whenever you
rewrite any commit in the series, you have to propagate the change
through all of the commits, every time. Whereas if you break them up,
you have the option of letting the later patches idle for a while then
to rebase them onto revision N of the earlier patch series in one big bang.
BTW I didn't have the impression that the series has to be broken into
more than two or three subseries. Splitting off refs-be-files.{c,h} from
refs.{c,h} and creating the virtual function table is pretty much one
unit of work and I see no sense splitting it artificially into separate
parts. Adding refs-be-lmdb.{c,h} is only a couple of (big!) patches
which, again, don't really need to be split any further. If you decide
to implement the delegation thing for handling the split between
per-worktree vs. shared references (even when both use the files
backend), that might be a third patch series between the other two.
The best dividing line to choose is between "uncontroversial" and
"possibly controversial", because the former are more likely to succeed
in a fast track.
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
--
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