On Sat, Feb 25, 2012 at 7:21 AM, Stephen J. Turnbull <[email protected]> wrote: > Archi writes: > > > What scenario were you wanting rebase for that patch commutation does not > > solve? There are specific corner cases, but I don't see how corner cases > > make for a good marketing feature. > > Rebase is mostly about presentation, rather than solving problems.
I agree. I think of rebase as an efficient user interface for handling bulk commute, obliterate and amend-record operations. One can't solve new problems with rebase, just solve them with less typing. For example, if I'm working on a series of patches and I want my patches to appear towards the front of `darcs changes` output, it'd be easier to type `darcs rebase` (non-interactive mode) than `darcs send -a -o temp && darcs obliterate ... && darcs apply temp` Similarly, if I want to obliterate one patch, combine two other patches and commute some others, it's easy to use $EDITOR to rearrange this file pick 1 update frobnitz pick 2 reorient giz pick 3 unschlump borfin pick 4 do something dumb pick 5 oops, proper giz fix into this pick 1 update frobnitz squash 5 oops, proper giz fix pick 3 unschlump borfin pick 2 reorient giz Typing the relevant darcs send, obliterate, apply and unrecord commands is usually more than I want to do. I've made a little demo video of me using interactive rebase in Git, for any who haven't used it themselves: http://youtu.be/ZLdcqIvnYPs (sorry if the video text is too small). -- Michael _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
