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

[Eric Kow]

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>