Sorry it took too long to reply to this.
Junio C Hamano wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
> > Junio C Hamano wrote:
> >> Junio C Hamano <gits...@pobox.com> writes:
> >> > Felipe Contreras <felipe.contre...@gmail.com> writes:
> >> But it does not have to stay that way. In order to move things
> >> forward in that direction, this new configuration has to be
> >> distinguishable from the traditional "refspec", as it embodies a
> >> different concept.
> > Is it a different concept?
> > % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*'
> > % git fetch origin master
> > What do you call this thing? ------^
> The answer to that question is the "value of the 'remote.*.fetch'
> configuration variable".
You are avoiding the question: it's a refspec.
> There is no "refs/heads/next:refs/remotes/origin/next" here, because
> the 'fetch' configuration is not used as a refspec, but as something
Yet both remote.fetch and remote.push are a 'struct refspec', and the
documentation says they are a "refspec".
> My understanding of the added option parameter to "git fast-export"
> is that it is not about specifying the history being transferred,
> but is about mapping the name of the destination. For example, does
> object between 'master' and 'next' participate in the datastream
> produced with this?
> fast-export \
> --refspec=refs/heads/master:refs/remotes/origin/master \
> --refspec=refs/heads/next:refs/remotes/origin/next \
> If this parameter were a refspec, as we have discussed already in
> previous rounds [*3*], we should be able to give it on the command line,
> like any normal refspec, instead of repeating the same thing
> (i.e. up to what commit should the history be transported) as in:
> fast-export --refspec=refs/heads/master:refs/remotes/origin/master
> but just
> fast-export refs/heads/master:refs/remotes/origin/master
Maybe in an ideal world, which we don't live in.
My guess is that trying to accomplish such a goal would result in an
unbelievable mess of the code that I wouldn't even want to think about where
to start to code this.
Moreover, `git grep refmap` returns me the following:
t/t5516-fetch-push.sh:test_expect_success 'pushing a specific ref applies
remote.$name.push as refmap' '
t/t5516-fetch-push.sh:test_expect_success 'with no remote.$name.push, it is
not used as refmap' '
I'd say with --refspec is the simplest and most sensible way this can be
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html