On Mon, May 23, 2011 2:44 pm, Konstantin Khomoutov wrote:
> 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
Well, not really. This discussion has been about protecting files in a
working directory, whereas the git thing is about unreferenced commits in
the repository being protected against garbage collection! Fossil has no
such thing as an unreferenced commit and doesn't ever lose anything from
the repository unless it is explicitly shunned (which is never part of a
normal workflow).
Eric
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
