Martin Koegler <martin.koegler@xxxxxxxxx> writes:
> For next. As this touches core functions, it will likely produce
> conflicts with other changes. Please provide the commit you want
> to rebase the patch on and I'll produce a V3.
No matter what base you pick, by the time the series is merged with
other topics in flight to form an updated 'pu' branch, any series of
this invasiveness will cause conflict.
So from that point of view, picking 'master' or 'next' as the base
would not make much difference.
However, picking 'next' (or 'pu') as the base is definitely worse
than 'master' for a different reason. Anything based on 'next',
even though it may apply cleanly there, will not be able to graduate
to 'master' without dragging all the other topics that are in 'next'
with it. Immediately after a feature release is the worst time, as
we will rewind and rebuild 'next' on top of 'master'.
In practice, the only sensible base for an invasive change is the
mimimum one you create yourself. You would:
(1) Start from a reasonably stable base, like 'master'.
(2) Among topics that are in flight but not in 'master', find the
ones that materially interfere with your changes. Merge them
on top of (1).
(3) Then build your change on top.
In the patch series you create in step 3, you would note which base
you chosen (e.g. "v2.14.1") in step 1, plus the names of the topics
you merged in step 2, after three-dash lines.
The set of topics you find in step 2 might end up including a topic
that is of dubious doneness (e.g. especially the ones that are not
yet in 'next'). In such a case, you or the other topic may have to
yield and wait for the other to stabilize. Git is not a substitute
for inter-developer communication, and you'd talk to the author of
the other topic and coordinate between yourselves when it happens.
Thanks.
