Hi, Sorry it took too long to reply to this. Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > Junio C Hamano wrote: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: > >> > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 > else. 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 \ > master > > 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 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 implemented. -- Felipe Contreras -- 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