Hi Stephen,
Thanks for your input.
Stephen J. Turnbull wrote:
Nik writes:
> http://nik.homelinux.net/files/darcs-coalescing.html
>
> If anyone has any comments on this, I would be very interested to read them.
At the commit level, I don't really see how you can beat git, since
for a pure "squash", it can edit the history DAG directly, and in
general can accomplish rebase very efficiently.
I was focusing more on the user interface than the underlying storage.
I had inferred that git and darcs would be as effective as the other in
the actual coalesce operation.
True, git can efficiently edit the history DAG, but with Darcs there is
(effectively) no history DAG to edit, so the point is moot, isn't it?
What would be interesting would be if patch theory allowed Darcs to
coalesce better (ie, with fewer conflicts, or spurious changes dragged
along with the desired ones),
I assumed that the coalesce was combining a number of smaller patches
into a single larger one. Darcs has the patch contents and the patch
dependency information which is sufficient to ensure the coalesced patch
is correct. Correct?
and/or the new hunk editing capabilities
allowed coalescing to have an efficient UI at a lower lever than
commits.
So you're talking more of the situation in which some of the patches to
coalesce contain multiple updates, some of which should be coalesced and
some not?
Is this also the cause of the "conflicts or spurious changes" you talk
of in the point above?
So, assuming that the storage model and record semantics are unchanged,
you don't see any real benefit to darcs users in the suggested change?
Cheers!
Nik
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
