[darcs-users] rebase feedback and amend-record flexibility

Ganesh Sittampalam ganesh at earth.li
Tue Apr 10 06:09:56 UTC 2012


Hi Michael,

Thanks! I'm replying to some points inline, and have reordered a bit to
get things in the order that makes sense for my discussion.

On 02/04/2012 17:09, Michael Hendricks wrote:

>   * rebase command is superfluous UI
>       o as mentioned above, most subcommands belong elsewhere
>       o 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

I think this is perhaps a general design point that we should decide
first. Rebase is currently a separate command mainly for ease of
separate development and once integrated into mainline there's no
technical reason not to split it up etc.

I'm not sure either way about whether it _should_ be integrated into
other commands.

On the one hand rebase is at least in some ways rather un-darcs-ish, in
that it mainly addresses scenarios where commute fails in some sense.
Should we normalise/legitimise its usage by having it available
everywhere? Would we still have a need for rebase if conflict handling
was (much) better?

On the other hand we already have amend-record which is commonly used
and very convenient, and as you highlight rebase is in many ways a
natural extension of that (indeed I originally conceived rebase for
darcs as a "amend-record on steroids").


> 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
>       o have proven very useful
>       o would be good building blocks for branch, rebase and stash plugins
>       o should be top-level commands like record/unrecord, pull/unpull,
>         revert/unrevert
>       o are too low level to satisfactorily solve the deep amend problem
>         for users
>       o need a way to list suspended patches (darcs changes --suspended?)
>   * pull
>       o should be "darcs pull --suspend-conflicts"
>       o even better would be "darcs pull
>         --conflicts={mark,allow,disallow,skip,suspend-ours,suspend-theirs}"
>       o suspending conflicted patches might offer more pleasant conflict
>         resolution, one offender at a time

Currently, the conflicts get dealt with on unsuspend, rather than on
suspend. on unsuspend you can do the conflict resolution one at a time -
does this work badly for you or was the workflow not well signposted?

>   * reify, inject
>       o I don't understand the purpose of these commands
>       o should their function be hidden in the implementation of
>         suspend/unsuspend?

Sorry, they shouldn't be exposed at all. They're low-level commands I
used when hacking a rebase of the Cabal repo for Duncan Coutts last
year. I would like to find a good generally usable way of achieving the
same goals (which were essentially doing some rather subtle
modifications of an existing stream of patches).


> 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)
>       o "darcs push --obliterate" could remove the pushed patches from
>         the local repo on success

Does that actually happen with rebase? I thought you end up with two
copies of the changes, or does it also rewind the source branch?

>   * commuting patches to better convey intent
>       o perhaps makes less sense in darcs
>       o sometimes useful to bring a few patches to the front so they're
>         quicker to access during interactive patch selection
>       o "git rebase --interactive" UI is the best I've seen for bulk
>         commute operations
>       o maybe best done as an interactive rebase plugin

OK, so mostly we'd hope this didn't need rebase, but it might if there
are real dependencies. If we go with the idea of having rebase
integrated into other commands, then a natural design here might be to
have a patch reordering command of some form with an optional rebase
where needed.

>   * rewording commit messages, changing author, changing date, etc
>       o amend-record does this, it's just not smart enough yet
>       o rewording a patch needs no commute operations
>       o dependencies should never prevent a reword operation
>       o rewording a buried darcs patch only modifies other patches if
>         there are "record --ask-deps" dependencies (which appear easy to
>         adjust automatically)

As per previous mails in the thread, darcs semantics currently prevent
editing patch metadata without changing the identity of both implicit
and explicit dependencies.

>   * changing the effect of earlier patches
>       o amend-record does this but isn't smart enough yet
>       o is really "commute two patches to be adjacent then coalesce them"
>       o commuting patches to be adjacent is more likely to succeed than
>         commuting a buried patch to the front
>       o amend-record can't do this yet because it selects patches before
>         it selects changes
>   * combining arbitrary, adjacent patches
>       o Darcs internals call this coalesce, but we have no UI for it
>       o current amend-record is a special case of this, applied to only
>         the top two patches
>       o maybe a new darcs command (combine,coalesce,squash)?
>   * splitting a single patch into multiple, adjacent patches
>       o conceptually similar to combining patches
>       o maybe a new darcs command (split, uncombine, uncoalesce)?

OK, that's a significant use case, which might fit in with amend-record
or might need a new workflow. Note that if you can't commute patches to
the front then there is a stack of dependencies that would need to have
their identity changed when editing the underlying patch.

Cheers,

Ganesh


More information about the darcs-users mailing list