I've been playing with the rebase branch for the last couple weeks.  Here's a lengthy brain dump.  If you're interested in more explanation for any particular point, let me know.<div><ul><li>suspend and unsuspend</li>
<ul><li>have proven very useful</li><li>would be good building blocks for branch, rebase and stash plugins</li><li>should be top-level commands like record/unrecord, pull/unpull, revert/unrevert</li><li>are too low level to satisfactorily solve the deep amend problem for users</li>
<li>need a way to list suspended patches (darcs changes --suspended?)</li></ul><li>pull</li><ul><li>should be "darcs pull --suspend-conflicts"</li><li>even better would be "darcs pull --conflicts={mark,allow,disallow,skip,suspend-ours,suspend-theirs}"</li>
<li>suspending conflicted patches might offer more pleasant conflict resolution, one offender at a time</li></ul><li>obliterate</li><ul><li>should be "darcs obliterate --suspended"?</li></ul><li>reify, inject</li>
<ul><li>I don't understand the purpose of these commands</li><li>should their function be hidden in the implementation of suspend/unsuspend?</li></ul><li>rebase command is superfluous UI</li><ul><li>as mentioned above, most subcommands belong elsewhere</li>
<li>Darcs already has UI for accomplishing the same goals as Git/Mercurial rebase, no new UI needed except perhaps interactive rebase for performing bulk history-edit operations</li></ul></ul><div>Users coming from Git or Mercurial are likely to think of rebase in the following use cases:</div>
</div><div><ul><li>moving patches from one branch to another (the original Git use case)</li><ul><li>"darcs push --obliterate" could remove the pushed patches from the local repo on success</li></ul><li>commuting patches to better convey intent</li>
<ul><li>perhaps makes less sense in darcs</li><li>sometimes useful to bring a few patches to the front so they're quicker to access during interactive patch selection</li><li>"git rebase --interactive" UI is the best I've seen for bulk commute operations</li>
<li>maybe best done as an interactive rebase plugin</li></ul><li>rewording commit messages, changing author, changing date, etc</li><ul><li>amend-record does this, it's just not smart enough yet</li><li>rewording a patch needs no commute operations</li>
<li>dependencies should never prevent a reword operation</li><li>rewording a buried darcs patch only modifies other patches if there are "record --ask-deps" dependencies (which appear easy to adjust automatically)</li>
</ul><li>changing the effect of earlier patches</li><ul><li>amend-record does this but isn't smart enough yet</li><li>is really "commute two patches to be adjacent then coalesce them"</li><li>commuting patches to be adjacent is more likely to succeed than commuting a buried patch to the front</li>
<li>amend-record can't do this yet because it selects patches before it selects changes</li></ul><li>combining arbitrary, adjacent patches</li><ul><li>Darcs internals call this coalesce, but we have no UI for it</li><li>
current amend-record is a special case of this, applied to only the top two patches</li><li>maybe a new darcs command (combine,coalesce,squash)?</li></ul><li>splitting a single patch into multiple, adjacent patches</li><ul>
<li>conceptually similar to combining patches</li><li>maybe a new darcs command (split, uncombine, uncoalesce)?</li></ul></ul></div><div><div>In most of the above use cases, suspend/unsuspend is only needed as a last attempt when normal commute/coalesce operations fail.  With some adjustments, such failures should be relatively rare.</div>
<div><br></div><div>Thus ends my lengthy brain dump<br clear="all"><div><br></div><div>-- </div>Michael<br>
</div></div>