Re: Creating own hierarchies under $GITDIR/refs ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 02, 2014 at 12:42:52PM +0100, David Kastrup wrote:
> John Keeping <john@xxxxxxxxxxxxx> writes:
> 
> > On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
> >> Duy Nguyen <pclouds@xxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]