[darcs-users] rebase feedback and amend-record flexibility
Michael Hendricks
michael at ndrix.org
Mon Apr 2 16:09:24 UTC 2012
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.
- suspend and unsuspend
- have proven very useful
- would be good building blocks for branch, rebase and stash plugins
- should be top-level commands like record/unrecord, pull/unpull,
revert/unrevert
- are too low level to satisfactorily solve the deep amend problem
for users
- need a way to list suspended patches (darcs changes --suspended?)
- pull
- should be "darcs pull --suspend-conflicts"
- even better would be "darcs pull
--conflicts={mark,allow,disallow,skip,suspend-ours,suspend-theirs}"
- suspending conflicted patches might offer more pleasant conflict
resolution, one offender at a time
- obliterate
- should be "darcs obliterate --suspended"?
- reify, inject
- I don't understand the purpose of these commands
- should their function be hidden in the implementation of
suspend/unsuspend?
- rebase command is superfluous UI
- as mentioned above, most subcommands belong elsewhere
- 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
Users coming from Git or Mercurial are likely to think of rebase in the
following use cases:
- moving patches from one branch to another (the original Git use case)
- "darcs push --obliterate" could remove the pushed patches from the
local repo on success
- commuting patches to better convey intent
- perhaps makes less sense in darcs
- sometimes useful to bring a few patches to the front so they're
quicker to access during interactive patch selection
- "git rebase --interactive" UI is the best I've seen for bulk
commute operations
- maybe best done as an interactive rebase plugin
- rewording commit messages, changing author, changing date, etc
- amend-record does this, it's just not smart enough yet
- rewording a patch needs no commute operations
- dependencies should never prevent a reword operation
- rewording a buried darcs patch only modifies other patches if there
are "record --ask-deps" dependencies (which appear easy to adjust
automatically)
- changing the effect of earlier patches
- amend-record does this but isn't smart enough yet
- is really "commute two patches to be adjacent then coalesce them"
- commuting patches to be adjacent is more likely to succeed than
commuting a buried patch to the front
- amend-record can't do this yet because it selects patches before it
selects changes
- combining arbitrary, adjacent patches
- Darcs internals call this coalesce, but we have no UI for it
- current amend-record is a special case of this, applied to only the
top two patches
- maybe a new darcs command (combine,coalesce,squash)?
- splitting a single patch into multiple, adjacent patches
- conceptually similar to combining patches
- maybe a new darcs command (split, uncombine, uncoalesce)?
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.
Thus ends my lengthy brain dump
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20120402/8e812c51/attachment.html>
More information about the darcs-users
mailing list