On Tue, Apr 06, 2010 at 09:12:44AM +0800, Michael J Gruber wrote: > > * 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html