Re: branch description as a note?

["Bence Ferdinandy" <bence@ferdinandy.com>]

On Thu Dec 12, 2024 at 02:52, Junio C Hamano <gitster@pobox.com> wrote:
> Justin Tobler <jltobler@gmail.com> 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.