[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