Junio C Hamano <gitster@xxxxxxxxx> writes: > 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.) [...] > 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 -- 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