Re: [PATCH 2/2] refs.c: Write reflogs for notes just like for branch heads

From: Jeff King <peff@peff.net>
Date: Mar 30, 2010, 17:19 UTC
Message-ID: <20100330171932.GE17763@coredump.intra.peff.net>
In-Reply-To: <201003291625.22977.johan@herland.net>

On Mon, Mar 29, 2010 at 04:25:22PM +0200, Johan Herland wrote:

Show 12 quoted lines

> > This is actually inspired by Jeff's novel notes use. I think there
> > are use cases where a notes log makes sense (notes on commits) and
> > those where it does not (metadata/textconv). In both cases having a
> > reflog is useful. So, the next step is really to allow notes trees
> > without history, which also takes care of the pruning issue. I know
> > how to do this, I just have to decide about the configuration
> > options.
> 
> I noticed that Jeff's proof-of-concept wrote notes trees without making 
> notes commits, and although it seemed like a bug at first, it does - as 
> you say - provide a rather nice way to store notes trees without 
> history.

No, it was very much intentional.

However, I think the next iteration will wrap the tree in an actual commit, but just keep each commit parentless. That will provide a nice spot for metadata like the cache validity information.

I like the idea of having a reflog, just because you could use it to salvage an old cache if you were playing around with your helper's options (or debugging your helper :) ). The usual 90-day expiration time is perhaps too long, though.

Show 8 quoted lines

> Note that I haven't explicitly designed the notes feature with this in 
> mind, so it's wise to add testcases for expected behaviour once we 
> start use history-less notes trees.
> 
> Thinking about it, the notes code itself (notes.h/.c) only wants a notes 
> _tree_ object, so will probably work fine with history-less notes 
> trees. But builtin/notes.c with its public commit_notes() function may 
> be another story...

I was planning on using my own cache-specific helper instead of commit_notes() anyway, so that shouldn't be a problem. By using a commit wrapper, I don't think any of the display code should be confused (since they need to handle the case of a root note commit anyway). Once I have some example trees, I can poke at them with the existing notes code and see how they behave (and how we _want_ them to behave, since I'm not sure yet what sort of cache introspection, if any, would be useful).

-Peff