Re: Rollback of git commands

From: Jon Smirl <jonsmirl@gmail.com>
Date: Nov 28, 2007, 01:33 UTC
Message-ID: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
In-Reply-To: <7vmyszb39s.fsf@gitster.siamese.dyndns.org>

On 11/27/07, Junio C Hamano <gitster@pobox.com> wrote:

Show 29 quoted lines

> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Could a rollback log be implemented in git? It would make things way
> > easier when you screw something up. You'd only roll back things that
> > impacted the object store, not things like checkout.
>
> The object store is append only, and if you disregard SHA-1 collisions,
> I do not think there is much you can gain from being able to roll back
> only object store.
>
> For example, you would want to be able to roll back where your 'master'
> branch was pointing at before you started that botched operation.  That
> is not in the object store at all (we have reflogs for that).
>
> Another example, you might have done quite an elaborate interactive add
> to stage only some changes to a path, but then accidentally said "git
> add" that path to stage the whole thing.  You may say "oops, that state
> was only in the index and now it is lost."  The blob that records the
> staged content _DOES_ exist in the object store in such a case so it is
> not lost --- there is nothing to roll back.  What you lost is a pointer
> into the object store (we do not have anything like reflog for
> individual index entry --- not that I would suggest adding one).
>
> Creating a blob that records all of .git/config, output from
> for-each-ref, output from "symbolic-ref HEAD" and output from ls-files
> -s every time you run _any_ git operation, and restore the state when
> you want to, would conceptually work, as you suggest, but I am not sure
> how practical it would be, performancewise, spacewise, and
> semanticswise.

I'm only looking for a command that would rollback the effect of changes to the object store (you don't have to remove the objects). Losing complex staging would be ok since it can be recreated.

Let's take my recent problem as an example. I typed 'git rebase linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg repair'. The repair failed and left me in a mess. Both of these are easy to rollback except for the fact that stg has stored a bunch of state in .git/*.

After doing the commands I located my last commit before the rebase and edited master back to it. But my system was still messed up since moving master got me out of sync with the state stg stored in .git/*. The 'stg repair' command had changed the stored state.

Instead lets store the contents of .git/* (minus the data itself) as objects. Then commit a new object after each command. Now rollback can be accomplished by walking back this chain off commits. Rollback would wipe out any staging, and effectively reset the working tree to match the point rolled back to. I don't think we need to capture the entire state of 'ls-file -s' to achieve this.

-- 
Jon Smirl
jonsmirl@gmail.com