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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-01-22 at 06:13 +0100, Johannes Schindelin wrote:
> > 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@xxxxxxxxxx>
  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.

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux