From: Junio C Hamano <gitster@pobox.com>
To: Max Horn <max@quendi.de>
Cc: git@vger.kernel.org, Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH] remote-hg: store converted URL
Date: Tue, 15 Jan 2013 08:51:48 -0800 [thread overview]
Message-ID: <7vr4lm4cez.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vzk0a4ekj.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 15 Jan 2013 08:05:16 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Max Horn <max@quendi.de> writes:
> ...
>> See also the discussion (yeah, this time a real one ;-) leading to this:
>> https://github.com/felipec/git/issues/2
>> ...
If I understand correctly, the $backend::$opaqueToken is a contract
between the remote-helper and the remote-$backend that says "When
user wants to interact with the same (foreign) repository, we agreed
to let her use 'origin' nickname. The remote-helper looks up this
opaque token that corresponds to 'origin' and gives it to the
remote-$backend, and whatever is in the opaque token should be
sufficient for the remote-$backend to figure out how to proceed from
there".
But in this hg::../over/there case, it seems that string is not
sufficient for remote-hg to do so and the contract is broken.
When "git clone $backend::$opaqueToken repo" is run in /dir/ecto/ry,
and then subsequent "git fetch origin" will be run in (a
subdirectory of) /dir/ecto/ry/repo, but anything relative to
/dir/ecto/ry will not work once you go inside /dir/ecto/ry/repo.
The "create a new repository here" argument could even be an
absolute path to a totally different place, so if the
remote-$backend wants to use $opaqueToken as anything relative to
the $(cwd) when "git clone" was invoked, that original location
needs to be available somehow.
Would a new helper protocol message be necessary, so that the
backend can rewrite the $opaqueToken at "clone" time and tell the
helper what to store as URL instead of the original? I do not think
that is much different from remote-$backend updating the value of the
remote.origin.URL using "git config".
An alternative approach may be for somebody (either the "git clone"
or the remote-$backend) to store a "base directory" when "git clone"
was invoked in remote.origin.dirAtCloneTime variable, so that the
next time remote-$backend runs, it can read that directory and
interpret the $opaqueToken as a relative path to that directory if
it wants to. That way, nobody needs to rewrite $opaqueToken.
How do other remote helpers solve this, I have to wonder, though.
By not allowing relative paths to a directory?
next prev parent reply other threads:[~2013-01-15 16:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 19:43 [PATCH] remote-hg: store converted URL Max Horn
2013-01-14 18:14 ` Junio C Hamano
2013-01-15 11:41 ` Max Horn
2013-01-15 16:05 ` Junio C Hamano
2013-01-15 16:51 ` Junio C Hamano [this message]
2013-01-15 18:10 ` Max Horn
2013-01-15 20:10 ` Junio C Hamano
2013-01-15 17:46 ` Max Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr4lm4cez.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=max@quendi.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.