Re: [PATCH v7 00/20] submodule: convert the rest of 'update' to C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Glen Choo <chooglen@xxxxxxxxxx> writes:
>
>> Hm, I haven't looked at where the conflicts are yet, but I'll get to it
>> as I'm reviewing the rest of the feedback.
>>
>> And on that note, what do you think of Ævar's suggestion to split off
>> the 'easy to review' and 'obvious' patches into their own preparatory
>> series? I wonder if this would make it harder or easier to manage the
>> conflicts.
>
> It depends on how small an interaction the "obvious and easy" part
> has with topics in flight.  In the best case, if there aren't any
> the preparatory series may even graduate before the other topics
> that interfere with the main part of this series becomes ready.
>
> In a worse case, what the preparatory work to lay more solid
> foundation wants to do may contradict what some of these topics in
> flight want to do.  Such semantic conflicts need to be resolved
> before the main part (and these interfering topics) can move
> forward, and with "split off", the core of the contradicting wish
> may become easier to see and what needs to be resolved may become
> clearer.
>
> So, I do not think of a way for such a split to make things harder
> for later.  Of course, the "easy to review" and "obvious" part has
> to be justifiable on its own, i.e. "a larger series wants to build
> on this foundation and for it to work this part must be done in this
> way", when the other topics wants to do the part in question
> differently, becomes a much weaker justification.  But if it is
> truly "obvious", it is unlikely that the benefit of the change
> becomes harder to justify.

Thanks for sharing your thought process. That makes sense, I'll do
that :)




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux