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

[Johan Herland <johan@herland.net>]

On Tuesday 30 March 2010, Jeff King wrote:
> On Mon, Mar 29, 2010 at 04:25:22PM +0200, Johan Herland wrote:
> > > 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.

Agreed.

> 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.

Yes, 90 days as a default might be excessive, but you can always 
override it with a "git gc --prune=now"...

> > 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).

Looking forward to your patches. :)


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net