Re: Creating own hierarchies under $GITDIR/refs ?

From: David Kastrup <dak@gnu.org>
Date: Feb 2, 2014, 11:42 UTC
Message-ID: <87wqhdzqo3.fsf@fencepost.gnu.org>
In-Reply-To: <20140202113141.GB29976@serenity.lan>

John Keeping <john@keeping.me.uk> writes:

Show 17 quoted lines

> On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>> 
>> > The file is for past commits only.
>> 
>> > New commits can contain these info in their messages.
>> 
>> If it's not forgotten.  Experience shows that things like issue numbers
>> have a tendency to be omitted, and then they stay missing.
>> 
>> At any rate, this is exactly the kind of stuff that tags are useful for,
>> except that using them for all that would render the "tag space"
>> overcrowded.
>
> Actually, I would say this is exactly the sort of thing notes are for.
>
> git.git uses them to map commits back to mailing list discussions:

But that's the wrong direction. What is needed in the Emacs case is mapping the Bazaar reference numbers (and bug numbers) to commits.

While it is true that the history rewriting approach would not deliver this either (short of git log --grep with suitable patterns), I was looking for something less of a crutch here.

> Notes aren't fetch by default, but it's not hard for those interested
> to add a remote.*.fetch line to their config.

If we are talking about measures everybody has to actively take before getting access to functionality, this does not cross the convenience threshold making it a solution preferred over others. But it's probably feasible to configure a fetch line doing this that will get cloned when first cloning a repository. That's not too hot for people with existing repositories, but since we are talking about a migration from Bazaar anyway, Git users currently are so by choice and so might be more willing to update their configuration if it helps with avoiding a fully new clone.

-- 
David Kastrup