Re: [PATCH v10 1/5] fetch: add remote.<name>.refmap

[Junio C Hamano <gitster@pobox.com>]

Harald Nordgren <haraldnordgren@gmail.com> writes:

>> > That does look like it would fall back on the refmap, but to be honest
>> > I'm not sure what is "correct" here :) I was hoping for more
>> > discussion of the questions I raised to see some thought about what we
>> > should or shouldn't do. I suppose falling back might be important for
>> > the later step with --limited-fetch, though?
>>
>> I just encountered a case where I wished to configure both refmap
>> and fetch at the same time.  From a second remote (let's call it
>> "cabal"), store any branch fetched from them in refs/remotes/cabal/
>> but I want to fetch only their 'master', 'next' and 'seen'.  I'd
>> want to be able to write something like:
>>
>>         [remote "cabal"]
>>                 fetch = master next seen
>>                 refmap = +refs/heads/*:refs/remotes/cabal/*
>>
>> And, no, this does not require any inferring based on what is
>> checked out and what the checked out branch tracks.
>
> Yes, I think we can handle this as well with some extra code.

I actually do not think we should have master next seen on the same
remote.cabal.fetch configuration variable.  It is a multi-valued
variable, so it should read more like

         [remote "cabal"]
                 fetch = refs/heads/master
                 fetch = refs/heads/next
                 fetch = refs/heads/seen
                 refmap = +refs/heads/*:refs/remotes/cabal/*

And without these remote.cabal.fetch configured, but with
remote.cabal.refmap configured, this command line

	$ git fetch cabal next

should work just like

	$ git fetch cabal \
		--refmap="+refs/heads/*:refs/remotes/cabal/*" \
		next

I think.

Thanks.