[darcs-users] Why adjacent (not overlapping) hunks depends on each other?

[Eric Kow]

OK, I've created  http://darcs.net/Internals/Commuting which we could
maybe flesh out for details on prim-patch commute rules?  Have also
linked to it from the user model.

On 13 November 2013 17:51, Eric Kow <kowey at darcs.net> wrote:
> How do folks feel about adding this to the user model page?  I
> couldn't do it in a concise way, but maybe somebody else would have
> better luck?  Also, I'm afraid I've not tried to think about removes,
> only adds, so not clear if this will be helpful or accurate:
>
> ======8<============
>
> Adjacent hunks are not allowed to commute, because there is no
> sensible way to preserve their line-number order under commutation.
>
> To elaborate on this, it helps to say that when we have two hunk
> patches on the same file, we can think of one of them as being
> “northern” (nearer the top of the file), and the other as being
> “southern” (nearer the bottom). Consider for example p4 and p5 in the
> diagram above (*).  Here we can say that p4 is the southern patch
> (@line6 +duty), whereas p5 is the northern patch (@line4 +clean). The
> northern patch can always be seen as adding (or removing!) padding to
> the textual context on which southern patch applies. This isn't so
> obvious because in this particular example, the northern patch occurs
> after the southern patch.  But if we commuted them we have to adjust
> p4 to (@7+duty) while leaving p5 intact.  The southern patch shifts
> (it's affected by the padding) and the northern patch always stays the
> same (it provides the padding so what does it care?).
>
> Reasoning on static northern patches and shifty southern patches works
> so long as the patches are non-adjacent.  Suppose that after p5 we had
> a p6b (@5+plastic => all the clean *plastic* seats were duly
> occupied).  If we followed the same reasoning about leaving the
> northerly p5 alone (@4+clean), and shifting the southern p6b back to
> account for the missing padding, we'd get two patches that apply at
> the same line… To be clear, having two successive hunk patches at the
> same line is not intrinsically bad; but allowing two such patches to
> commute creates an ambiguity under cherry picking: Is it “all the
> clean plastic seats were duly occupied” or “all the plastic clean
> seats were duly occupied”?  We wouldn't be able tell because our
> compass would be broken!
>
> (*) http://darcs.net/Using/hunk-dependency.png
>
> On 13 November 2013 06:24, Ganesh Sittampalam <ganesh at earth.li> wrote:
>> Hi,
>>
>> On 12/11/2013 18:06, Vincent Zweije wrote:
>>
>>> On Tue, Nov 12, 2013 at 01:50:25PM +0100, Tommy Pettersson wrote:
>>
>>> ||          If we try to pull them together in yet another clone of
>>> ||  the original repo, the first hunk we pull will go to this line
>>> ||  number. But what about the second hunk? It wants to go to the
>>> ||  same line nuber, and it knows nothing about the hunk that is
>>> ||  already there. Should we put it before or after?
>>>
>>> Suppose hunk A replaces lines [A1:A2), and hunk B replaces lines [A2:A3).
>>>
>>> These hunks are adjacent. However, their relative order in the file is
>>> undetermined only if A1 = A2 = A3. So only hunks that remove no lines
>>> must be ordered by a dependency (and conflict if they don't have one).
>>>
>>> For symmetry reasons I suspect it may be necessary that the same may
>>> hold for hunks that only remove lines, but I haven't thought this
>>> through thoroughly.
>>
>> Yes, if two patches both add and remove lines, then darcs will allow
>> them to commute even if they touch.
>>
>> In fact I think darcs is a bit too strict - I believe that it's enough
>> if *one* of the patches both adds and removes lines - but we can't
>> change the rule now without breaking compatibility, so it'll have to
>> wait for a new patch format.
>>
>> Cheers,
>>
>> Ganesh
>>
>>
>>
>> _______________________________________________
>> darcs-users mailing list
>> darcs-users at darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-users
>>
>
>
>
> --
> Eric Kow <http://erickow.com>



-- 
Eric Kow <http://erickow.com>