[darcs-users] darcs patch: Accept issue1325: hunk patches interfere with pending ...
kowey at darcs.net
Wed Oct 21 13:57:39 UTC 2009
On Wed, Oct 14, 2009 at 11:29:03 -0300, Marco Túlio Gontijo e Silva wrote:
> From my point of view the changes between records should be minimized.
> If the user want to store some history information, is should record it.
> If it has undone some change before recording, that change should not be
> shown in the patch.
I think everybody agrees with this. The question is whether or not it's
always practical to implement. I sure hope it will be!
> Why is there the need to do
> hunk ./file 1
> rmfile ./file
> Couldn't rmfile store in itself the content of the removed file? I
> think this would solve this problem.
First: we should be clear that any changes of this sort would require
a new backward incompatible format. Which is not to say that we
shouldn't think hard about what our patches are and how they should
(eg merge); after all, that's why we're still working on Darcs 3 and
that's why we're still working out things like solutions to the add-add
conflicts problem, character-diff patches and hunk moves. So the kind
of solution being discussed is strictly a long term affair.
If there is a more immediate way to go about it, great! Just know that
this is not it :-D
Second: maybe it was just a question of keeping things simple. Rather
than have a notion of hunk in three places (addfile, hunk, rmfile), we
just have it one place. Simplicity is good; it means, for example, we
don't have to worry about how to do conflict marking between rmfile
hunks and regular hunks.
Although note that in Marco's solution, at least commutation wouldn't
be any harder to define (presumably), since hunk patches don't commute
past rmfile anyway...
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the darcs-users