Ok.. I was thinking in it... Consider a hunk p, its effect is an injective simple relation (an injective partial function). We know (because p is injective) that p;p^ is a co-reflexive relation, id est, it does nothing but it can only be applied to trees in the domain of p
If you use commuteHunk an stupid-hunk does not commute with every patch (I was wrong), and it is very simple to find a counterexample, just consider Hunk f l [foo] [] :< Hunk f l [] []. commuteHunk will reject to commute these patches, and that's good because if you have a tree in which f has exactly l lines, and you remove the line l then Hunk f l [] [] can't be applied any more. What commuteFP does is just trivially commute any id-hunk (stupid-hunk does not seem a good name, since they make sense), and this is definetly wrong (at least in theory, since effect-preserving is no longer true). So you was right Eric, Darcs could end up trying to apply a Hunk f 20 [] [] when f has 10 lines. The interesting question if it matters in practice. Could the following be possible / a problem? I have a file f with 10 lines, and I apply p=Hunk f 10 [foo] [bar] Then I rollback p: p;p^ Then I apply q = Hunk f 10 [foo] [] Then I reorder my patches: q;p;p^. I can't know when this could be possible since I don't know Darcs code deeply enough. Then I rollback p^: q;p;p^;p So I have an inconsistent history (a non-sensible sequence of patches). On Tue, Nov 23, 2010 at 12:37 PM, Iago Abal <iago.a...@gmail.com> wrote: > Could stupid-hunks be the result of rollback and colescing of patches? > > Suppose we have some hunk p, if we rollback it pp^ and then we ask for > colescing(pp^), could this produce an stupid-hunk? > > On Mon, Nov 22, 2010 at 11:48 AM, Iago Abal <iago.a...@gmail.com> wrote: > >> On Mon, Nov 22, 2010 at 11:00 AM, Eric Kow <ko...@darcs.net> wrote: >> >>> On Wed, Nov 17, 2010 at 16:32:54 +0000, Iago Abal wrote: >>> > Question 1: Darcs diff could generate non-sensible hunks? That will be >>> a >>> > bug, I think. >>> >>> It might not come from the differ. I wonder what else might generate >>> hunks. Could this somehow result from operations like patch coalescing, >>> or maybe generating the primitives used during conflict marking? There >>> may be other sources still. >>> >>> If so, it seems like a quick&dirty fix (instead of fix what produces >> stupid-hunks just check for them in commute). Would be interesting to know >> what was the comment of the author when s/he record that patch. >> >>> > Let me call Hunk f l [] [] "stupid-hunk": A stupid-hunk h is almost >>> > equivalent to the Identity patch (but it requires h.file to exist, and >>> line >>> > h.line to be in "in bounds"). I think could be easily proved that a >>> > stupid-hunk will always commute with another Hunk. >>> >>> Well I can see that the stupid hunks always commute past. I guess I'm >>> vaguely concerned that there's some sort of patch theory property that >>> gets violated by these odd indices, or that one day we'll be trying to >>> apply a stupid hunk to line 42 of a now 10 line file. Sure we could >>> catch the stupid hunk case and systematically no-op (need to check if >>> we do), but it does look weird. >>> >> Are you worried because this stupid-hunks are created (e.g. by colesce) >> with invalid line numbers? Or are you worried because the use of commute >> could lead to invalid (out of range) line numbers? >> >>> >>> -- >>> Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> >>> For a faster response, try +44 (0)1273 64 2905 or >>> xmpp:ko...@jabber.fr <xmpp%3ako...@jabber.fr> (Jabber or Google Talk >>> only) >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.10 (GNU/Linux) >>> >>> iEYEARECAAYFAkzqTTgACgkQBUrOwgisBPmqyQCfS8pIScKLjKWdtspSyCwQelh/ >>> GugAoLdbdfzpcqF69eClzasBRNE6vhBl >>> =EPDz >>> -----END PGP SIGNATURE----- >>> >>> >> >> >> -- >> Iago Abal Rivas >> > > > > -- > Iago Abal Rivas > -- Iago Abal Rivas
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
