Re: [RFC/PATCHv10 08/11] Notes API: get_note(): Return the note annotating the given object

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

 



On Monday 07 December 2009, Junio C Hamano wrote:
> Johan Herland <johan@xxxxxxxxxxx> writes:
> > Created by a simple cleanup and rename of lookup_notes().
> >
> > Signed-off-by: Johan Herland <johan@xxxxxxxxxxx>
> > ---
> >  notes.c |   15 ++++++++-------
> >  notes.h |    3 +++
> >  2 files changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/notes.c b/notes.c
> > index 79bfa24..110404a 100644
> > --- a/notes.c
> > +++ b/notes.c
> > @@ -379,12 +379,13 @@ void add_note(const unsigned char *object_sha1,
> > const unsigned char *note_sha1) note_tree_insert(&root_node, 0, l,
> > PTR_TYPE_NOTE);
> >  }
> >
> > -static unsigned char *lookup_notes(const unsigned char *object_sha1)
> > +const unsigned char *get_note(const unsigned char *object_sha1)
> 
> Is there a need to find "note for this commit in the set of notes 3 days
> ago"?  IOW, reading note for the given commit not from the tip of the
> history of the refs/notes/commits but from say refs/notes/commits~4?
> Similarly, is there a need to ask for a history of notes for a given
> commit, something like "git log refs/notes/commit/$this_commit" in a
>  world without any fanout?
>
> Obviously, "there is no need because..." is the best answer I'd be happy
> with.  "There may be in the future but we haven't identified a good use
> case and we don't implement what we do not need now." is also perfectly
> acceptable.

There may be in the future but we haven't identified a good use case and we 
don't implement what we do not need now.

;)

> IOW, I am not suggesting to change it---I just want to know how much
> thought went in before deciding to implement the interface this way.

Well, this later part of the series (from patch #6) was built mainly to 
support the fast-import patch (which is no longer based on this API), but 
also with an eye towards keeping things fairly flexible and generic. 
Furthermore I expect to use most of these patches when I get around to 
builtin-ifying the git-notes shell script (which currently is oblivious the 
notes API and things like fanout and rebalancing).

In any case, if you look at patch #10/11, you'll see I introduce the concept 
of multiple notes trees. This was originally done to allow fast-import to 
edit notes in several branches simultaneously, but it now occurs to me that 
this is exactly what we need to answer your questions above: If you want to 
look at an older version of your notes tree, you simply instantiate another 
notes tree with:

	struct notes_tree my_notes;
	init_notes(my_notes, "refs/notes/commits~4", ...);

and you can now compare notes between my_notes and the current (or any 
other) notes tree.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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]