Taylor Blau [off-list ref] writes:
quoted
quoted
That way, the bottom part can be merged sooner to 'next' than the
rest. It always is cumbersome to have some part of the series in
'next' and remainder in 'seen', so at that point, the lower half
would naturally gain a different name before it gets merged to
'next', I would think.
That seems to me like it ends up being _more_ work than just making them
into two branches in the first place.
More work to contributors? How?
As long as each of 20-patch and 8-patch series is marked clearly to
manage the risk of mistakes and confusion down to the same level as
a single long series, I am perfectly OK.
Examples of help contributors could have made, which would have
avoided past confusion (these are not "potential" ones, but I had to
redo day's intergration in the past because of one long topic
building on top of another) are:
- When sending either topic, not limited to the initial round but
in all the subsequent rounds, remind that the top topic is to be
applied on top of the bottom topic.
- When updating the bottom topic (e.g. 20-patch one in this case),
send out the top one (e.g. 8-patch one), too (or instruct me to
discard the top one tentatively).
The worst case that happened in the past was that a quite minor
tweak was made to a bottom topic that was depended on another topic,
so I just queued the new iteration of the bottom topic again,
without realizing that the other one needed to be rebased. We ended
up two copies of the bottom topic commits in 'pu' (these days we
call it 'seen') as the tweak was so minor that the two topics
cleanly merged into 'pu' without causing conflict. The next bad
case was a similar situation with larger rewrite of the bottom
topic, which caused me to look at quite a big conflict and waste my
time until I realized that I was missing an updated top half.
If the inter-dependent topics that caused me trouble were managed as
a single long patch series, either with "this is a full replacement
of the new iteration" or "these are to update only the last 8
patches; apply them after rewinding the topic to commit f0e1d2c3
(gostak: distim doshes, 2021-01-08)", would have had a lot less risk
to introduce human error on this end.
I agree, but I also wasn't aware that you would consider queuing part of
a series. If that's the route you want to take, I'm OK with that.
Discarding broken part of a series and only queuing a good part can
happen with or without multiple topics. Merging one topic to 'next'
but not the other also happens. Merging early part of a topic to
'next' while leaving the rest to 'seen' is possible but I'd prefer
to avoid it. Because of the last one, a single long topic, when a
bottom part stabilizes enough, would likely to gain a separate name
and its tip would be merged to 'next'.
But I
tend to agree with Peff that (in this case since a clear deliniation
already exists) it may save us time to just send two separate series
from the get-go.
As long as the two serieses are marked as such clearly, not just in
the initial round but in all subsequent rounds, it is OK. But in an
unproven initial round, you may regret having to move a patch across
topics, from the bottom one to the top one or vice versa, instead of
just reordering inside a single topic.
quoted
So I guess I remain skeptical that ad-hoc splitting of longer series is
easier than doing so up front.
Nobody suggested ad-hoc splitting. I was saying that splitting
would naturally grow out of reviews toward stabilization.
On Wed, Jan 13, 2021 at 12:06:08PM -0800, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
But I tend to agree with Peff that (in this case since a clear
deliniation already exists) it may save us time to just send two
separate series from the get-go.
As long as the two serieses are marked as such clearly, not just in
the initial round but in all subsequent rounds, it is OK. But in an
unproven initial round, you may regret having to move a patch across
topics, from the bottom one to the top one or vice versa, instead of
just reordering inside a single topic.
Sounds good. Like I said, the last thing I want to do is create undue
burden on your or anybody else when queuing or reviewing these topics.
So, I'll try to err on the side of stating the dependency between topics
too often rather than not often enough. Hopefully the first ~20 patches
are boring enough that they will make their way to master soon enough
and we don't have to worry about it.
Ordinarily, I would have held off on the second series until more the
first one had graduated, but I felt that the pure refactorings didn't
make much sense on their own without the new file-based backend to
motivate them.
Thanks,
Taylor
On Wed, Jan 13, 2021 at 12:06:08PM -0800, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
quoted
quoted
That way, the bottom part can be merged sooner to 'next' than the
rest. It always is cumbersome to have some part of the series in
'next' and remainder in 'seen', so at that point, the lower half
would naturally gain a different name before it gets merged to
'next', I would think.
That seems to me like it ends up being _more_ work than just making them
into two branches in the first place.
More work to contributors? How?
The quoted part is from me, so I'll respond: I didn't mean contributors,
but it seems like more work to you. I.e., you are ending up with the
same multi-branch config _and_ you have to split the branches yourself
later after seeing review.
But reading what you wrote below, the advantage is that if this does not
happen until the first part hits "next", then there is no chance of it
being rebased at that point (and thus getting rewritten out from under
the second topic).
The worst case that happened in the past was that a quite minor
tweak was made to a bottom topic that was depended on another topic,
so I just queued the new iteration of the bottom topic again,
without realizing that the other one needed to be rebased. We ended
up two copies of the bottom topic commits in 'pu' (these days we
call it 'seen') as the tweak was so minor that the two topics
cleanly merged into 'pu' without causing conflict. The next bad
case was a similar situation with larger rewrite of the bottom
topic, which caused me to look at quite a big conflict and waste my
time until I realized that I was missing an updated top half.
I somehow assumed you had more automation there. On my end, since I
rebase my topics aggressively, it is just a matter of pointing the
branch upstream in the right place. But of course that is not your
workflow at all.
I know you do have the "this branches uses" logic in your what's cooking
emails. In theory it could remind you of the situation, but I'm not sure
where in the workflow you'd insert it (by the time you run the WC
script, it is hard to realize the rebasing that _should_ have been done
earlier, unless you collate patch-ids, and even that is not 100%).
I do wonder if setting the dependent branch's @{upstream} would be
helpful here. You do not rebase all of your topics, but the ones with a
local-branch @{u} would be candidates for doing so.
All that said, I am also sensitive that my armchair "you could do it
like this..." suggesting may not be fully informed. So take it as idle
thoughts, not necessarily arguments. :)
quoted
quoted
So I guess I remain skeptical that ad-hoc splitting of longer series is
easier than doing so up front.
Nobody suggested ad-hoc splitting. I was saying that splitting
would naturally grow out of reviews toward stabilization.
This quote is me again. By "ad-hoc" I meant exactly this "after we see
some reviews" (as opposed to drawing a line up front).
-Peff