Re: Rollback of git commands

From: Sergei Organov <osv@javad.com>
Date: Nov 28, 2007, 18:39 UTC
Message-ID: <87lk8imcxv.fsf@osv.gnss.ru>
In-Reply-To: <20071128165033.GA31218@elte.hu>

Ingo Molnar <mingo@elte.hu> writes:

Show 21 quoted lines

> * 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)

Or it could be Emacs-like: 'undo' is just another operation that is a subject for further undo's ;) Then there is no need for 'redo', and no need to override either the future or the past. Besides this obvious technical superiority will help to maintain git's reputation of being hard to grok ;)

-- 
Sergei.