On 2/11/25 10:07, Junio C Hamano wrote:
> Illia Bobyr <illia.bobyr@xxxxxxxxx> writes:
>
>> I've split the big change from v3 [1] into multiple, mostly
independent patches
>> to make it easier to review and merge each one separately.
>>
>> [1]
https://lore.kernel.org/git/20250206014324.1839232-1-illia.bobyr@xxxxxxxxx/
>>
>> Patches 1 through 4 are fixing minor bugs and inconsistencies.
>>
>> Patch 5 contains updates gitdiffcore to use same placeholder names
as the rest
>> of the code.
>>
>> Patch 6 contains a minimum change to add long versions of -S and -G.
>>
>> Patch 7 adds bash completion support.
>>
>> Patches 8 through 10 increase usage of the long argument versions in
tests, CLI
>> help and docs respectively.
>>
>> Please, let me know if you prefer it split in a different way, or
reorder the
>> changes.
>
> When you base your patch on a different base than 'master' (or if
> the previous iteration of the topic has already been queued in my
> tree, then the commit used as the base to queue the topic), please
> make sure you state it clearly.
>
> This iteration seems to apply on none of bc204b74 (The seventh
> batch, 2025-02-03), on top of which the previous round dcc02caba2
> (ib/diff-S-G-with-longhand) has been queued, or any of the recent
> tips of 'master', like 388218fa (The ninth batch, 2025-02-10) or
> 9520f7d9 (The eighth batch, 2025-02-06), so I cannot look at it.
Sorry for the confusion. I randomly decided to check if my changes have any
conflicts with `next` and rebased on top of it.
Did not realize it would affect the patches.
I've rebased back on top of `master` and published as v5.
>> I was not sure if I should include a reference to the previous
version of the
>> patch into the next reroll. It seems that
>> `Documentation/MyFirstContribution.adoc` suggests so. But it creates
very long
>> threads. And I've noticed that not everyone is doing it.
>
> Almost everybody does so, actually.
>
> Taking a topic that has 5 iterations, each about ~20 patches, as an
> example:
>
>
https://lore.kernel.org/git/20250207-pks-reftable-drop-git-compat-util-v5-0-ba2adc79110f@xxxxxx/
>
> it is perfectly clear and easy to nagivate from the list of messages
> what discussions we had in previous iterations.
Thank you for the explanation and for sharing an example link. I'll use v3
cover letter as a reference point for v5, as I have already interrupted the
reference chain in v3.
>> Reply to review notes ...
>
> It is more customary to Reply-all directly to review messages,
> instead of sending new round of patches. When the cover letter of a
> new iteration is sent as a response to the cover letter of the
> previous iteration, readers can find the previous discussion
> messages.
Got it. Thank you. I have replied to your review email, so that we can
continue the conversation there.
