On Sun, 22 May 2011 06:50:56 -0400
Richard Hipp <d...@sqlite.org> wrote:
[...]
> > >>> Does anybody have any other suggestions on how to prevent the
> > >>> lose of uncommitted work?
> > >>
> > >> Maybe not suggestion to prevent losing of uncommitted work, but
> > >> I'm thinking about using 'stash' in such situation.
> >
> > Perhaps Fossil could do this automatically. Whenever an 'update'
> > would change any locally modified file, Fossil could stash the
> > changes away first and inform the user.
> >
>
> That's sort of what "fossil undo" does. Except it only stores the
> most recent change. You are suggesting an "auto-stash" that keeps
> backups at each change, and stores them in a visible place such as
> the stash. An interesting idea...
>
> Would we purge the auto-stash on a commit? Or just let it grow until
> the user manually purged it?
This looks like Git's "reflog" functionality [1].
The basic idea of the reflog is that its entries reference commit
objects which could otherwise be "lost" (for instance due to the current
branch's HEAD having been forcibly repositioned to point to another
commit ("hard reset" in Git speak)).
1. http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
