Re: Rollback of git commands

[Ingo Molnar <mingo@elte.hu>]

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

> 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