Re: Semantics of Move

Branko Čibej wrote:
> On 15.08.2013 17:01, Julian Foad wrote:
>>  Is this acceptable?
>
> Looks OK, from a quick review.
>
>> This means that combining the two separately committed
>> changes "copy" and "move a child" into a single commit will
>> result in semantic data loss, which we are trying to avoid.
>
> Not really. The copied+moved child node will still have copyfrom
> information linking it to the source of the copy. That doesn't trivially
> tell us how the node came to be at the new location, but there are other
> cases where that's not tracked (e.g., sequential local renames followed
> by a commit; only the result will be tracked, not the intermediate
> (wc-local) states).

Ah, yes: the loss of information about intermediate states does not matter, because we're talking about squashing a series of revisions into a single revision, so by definition information about the intermediate states is to be lost.  All that matters is the relationship between the final state and the initial state, and the (user-level) meaning of that relationship can be described perfectly well without saying "move", in the form "the subtree at path P_at_X is copied to path P1_at_Y, except for its child C which is copied to path P2/C_at_Y instead".  That makes me happy.

- Julian
Received on 2013-08-15 21:35:42 CEST