Re: Rollback of git commands

From: Ingo Molnar <mingo@elte.hu>
Date: Nov 28, 2007, 16:50 UTC
Message-ID: <20071128165033.GA31218@elte.hu>
In-Reply-To: <ee77f5c20711271757h724d5fcep38f3c2354c54f20b@mail.gmail.com>

* David Symonds <dsymonds@gmail.com> wrote:

Show 13 quoted lines

> On Nov 28, 2007 12:49 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > Rollback is too strong of name for this. Checkpoints would be better.
> > The idea is to record the total system state at convenient moments and
> > then allow moving back to the checkpointed state. The object store
> > supports this, but the rest of the state in .git/* isn't being
> > recorded.
> 
> rsync -a .git /somewhere/safe
> 
> I fear that what you ask becomes a chicken-and-egg scenario: where/how 
> is this checkpointing information going to be stored? If it's tightly 
> integrated with Git, what happens when you want to roll-back a 
> checkpoint-restore?

well, it would/could be the normal undo/redo semantics of editors: you can undo-redo in a linear history fashion, in an unlimited way, but the moment you modify any past point of history then the redo future is overriden. (but the 'past' up to that point is still recorded and available)

and this could all be driven via .git/logs - as long as all other metadata is imported into the object store and the root of this git tree would be represented in a single file. The logs are append-only as well, the loss of them means the loss of undo/redo information, nothing else. Figuring out the linear history from the logs would be computationally expensive, but that's not a big issue as 'undo/redo' would be a rare operation anyway.

But i guess i must be missing some obvious complication?

	Ingo