Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)

From: Sam Vilain <sam@vilain.net>
Date: Jan 31, 2009, 06:45 UTC
Message-ID: <1233384354.10045.170.camel@maia.lan>
In-Reply-To: <alpine.DEB.1.00.0901220606040.3586@pacific.mpi-cbg.de>

On Thu, 2009-01-22 at 06:13 +0100, Johannes Schindelin wrote:

Show 8 quoted lines

> > It would be nice to hear a real world success story using the notes
> > mechanism before casting this design in stone.
> 
> I'd like to have some profiling done before that.  For example, I am still 
> a bit unsure how the things would perform with a 50-deep delta chain for 
> a notes tree having 50,000+ notes in it (which I think will not be all 
> that unreasonable for a medium-sized project that stores bug-tracking 
> information in the notes).

Is there any reason why the split has to be cast in stone at all?

ie, the code could just scan the root tree of the branch, and progressively descend into sub-trees based on a partial match of the object for which the note is to be found. If you find a partial name then you expect that it is a tree and descend into it and scan for the rest. If you find a complete name then you expect that it is a blob and open it. If it turns out to be a tree then there are multiple notes for that commit. Then I think you get the best of both worlds; you can start with a simple flat structure and then later someone can come along and make it split it when there are more than N entries in the root tree (where N is determined from profiling etc).

There are two practical applications I could use this for straight away for perl.git, and I think that they would be important use cases.

One would be to allow grafts to be noted. These might want to live in a different place to refs/notes/commits, like refs/notes/grafts, to avoid performance issues and to recognise they are a different type of data. A second would be for commit header information - particularly the author field and commit description - to be amended. I think this all belongs under refs/notes/commits. These are in essence, historical corrections that don't need to alter the tree.

The idea of making it allow a union merge seems relatively workable, I think for simplicity and flexibility that the contents of the note should be considered to be format-patch output (except without the diff of course). So union-ish, more like a RFC822-aware merge of mail messages.

eg, say the contents of the note are:

  Some text

=> appends "Some text" to the note as currently implemented

  Subject: Blah blah

  Blah blah blah

=> _replaces_ commit message and body, as if it had been committed
   with the above message

  From: Sam Vilain <sam@vilain.net>
  Date: Thu, 22 Jan 2009 06:13:01 +1300

  Blah blah blah

=> replaces 'author' line in commit.  "Blah blah blah" appended to
   commit body.

Sound sane?

Sam.