David Kastrup writes:
> Are there some measures one can take/configure in the parent repository
> such that (named or all) additional directories inside of $GITDIR/refs
> would get cloned along with the rest?
$ git config --add remote.orgin.fetch '+refs/notes/*:refs/notes/*'
Andreas.
--
Andre
John Keeping writes:
> 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.
I added note
On Sun, Feb 02, 2014 at 11:37:39AM +0100, David Kastrup wrote:
> So I mused: refs/heads contains branches, refs/tags contains tags. The
> respective information would likely easily enough be stored in refs/bzr
> and refs/bugs and in that manner would not pollute the "ordinary" tag
> and branch sp
On Sun, Feb 02, 2014 at 12:42:52PM +0100, David Kastrup wrote:
> 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.
>
Duy Nguyen writes:
> On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup wrote:
>> Since Git has a working facility for references that is catered to do
>> exactly this kind of mapping and already _does_, it seems like a
>> convenient path to explore.
>
> It will not scale. If you make those refs avai
On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup wrote:
> Since Git has a working facility for references that is catered to do
> exactly this kind of mapping and already _does_, it seems like a
> convenient path to explore.
It will not scale. If you make those refs available for
cloning/fetching, a
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
>>
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, a
Duy Nguyen writes:
> On Sun, Feb 2, 2014 at 5:37 PM, David Kastrup wrote:
>> in the context of an ongoing discussion on the Emacs developer list of
>> converting the Bzr repository of Emacs, one question (with different
>> approaches) is where to put the information regarding preexisting Bazaar
On Sun, Feb 2, 2014 at 5:37 PM, David Kastrup wrote:
> in the context of an ongoing discussion on the Emacs developer list of
> converting the Bzr repository of Emacs, one question (with different
> approaches) is where to put the information regarding preexisting Bazaar
> revision numbers and bug
Hi,
in the context of an ongoing discussion on the Emacs developer list of
converting the Bzr repository of Emacs, one question (with different
approaches) is where to put the information regarding preexisting Bazaar
revision numbers and bug tracker ids: those are not present in the
current Git m
11 matches
Mail list logo
