revert/shelf/undo/redo

[Martin Pool]

On 19/10/05, Michael Ellerman <michael at ellerman.id.au> wrote:
> On Wed, 19 Oct 2005 13:12, Martin Pool wrote:
> Basically I'd like a "shelf" to become a place where you can put multiple
> uncommited hunks, and/or commits. The default would be to shelve everything,
> the current behaviour would be selected with --hunks or --select.
>
> Unshelve would then bring things off the shelf in reverse order (ie. LIFO),
> commits would be recommited, and uncommited hunks would just be left in the
> working tree.
>
> Things that might be nice:
>  - being able to "combine" two patches on the shelf, including combining
>    non-adjacent patches. This could be tricky, but would be cool.
>  - unshelving out of order. (similar problem)
>  - when shelving commits, a choice of uncommiting them (ie. modifying history)
>    or saving their inverse as a new commit.
>  - being able to switch between multiple shelves.

That'd be nice.  If they're based on patches (or better, changesets)
stored to files then a sufficiently advanced user can do some of these
things themselves with only basic tool support.

> That's probably all getting a bit ambitious, but we'll see.
>
> A shelf with (some of) these properties would basically be an implementation
> of quilt in bzr. Having used quilt for a while, I think for some workflows
> the "tree + patches" model is valuable.

I think it'd be very nice too.

> I'm not sure about undo. I think it could be cool, as long as *all operations*
> that affect the repository are undoable. So that includes: adds and removes,
> commits, pulls, merges, ignores (?) ... it could get tricky. What you don't
> want is for the user to think "bzr undo will undo X" and for it to actually
> do Y, especially when X is a subset of Y.

That's true, and I did actually write that in the original design docs
as a bug in tla giving this meaning (revert-and-save) to "undo".  A
well-done universal undo can be a real boon to somebody exploring a
program but it's probably just going to make things worse if it
doesn't always undo the last action.

You could get part way there by at least knowing what the last action
was and saying "sorry, can't undo commit yet".

Leaving aside undo, would it be reasonable to always do revert as a
non-interactive shelve?  I think so.

--
Martin