Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > I believe the code in this patch is fairly well-prepared to deal with > it. It would merely need to learn to store a list of trees in the > notes_rewrite_cfg, provided that it's ok to load them all > simultaneously. I was mentally handwaving to myself that all will be well in the end ;-) but thought that it would never hurt to ask if you have thought things through. > However, I haven't really thought about having several notes trees. > Is this automatic copying the only operation that needs this feature, > or were you thinking of others too? I was envisioning that most of the time people would want to read from (and probably concatenate, or output with the origin information tagged in) multiple notes but want to create into a single one. But updating for rewritten commits fundamentally need to happen in all of these multiple notes trees they would want to read from. For example, if I have amlog notes to record the message-id of the original message I ran "am" to queue people's patches, I would want to carry that even after I make typofixes in the commit log message or in the code using "commit --amend". If you have buildlog notes to record the output from continuously running build-test-bot, you probably do not want these notes to get carried forward when you rebase a branch. In "log --show-notes=amlog --show-notes=buildlog" output, we will see notes from both amlog and buildlog in the original history, but only the notes from amlog will be shown in the rebased history. -- 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