Hello all,

ok, this may sound a little odd especially with the 'notes vs
metadata' thread going on, but I was wondering: do we store _any_ kind
of metadata _about_ the notes themselves? If I'm reading the code
correctly, we have neither author nor date information about the notes
themselves, so we don't know who added them or when. Is it too late to
suggest that this kind of metadata be added to notes? Making them
full-blown commit-style objects is probalby overengineered and wrong
under many points of view (not to mention probably incompatible with
current storage), but maybe we can set up a convention that notes
SHOULD be in pseudo-mbox format? This would mean that when a note is
created, the template starts with a 'From ' line including the user's
name &  email and note creation date; when editing, the note is again
augmented with the new author name email and date. Of course the users
are then free do expunge the From lines if they don't want it (just
commenting it would be enough, of course). How does the idea sound?

-- 
Giuseppe "Oblomov" Bilotta
--

[ message continues ]

This is already done refs/notes/commits (or any other notes ref) is a
normal commit and so any edits to the notes are thus tracked in the
normal way.

To see this add a note, then use:

    gitk notes/commits.

Regards,

jon.

On Sun, Feb 7, 2010 at 10:50 PM, Giuseppe Bilotta
--

[ message continues ]

NAK

Notes are stored in a notes tree that is changed by making commits on the 
notes ref (see commit_notes() in builtin-notes.c in 'pu'). The commits on 
the notes ref are regular commits with the usual commit metadata (author, 
date, etc.), so if you're interested in who/when a given note was written, 
you can simply point 'git (gui) blame' at the notes tree.


...Johan

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

[ message continues ]

Yup, I was totally overseeing the obvious thing about the notes
commit, and up until this morning I thought that settled the issue.

However, this morning I read Junio's posts about the issue of merging notes
http://permalink.gmane.org/gmane.comp.version-control.git/139252 and
thought that this might be a possible solution.

Junio's root issue is basically that you can only have one note per
commit per namespace, and that normally notes from different
developers grow from different root commits and are thus unmergeable.

I see two possible solutions to this:
 * one is to allow more than one note per commit per namespace, which
moves a little towards the 'note as a tree' idea, but with severe
restrictions (the tree would be flat and each blob in it would be a
note)
* the other is to keep the notes as single files, but give them a
little bit of structure to make merging easier: my mbox-style idea
would of course only be an idea, but in general by keeping the notes
'sectioned', merging could be reduced to concatenation most of the
times. The mbox approach also has the benefit that you'd have more
information about the single section, so that you could for example
keep them sorted etc.

Just brainstorming here, so feel free to tear down this idea too 8-)

-- 
Giuseppe "Oblomov" Bilotta
--

[ message continues ]