On Thu Dec 12, 2024 at 02:52, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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). That's a fair point, that branch names are local. But if the information is being sent over email (in a coverletter), that doesn't matter too much (although should somebody attempt to "apply a cover letter" to a local branch that already has completely different description applied that might cause issues, i.e. I send the email from local development branch, but the receiving end applies it directly on master which had a description already). During push/pull though, the user already has a mapping between local and remote branches, so that could be used to overcome the difference between local and remote branch names. Though I'm probably glossing over other complications.
