On 27.08.2017 02:09, Branko Čibej wrote:
> 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).
Another reason to store whole files: patches don't work with non-text
files. Which is a major problem especially on Windows where files often
are encoded in utf16.
Stefan
Received on 2017-09-02 10:12:31 CEST