On Sun, Feb 7, 2010 at 11:57 PM, Johan Herland <johan@xxxxxxxxxxx> wrote: > On Sunday 07 February 2010, Giuseppe Bilotta wrote: >> 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? > > 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. 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 -- 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