Re: [PATCH] fmt-merge-msg: use branch.$name.description

Michael J Gruber [off-list ref] writes:

Alternatively, one could store the description in a blob and refer to
that directly, of course. I.e., have

refs/description/foo

point to a blob whose content is the description of the ref

ref/foo

That would be unversioned, and one could decide more easily which
descriptions to share. (A notes tree you either push or don't.)

If refs/descriptions/foo were to point at a commit object and its commit
log message is used to store the description you could make it versioned.

A history that records forest of descriptions where its commit contains a
tree whose leaves are branch names is slightly better than notes based
approach in that it does not have to violate "notes are for objects"
design principle, but it shares the same "branch names are local" issue as
your "lone refs/description/foo describes 'foo' and 'foo' only".

In addition, it shares with the notes based approach that exchanging a
description on a single branch will inevitably pull in descriptions of all
the other branches you happen to have in the forest, which was one of the
reasons that recording "push -s" certificates in notes tree failed whether
the v2 or v3 approach was used.

You should be able to make a few changes to jc/request-pull-show-head-4 to
move the description to such a "refs/desc/$name" from completely local
"branch.$name.description". The machinery to edit the description is
localized to edit_branch_description() introduced in b7200e8 (branch:
teach --edit-description option, 2011-09-20), and the machinery to read
the description is localized to read_branch_desc() in 6f9a332 (branch: add
read_branch_desc() helper function, 2011-09-21); the remainder of the
series could be used unmodified.

But it remains that any of these approaches assume branch names are
universal. Unlike other systems, what we call branches do not have their
own identity, so if you really want to go that route (and we _might_ need
to in the longer term, but I am not convinced at this point yet), you
would first need to define how that local namespace would look like, how
people interact with it, etc. It might be just the matter of declaring a
convention e.g. "Among people who meet at this central repository,
everybody must map the branches identically to their local branch
namespace, and all sharing must go through the central repository", and
calling a tuple <central repository URL, branch name in that repository>
with a name that cannot be confused with "branch" (so "remote branch" is
out), such as "(development) track".

Junio C Hamano [off-list ref] writes:

Michael J Gruber [off-list ref] writes:

quoted

Alternatively, one could store the description in a blob and refer to
that directly, of course. I.e., have

refs/description/foo

point to a blob whose content is the description of the ref

ref/foo

That would be unversioned, and one could decide more easily which
descriptions to share. (A notes tree you either push or don't.)

[...]

But it remains that any of these approaches assume branch names are
universal. Unlike other systems, what we call branches do not have their
own identity, so if you really want to go that route (and we _might_ need
to in the longer term, but I am not convinced at this point yet), you
would first need to define how that local namespace would look like, how
people interact with it, etc. It might be just the matter of declaring a
convention e.g. "Among people who meet at this central repository,
everybody must map the branches identically to their local branch
namespace, and all sharing must go through the central repository", and
calling a tuple <central repository URL, branch name in that repository>
with a name that cannot be confused with "branch" (so "remote branch" is
out), such as "(development) track".

Well, git could by default imply that 'refs/heads/*:refs/remotes/foo/*'
implies 'refs/description/*:refs/remote-descriptions/foo/*'...

...one more argument for hierarchical remote-tracking refs namespace,
i.e. 'refs/remotes/foo/refs/heads/*', and not current 'refs/remotes/foo/*'

Just my 3 eurocents^W groszy.
-- 
Jakub Narębski