On Wed, Apr 10, 2013 at 11:33 PM, Jeff King <p...@peff.net> 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).


[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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to