On Wed, Apr 10, 2013 at 11:33 PM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Apr 10, 2013 at 07:07:12PM -0500, Felipe Contreras wrote: > >> When pushing, the remote namespace is updated correctly >> (e.g. refs/origin/master), but not the remote helper's >> (e.g. refs/testgit/origin/master). >> >> Let's update it correctly. > > I would have thought it was the helper's responsibility to update these. > Obviously remote-testgit can handle this fine, but will any other > helpers be using these refs as a marker to know the last point they > imported, and get confused if we update the refs behind their back? > > For example, during the import, a helper might know that it has imported > up to X on a foreign vcs, and that resulted in commit Y in git, which it > stored in refs/$helper/heads/master during the last import. When we > fetch from it again, it picks up from X to the tip of the foreign vcs, > and then imports that history on top of commit Y. > > But if we push some commits to the helper, moving Y up to Z, then it > would build the new commit (which contains the foreign-vcs's equivalent of > Y..Z) on top of Z, not Y. Why would it do that? If X points to say revision 100, presumably it was stored somewhere while doing a fetch. Similarly, if foreign version of Z is 150, it can update that number while doing a push. The next fetch it would start from 151. All this is hypothetical of course, because... > I do not offhand know of any helpers that are implemented this way, > though. vcs-svn does not seem to use the refspec feature at all, and I > assume that your hg/bzr helpers do not have this problem. So perhaps it > is not worth worrying about. They cannot be implemented this way, because as I have already argued and shown[1], remote helpers must be using marks, they don't work otherwise (transport helper is broken for those cases). Cheers. [1] http://article.gmane.org/gmane.comp.version-control.git/210306 -- 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