From: Jakub Narebski <jnareb@gmail.com>
Date: Sat, 08 Oct 2011 00:01:35 GMT
Subject: Re: [PATCH] fmt-merge-msg: use branch.$name.description
Message-ID: <m3mxdc1hek.fsf@localhost.localdomain>
In-Reply-To: <7vobxstt4w.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> 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