From: John Keeping <john@keeping.me.uk>
To: David Kastrup <dak@gnu.org>
Cc: Duy Nguyen <pclouds@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Creating own hierarchies under $GITDIR/refs ?
Date: Sun, 2 Feb 2014 12:24:32 +0000 [thread overview]
Message-ID: <20140202122432.GC29976@serenity.lan> (raw)
In-Reply-To: <87wqhdzqo3.fsf@fencepost.gnu.org>
On Sun, Feb 02, 2014 at 12:42:52PM +0100, David Kastrup wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > 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.
Ah, OK. I hadn't quite read carefully enough.
I actually wonder if you could do this with notes and git-grep; for
example:
git grep -l keeping.me.uk refs/notes/amlog |
sed -e 's/.*://' -e 's!/!!g'
That should be relatively efficient since you're only looking at the
current notes tree.
> 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.
I'm assuming you'll need some form of tool (at least a script) to
manipulate this feature; it wouldn't be too hard for that to set this up
the first time it's run.
next prev parent reply other threads:[~2014-02-02 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 10:37 Creating own hierarchies under $GITDIR/refs ? David Kastrup
2014-02-02 11:00 ` Duy Nguyen
2014-02-02 11:19 ` David Kastrup
2014-02-02 11:31 ` John Keeping
2014-02-02 11:42 ` David Kastrup
2014-02-02 12:24 ` John Keeping [this message]
2014-02-02 23:44 ` Jed Brown
2014-02-02 12:00 ` Duy Nguyen
2014-02-02 12:09 ` David Kastrup
2014-02-02 11:04 ` Andreas Schwab
2014-02-02 23:26 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140202122432.GC29976@serenity.lan \
--to=john@keeping.me.uk \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).