Julian Foad wrote on Fri, 25 Aug 2017 21:42 +0100:
> Let's clarify. We can mean two possible things when we say 'a series of
> patches':
>
> 1. "patch versions": a series of successively better patches, all
> attempting the same logical thing, all from the same base, and only one
> of which is applied at any time;
>
> 2. a series of patches, each providing a different logical change,
> where each patch is based on the result of applying the previous one.
> ("quilt" is a tool for managing path series of this kind. My 'option 3'
> (local repository) design for checkpointing could also be used in this
> way, in a primitive way, but would not support revising earlier patches
> in the series which is a key strength of what "quilt" can do.)
>
> I am talking about definition 1 ("patch versions").
>
> I propose patches in a series of patch versions be named "featureA-1",
> "featureA-2", ... (This is what I do already, manually, in my own work.)
>
> I propose that we should not attempt to provide any special support for
> definition 2 within this "shelving" feature; users can manage that
> themselves by simply remembering which feature names depend on which
> other ones, or by including some other numbering system within the names.
Could you explain how you see this working? In use-case #2, later patches
in the series typically depend on earlier patches. I don't see how that
use-case
can be addressed if the patches are all implemented against deltas against
the same base (for example, because if patch #2 in a 5-patch series is edited,
all later patches would have to be regenerated).
If that's not clear enough I'd be happy to elaborate.
Cheers,
Daniel
P.S. I think brane's suggestion would make the "edit patch #2 in a 5-patch
series"
use-case a lot easier: diff3 is exactly the right tool for rebasing patch #3 on
top
of the edited #2.
