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@X is copied to path P1@Y, except for its child C which is copied to path P2/C@Y instead". That makes me happy. - Julian
