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

[Michael Hendricks]

Hi Ganesh.

On Tue, Apr 10, 2012 at 12:09 AM, Ganesh Sittampalam <ganesh at earth.li>wrote:

> 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?
>

That's an excellent question.  Really good conflict handling would
certainly eliminate one substantial use case for rebase.  I'm not sure if
it could help in the other use cases though.


> >   * 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?
>

Sorry, I worded my bullet point poorly.  The current rebase behavior of
resolving conflicts one patch at a time during unsuspend has worked very
well for me and was clear enough from the documentation.

I meant to say that being able to suspend conflicts as part of the standard
pull command (that users are already familiar with) would extend the same
pleasant experience to them too.

> 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?
>

Git rebase rewinds the source branch.  It's been a while since I've used
Mercurial rebase, but I vaguely recall it being the same.


> >   * 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.
>

I understand how the identity of ask-deps dependencies must change (since
they're recorded as references to patchinfo).  I don't see how other
dependencies must change.  Can you provide an example?  Ignoring ask-deps
dependencies, every scenario I've thought of can allow deep metadata
changes without affecting any other patches.


> 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.
>

Sometimes that's true, but it doesn't seem to be true in the general (or
common) case.  Can you provide an example so I can see what I'm missing?

Coalescing two adjacent patches seems to be a safe operation (assuming no
patchinfo changes) because the coalesce has no net effect on the filesystem
on which subsequent patches operate.  As far as subsequent patches are
concerned, the coalesce was a noop.  I'm probably missing something
obvious, so a counterexample would be great.

-- 
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20120410/9ef6cc3a/attachment.html>