On 27.08.2017 02:04, Daniel Shahaf wrote:
> 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.
Yes, that's one of the reasons I proposed storing whole files instead of
patches. Rebasing and reordering would become much simpler (although not
exactly "simple" if we take tree restructuring into account).
-- Brane
Received on 2017-08-27 02:09:57 CEST