Johan Herland <johan@xxxxxxxxxxx> 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? -- 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