Re: [PATCH v6 06/10] fast-export: add new --refspec option
Hi, 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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 06/10] fast-export: add new --refspec option
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.
The refspec mechanism and syntax used in fetch and push were
invented and designed to express two things [*1*]:
1) what is the set of objects that are necessary and sufficient to
complete some histories need to be transferred; what are the
tips of these histories that are being completed?
2) after the object transfer, some refs on the side that receive
the objects are optionally to be updated;
2-a) which refs are they?
2-b) what objects are they updated to point at?
A refspec consists of one or more elements, each of which has
right and left hand side separated by a colon, i.e. RHS:LHS, and
1) is determined by the RHS
2-a) is determined by the LHS
2-b) is determined by the correspondence between RHS-to-LHS.
A wildcarded refs/heads/*:refs/remotes/origin/* dynamically
expands to what the side that sends objects have, e.g. if fetching
from a repository with 'master' and 'next' branches, it becomes
refs/heads/master:refs/remotes/origin/master
refs/heads/next:refs/remotes/origin/next
So with
$ refspec='refs/heads/master:refs/remotes/origin/master
refs/heads/next:refs/remotes/origin/next'
$ git fetch origin $refspec
we transfer objects to allow us to have complete histories leading
to 'master' and 'next' from the origin repository. And we update
our refs/remotes/origin/{next,master} refs.
Traditionally, when there is _no_ refspec on the command line, the
value of 'remote.*.fetch' configuration variable is used as the
fallback default, and that usage is still true. When used in that
way, the value of the variable _is taken as_ a refspec.
However, we can no longer say that the variable _is_ a refspec with
the modern Git, and here is why.
git fetch origin master used to ignore the 'remote.*.fetch'
configuration variable completely, but since f2690487 (which is a
fairly recent invention), the variable participates in the fetch
process in a different way [*2*]. With this in the config:
[remote origin]
fetch = refs/heads/master:refs/remotes/origin/master
fetch = refs/heads/next:refs/remotes/origin/next
the command with 'master' refspec on the command line transfers the
objects required to complete the history only for the 'master', and
not 'next':
$ git fetch origin master
In this usage, 'master' on the command line is the only thing that
determines what histories are completed (because it does not say
'next', the objects necessary to complete its history are not
transferred unless they are needed to complete 'master'). The value
of the 'remote.*.fetch' configuration does not participate in the
determination of the history being transferred at all. It is not
used as a refspec.
But unlike Git of the last year, we do map this 'master' using the
'remote.*.fetch' configuration variable, in order to decide 2)
above. We find that the given remote ref, 'master', has an element
that corresopnds to it in the 'remote.*.fetch' configuration, and
that element tells us to update refs/remotes/origin/master to point
at the object they call 'master', effectively turning the above
command line into this form (using refspec that has only one
element, refs/heads/master:refs/remotes/origin/master):
$ git fetch origin refs/heads/master:refs/remotes/origin/master
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.
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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Junio C Hamano gits...@pobox.com writes: A refspec consists of one or more elements, each of which has right and left hand side separated by a colon, i.e. RHS:LHS, and 1) is determined by the RHS 2-a) is determined by the LHS 2-b) is determined by the correspondence between RHS-to-LHS. Heh, I got my right and left the other way around ;-) -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
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? --^ -- Felipe Contreras -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Richard Hansen rhan...@bbn.com writes: I thought that the discussion agreed this option should not be called --refspec but something like --refmap? I don't know what you agreed to, http://article.gmane.org/gmane.comp.version-control.git/237473 Yup, that was what I had in mind. but I didn't agree to anything. Based on your silence I too thought that you had agreed. Careful. Silence does not mean agreement, at least around here. It may be just the person was busy and hasn't got around to it, was not paying attention and missed the discussion, or was not as interested in the topic as his/her other activities. That, especially the last possibility among the three example reasons above, was why I said the discussion agreed, not you agreed. What you pass to this option is a refspec, so it makes sense to name the option --refspec. As discussed in that thread, it's not really the same thing as a refspec used in push or fetch. In those commands, the refspec specifies two separable things: what to transfer, and how to translate refs names between the remote and local repositories. IIUC, the fast-export --refspec argument only specifies how to translate ref names, not what gets transferred. If my understanding is correct, then I agree with Junio and Peff that --refmap is a better name. I know from one of the tests that the option Felipe added is implemented in such a way that allows: git fast-export --option refs/heads/master:refs/heads/next master to rename the destination, but I didn't check, when I wrote the message to envision how a similar mechanism could be used to enhance push/fetch in the future, if it can be actually used as a mapping git fast-export --option refs/heads/*:refs/remotes/mine/* master Being able to do so was the only reason why I agree with the patch in question (not my toy patch, but [6/10] that started this thread) that it is a good idea in the longer term, as the other approach I suggested to teach revision command line parser to optionally take refspecs as if they specify LHS of the colon as object name with rev_cmdline annotations would not work well for such a purpose. Thanks. -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Richard Hansen wrote: On 2013-11-11 18:50, Felipe Contreras wrote: On Mon, Nov 11, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: So that we can convert the exported ref names. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I thought that the discussion agreed this option should not be called --refspec but something like --refmap? I don't know what you agreed to, http://article.gmane.org/gmane.comp.version-control.git/237473 but I didn't agree to anything. Based on your silence I too thought that you had agreed. Given that my opinion is regarded as inferior by those in the discussion, I don't see why I should share it, specially since when I do, it's considered toxic if I disagree. What you pass to this option is a refspec, so it makes sense to name the option --refspec. As discussed in that thread, it's not really the same thing as a refspec used in push or fetch. In those commands, the refspec specifies two separable things: what to transfer, and how to translate refs names between the remote and local repositories. IIUC, the fast-export --refspec argument only specifies how to translate ref names, not what gets transferred. Does it? % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master From /home/felipec/dev/git * branchmaster - FETCH_HEAD * [new branch] master - refs/remotes-test/origin/master In this case remote.origin.fetch is determining how to translate ref names, not what gets transferred, *exactly* the same as we are doing with --refspec. And as far as I know, remote.origin.fetch is a refspec. -- Felipe Contreras -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Felipe Contreras felipe.contre...@gmail.com writes: Does it? % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master From /home/felipec/dev/git * branchmaster - FETCH_HEAD * [new branch] master - refs/remotes-test/origin/master In this case remote.origin.fetch is determining how to translate ref names, not what gets transferred, *exactly* the same as we are doing with --refspec. And as far as I know, remote.origin.fetch is a refspec. If you had 'next' and 'pu' branches at the remote, do they get fetched with that command line? -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Does it? % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master From /home/felipec/dev/git * branchmaster - FETCH_HEAD * [new branch] master - refs/remotes-test/origin/master In this case remote.origin.fetch is determining how to translate ref names, not what gets transferred, *exactly* the same as we are doing with --refspec. And as far as I know, remote.origin.fetch is a refspec. If you had 'next' and 'pu' branches at the remote, do they get fetched with that command line? No, why would they? You specified a single branch to fetch. Try it yourself. % git clone git://git.kernel.org/pub/scm/git/git.git % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master -- Felipe Contreras -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: Does it? % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master From /home/felipec/dev/git * branchmaster - FETCH_HEAD * [new branch] master - refs/remotes-test/origin/master In this case remote.origin.fetch is determining how to translate ref names, not what gets transferred, *exactly* the same as we are doing with --refspec. And as far as I know, remote.origin.fetch is a refspec. If you had 'next' and 'pu' branches at the remote, do they get fetched with that command line? More interestingly, if you have [remote mothership] push = +refs/heads/*:refs/remotes/satellite/* in your configuration and then said $ git push mothership master then configured remote.mothership.push is not even used (I bring this up because export is more closely related to push than fetch). This (and why 'next' and 'pu' are not fetched in the fetch example) is because traditionally, refspecs that are explicitly given on the command line overrides configured ones (in other words, configured ones are used as a fallback default). This is a bit of tangent, but since the recent discussion on the triangular workflows, I've been wondering if we may want to have a new way to configure things so that we can say When I push to mothership any one of my local branches, I want it to go to the ref with the same name at the mothership under refs/remotes/satellite/ hierarchy (because I am emulating 'git fetch' that is run on the mothership to get updates from this satellite), somewhat similar to what you added to fast-export via the option in question. But we cannot achieve that mapping by changing the meaning of the configured refspecs remote.mothership.push without having to worry about breaking existing practices of people. When they say git push mothership master, they do mean to push refs/heads/master to refs/heads/master, and it will break the expectation in their existing repositories if we change the semantics under them. A possible way to achieve that mapping When I push to mothership any one of my local branches,... could be to introduce a _new_ configuration (so that existing repositories will not suddenly change their behaviour): [remote mothership] pushmap = +refs/heads/*:refs/remotes/satellite/* And then we can allow this command line $ git push mothership master to be affected by the mapping when expanding the short-hand refspecs given on the command line. Traditionally, anything without colon stood as a short-hand for push to the same name, e.g. 'master' is for 'refs/heads/master:refs/heads/master' in this example, and 'v1.0' would be for 'refs/tags/v1.0:refs/tags/v1.0'. 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. -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
Felipe Contreras felipe.contre...@gmail.com writes: So that we can convert the exported ref names. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I thought that the discussion agreed this option should not be called --refspec but something like --refmap? -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
On Mon, Nov 11, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: So that we can convert the exported ref names. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I thought that the discussion agreed this option should not be called --refspec but something like --refmap? I don't know what you agreed to, but I didn't agree to anything. What you pass to this option is a refspec, so it makes sense to name the option --refspec. -- Felipe Contreras -- 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
Re: [PATCH v6 06/10] fast-export: add new --refspec option
On 2013-11-11 18:50, Felipe Contreras wrote: On Mon, Nov 11, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: So that we can convert the exported ref names. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I thought that the discussion agreed this option should not be called --refspec but something like --refmap? I don't know what you agreed to, http://article.gmane.org/gmane.comp.version-control.git/237473 but I didn't agree to anything. Based on your silence I too thought that you had agreed. What you pass to this option is a refspec, so it makes sense to name the option --refspec. As discussed in that thread, it's not really the same thing as a refspec used in push or fetch. In those commands, the refspec specifies two separable things: what to transfer, and how to translate refs names between the remote and local repositories. IIUC, the fast-export --refspec argument only specifies how to translate ref names, not what gets transferred. If my understanding is correct, then I agree with Junio and Peff that --refmap is a better name. -Richard -- 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
