John Keeping <> writes:

> On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
>> Duy Nguyen <> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to