Re: What's cooking in git.git (Apr 2010, #02; Sun, 04)

On Tue, Apr 06, 2010 at 09:12:44AM +0800, Michael J Gruber wrote:

quoted

* mg/notes-reflog (2010-03-29) 2 commits
 - refs.c: Write reflogs for notes just like for branch heads
 - t3301-notes: Test the creation of reflog entries

Implementation is trivially correct; I am unsure if "notes" tree wants
reflog in the first place, though.  Please convince me and I'll move it
to 'next' soon, aiming for -rc0 or -rc1 at the latest.

I think that Jeff's impressive textconv caching is only the first of
many uses of notes where the notes ref is not a branch head with
continuously added history, but where the ref is being rewritten over
and over again. Also, people may rewrite their refs/notes/commits when
experimenting with remote notes trees.

In both cases, I deem the reflog "backup" a useful safety measure (just
as for other refs), and the automatic purging of the reflog provides
just the appropriate housekeeping.

I agree. I don't expect people to want to look at their notes reflogs
very often, but we have become accustomed to having the reflog safety
net. It is often not until after the "oh crap" moment that the user
comes to the list and we tell them what the reflog is and how to
recover their lost data.

In the case of textconv caches, reflogs are not quite as important
because there is no lost data, only lost time. And as of now, we write a
large number of commits and trees that end up unreachable very quickly
(but only, of course, when encountering new items to cache).  But I
think that is a flaw in the notes-cache code. It should probably flush
the internal cache to a notes ref only on exit, not for every written
entry.

We had discussed dropping the expiration time for notes reflogs. Caches
could be 0 or very low (say 1 day), as recovery would primarily be about
experimentation with textconvs and recovering a cached state that is
slow to generate (e.g., you invalidate your cache by switching your
textconv, then switch it back; instead of regenerating your cache from
scratch, you find the latest cache commit that matches the textconv you
want. We could even do that automatically instead of clearing the cache,
but it is rare enough that I wouldn't bother).

General notes refs are probably useless after a week or two, since you
probably won't have the "oh no, I was working on this topic weeks ago
and I want to recover my partial work" moment that you do with regular
work. On the other hand, since they don't tend to have unreachable
entries, keeping them doesn't bloat the object database.

So that was a bit rambling perhaps, but the point is that I would rather
err on the side of having the reflog safety net and then later realize
we don't really want it, than vice versa.

-Peff