Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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". -- 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