git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 7, 2011, 20:59 UTC
Message-ID
<7vobxstt4w.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4E8EED39.1060607@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 11 quoted lines
> 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".

Previous: Jonathan NiederNext: Jakub Narebski
Message 11 of 12 in “fmt-merge-msg: use branch.$name.description”
  1. fmt-merge-msg: use branch.$name.descriptionJunio C Hamano, Oct 7, 2011
  2. Michael J GruberOct 7, 2011
  3. Jonathan NiederOct 7, 2011
  4. Michael J GruberOct 7, 2011
  5. Jonathan NiederOct 7, 2011
  6. Michael J GruberOct 7, 2011
  7. Jonathan NiederOct 7, 2011
  8. Junio C HamanoOct 7, 2011
  9. Michael J GruberOct 7, 2011
  10. Jonathan NiederOct 7, 2011
  11. Junio C HamanoOct 7, 2011
  12. Jakub NarebskiOct 8, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.