[darcs-users] Coalescing patches
darcs at babel.homelinux.net
Thu Sep 24 01:55:04 UTC 2009
Thanks for your really informative reply.
Stephen J. Turnbull wrote:
> Nik writes:
> > 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?
> No, it's not. Search the archives for discussions of "when to tag".
> Darcs does have to keep track of dependencies among patches, those do
> form a DAG, although it may be more sparse than git's history DAG.
> The point about tagging is that once you hit a tag, you can stop
> searching for dependencies. And editing the DAG in Darcs is not very
Agreed, darcs does have a DAG, although as I understand it, it's not a
history DAG in the way Mercurial or Git have them. Darcs stores
dependencies, but does not force everything to be sequential. Correct?
More to the point, I was not envisaging the coalesce option as being a
history editing operation. rather it is a way of handling and
formalising the association between multiple patches.
My view was that a coalesced patch is more like a patch container: a
single patch that represents all the changes of the multiple patches it
A coalesced patch represents *new* history information, not *changing*
existing history information.
> > 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?
> Well, yes and no. What if you want to get rid of certain
> dependencies? It seems to me that the main point of coalescing in the
> naive view is to get rid of the trivial dependencies *among the
> coalesced patches*. But I think an obvious and important
> generalization is to get rid of spurious dependencies on other
Ok, your point is well taken.
I had deliberately tried to keep the coalesce option simple to avoid
this type of problem.
The main problem I was trying to solve is that of a consumer of my
shared repo not wanting to know which 15 patches to pull to get
everything required for a particular feature.
By pushing a coalesced patch to the shared repo, there is now a single,
(hopefully) well identified, patch in the shared repo that can be pulled
(and later unpulled) in a single reliable operation.
This should make cherry-picking much more useful for users of that
My assumption was that if we provide good enough tools to manage really
fine-grained patches, and good enough tools to categorise those
fine-grained patches when they are created (or later, interactively),
then the spurious dependencies should be greatly reduced, or (hopefully)
> > 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?
> It's hard to say. I've experimented with a workflow where I never
> commit; XEmacs has a call to "git commit" on after-save-hook.
> Later I would go back and edit the DAG to split the autosave branch
> into topics, and coalesce related patches.\
Your information here is really useful!
> What I found was
> (1) I tended to save *much* more often, because "save->fix typo->save"
> was a really easy idiom to keep extraneous changes separate from
> the main effort.
> (2) Since each patch was small, I was generally willing to write a
> short log for most saves. (This surprised me.) It was useful to
> refer to these in creating coalesced logs.
Interesting - and useful.
I had hoped this was possible, and your comments help confirm this.
Using the darcs concept of the "spontaneous branch", I wanted to rely on
the log of each save to define the coalescing automatically.
> (3) In software development (mostly maintenance-type work, fixing
> bugs, code cleanups, etc), I found myself spending about equal
> amounts of time (a) cherry-picking trivial patches to push
> immediately, (b) rebasing the "real work", and (c) merging, fixing
> conflicts and other cleanup (pruning dead branches, etc).
If the log messages you created at save time correctly grouped those
patches to the correct "spontaneous branch", then how much time would
this save you?
With these spontaneous branches you would:
* be able to issue a single command to push and coalesce all patches in
a particular spontaneous branch.
* be able to push the trivial patches without any "cherry-picking"
effort (because they would all be on a single spontaneous branch)
* would not have any merging or rebasing tasks caused by coalescing,
because coalescing does not edit the DAG (darcs=dependency DAG;
If you are unfamiliar with the "spontaneous branch", see here:
> (4) Based on time logs, I was about as productive with this workflow
> as otherwise, but (a) felt more productive, and (b) probably could
> have achieved a significant gain with better tools.
I'm hoping that the combination of spontaneous branches and automatic
coalescing would achieve some or all of that significant gain.
> (5) In writing lectures, etc this workflow was actually a drag because
> I didn't have very good tools. (DAG editing was done with shell
> functions and CLI commands.) The work was very linear and the
> burden of compacting the patches was greater than perceived
> benefits. With better tools it probably would have been a no-op.
I'm having trouble visualising the issues here.
Would the spontaneous branch and coalesce options help here?
(It seems to me they should.)
>  git was the only one that was fast enough at that time. All the
> others were slow enough that I found myself saving much less often. I
> don't know about now.
Yes, I had wondered on this as well.
This had led me to a separate train of thought on a "darcs.git" product
in which the darcs patch theory is used to create and organise the
patches, but they are stored in teh underlying Git storage. Hopefully
the best of both worlds...
Thanks again for your really useful information.
More information about the darcs-users