Re: Rollback of git commands

* David Symonds [off-list ref] wrote:

On Nov 28, 2007 12:49 PM, Jon Smirl [off-list ref] wrote:

quoted

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