Justin Tobler <jltobler@xxxxxxxxx> writes: > One problem I see with notes is they all live in a single notes tree and > are associated with individual commits. Therefore, I'm not quite sure > how a specific note could be correlated with a branch without having a > separate notes tree for each branch. Maybe the notes mechanism could be > extended to also support storing notes associated directly with a > reference in its tree? That might allow for notes to follow a reference > as it gets updated. The "in a single notes tree" part is easily surmountable by having more than one (see "git notes --ref=..." option) and that indeed is how I maintain the mapping from each commit to the message-ID the commit comes from. But you are absolutely correct to point out that notes are attached to individual commits, and it becomes unwieldy once you start to have more than one commit on the branch. You can attempt to work it around by enforcing a convention, like "the commit at the tip of the branch has its descriptions", but then "git commit" that advances the branch by one commit needs to move the notes, "git reset" to rewind and "git branch" to repoint would need to transplant, but then there needs ways to differenciate a forking (you are creating a new branch from the tip of an existing branch, you do not want to copy the old branch's description) and repointing. It easily lead to UI nightmare. Abusing notes tree by storing branch name in a blob and taking the blob object name as the key in a notes tree will absolutely not work. The names of branches are ephemeral and local (what I call the ps/build branch may be called junio/ps/build by Patrick, and both names are valid in the scope around these names), so using such a local name as a key would make it even harder to share such notes tree (not that "git notes merge" is a great end user experience to begin with).
