Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation

Johan Herland [off-list ref] writes:

This patch teaches 'git fast-import' to automatically organize note objects
in a fast-import stream into an appropriate fanout structure.

I really hate to sound like a clueless newbie, but that is what I am in
the area of 'notes', so I have two questions.

 - What is the semantics of having more than one note to the same commit
   in the input stream?  Does the 'notes' part also have history and the
   latest one overwrite the earlier one by creating a new commit that
   points at the new 'notes' tree?  I've always thought of 'notes' as an
   unversioned metainfo, but I realize that versioning them would make
   sense (you can and obviously would want to inspect the story behind the
   current note attached to one particular commit).

 - If however 'notes' want to have a history, how would it interact with
   this rebalancing of the tree?  Rebalancing makes a lot of sense if the
   'notes' mechanism deals with the only one latest version because it can
   keep the optimal look-up performance.  There were some talks about
   specialized merge strategies that can be made aware of rebalancing, but
   is there a plan to deal with "git log -p notes" side, and how?