* [PATCH 1/8] Make the "traditionally-supported" URLs a special case
@ 2009-09-04 2:13 Daniel Barkalow
2009-09-04 5:29 ` Sverre Rabbelier
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Daniel Barkalow @ 2009-09-04 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Instead of trying to make http://, https://, and ftp:// URLs
indicative of some sort of pattern of transport helper usage, make
them a special case which runs the "curl" helper, and leave the
mechanism by which arbitrary helpers will be chosen entirely to future
work.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Makefile | 17 ++---------------
transport-helper.c | 7 ++-----
transport.c | 2 +-
transport.h | 2 +-
4 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/Makefile b/Makefile
index 263e191..3ac12ec 100644
--- a/Makefile
+++ b/Makefile
@@ -972,8 +972,7 @@ else
else
CURL_LIBCURL = -lcurl
endif
- CURL_SYNONYMS = git-remote-https$X git-remote-ftp$X
- PROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X
+ PROGRAMS += git-remote-curl$X git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
@@ -1483,16 +1482,10 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-remote-http$X: remote-curl.o http.o http-walker.o $(GITLIBS)
+git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-$(CURL_SYNONYMS): git-remote-http$X
- $(QUIET_LNCP)$(RM) $@ && \
- ln $< $@ 2>/dev/null || \
- ln -s $< $@ 2>/dev/null || \
- cp $< $@
-
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)) git.o: $(LIB_H) $(wildcard */*.h)
builtin-revert.o wt-status.o: wt-status.h
@@ -1674,12 +1667,6 @@ endif
ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
done; } && \
- { for p in $(CURL_SYNONYMS); do \
- $(RM) "$$execdir/$$p" && \
- ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
- ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
- cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
- done; } && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
diff --git a/transport-helper.c b/transport-helper.c
index 43fdc0a..4684877 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -152,13 +152,10 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
return ret;
}
-int transport_helper_init(struct transport *transport)
+int transport_helper_init(struct transport *transport, const char *name)
{
struct helper_data *data = xcalloc(sizeof(*data), 1);
- char *eom = strchr(transport->url, ':');
- if (!eom)
- return -1;
- data->name = xstrndup(transport->url, eom - transport->url);
+ data->name = name;
transport->data = data;
transport->get_refs_list = get_refs_list;
diff --git a/transport.c b/transport.c
index f2bd998..4cb8077 100644
--- a/transport.c
+++ b/transport.c
@@ -823,7 +823,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
} else if (!prefixcmp(url, "http://")
|| !prefixcmp(url, "https://")
|| !prefixcmp(url, "ftp://")) {
- transport_helper_init(ret);
+ transport_helper_init(ret, "curl");
#ifdef NO_CURL
error("git was compiled without libcurl support.");
#else
diff --git a/transport.h b/transport.h
index bfd542f..c14da6f 100644
--- a/transport.h
+++ b/transport.h
@@ -80,6 +80,6 @@ int transport_disconnect(struct transport *transport);
char *transport_anonymize_url(const char *url);
/* Transport methods defined outside transport.c */
-int transport_helper_init(struct transport *transport);
+int transport_helper_init(struct transport *transport, const char *name);
#endif
--
1.6.4.2.419.gc86f8
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 2:13 [PATCH 1/8] Make the "traditionally-supported" URLs a special case Daniel Barkalow
@ 2009-09-04 5:29 ` Sverre Rabbelier
[not found] ` <20090904172345.6117@nanako3.lavabit.com>
2009-09-04 15:40 ` Daniel Barkalow
2009-09-04 9:04 ` Mike Ralphson
2009-09-04 10:34 ` Johannes Schindelin
2 siblings, 2 replies; 18+ messages in thread
From: Sverre Rabbelier @ 2009-09-04 5:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
Heya,
On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@iabervon.org> wrote:
> Instead of trying to make http://, https://, and ftp:// URLs
> indicative of some sort of pattern of transport helper usage, make
> them a special case which runs the "curl" helper, and leave the
> mechanism by which arbitrary helpers will be chosen entirely to future
> work.
I'm sorry, I missed a few emails I think :(. Would you mind explaining
why we chose to special-case the curl helpers instead of the symlink
scheme?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 2:13 [PATCH 1/8] Make the "traditionally-supported" URLs a special case Daniel Barkalow
2009-09-04 5:29 ` Sverre Rabbelier
@ 2009-09-04 9:04 ` Mike Ralphson
2009-09-04 10:34 ` Johannes Schindelin
2 siblings, 0 replies; 18+ messages in thread
From: Mike Ralphson @ 2009-09-04 9:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
2009/9/4 Daniel Barkalow <barkalow@iabervon.org>:
> Instead of trying to make http://, https://, and ftp:// URLs
> indicative of some sort of pattern of transport helper usage, make
> them a special case which runs the "curl" helper, and leave the
> mechanism by which arbitrary helpers will be chosen entirely to future
> work.
> - PROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X
> + PROGRAMS += git-remote-curl$X git-http-fetch$X
I think .gitignore would need to be updated again with the added and
removed executables?
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 2:13 [PATCH 1/8] Make the "traditionally-supported" URLs a special case Daniel Barkalow
2009-09-04 5:29 ` Sverre Rabbelier
2009-09-04 9:04 ` Mike Ralphson
@ 2009-09-04 10:34 ` Johannes Schindelin
2009-09-04 10:50 ` Junio C Hamano
2 siblings, 1 reply; 18+ messages in thread
From: Johannes Schindelin @ 2009-09-04 10:34 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
Hi,
On Thu, 3 Sep 2009, Daniel Barkalow wrote:
> Instead of trying to make http://, https://, and ftp:// URLs indicative
> of some sort of pattern of transport helper usage, make them a special
> case which runs the "curl" helper, and leave the mechanism by which
> arbitrary helpers will be chosen entirely to future work.
I have to admit that this does not convince me at all.
The special case is "http://" and "https://" which might indicate foreign
VCS repositories.
In all other cases, I am afraid that you are complicating the glove.
Remember: the whole purpose of the "foreign VCS" helpers is user
convenience.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
[not found] ` <20090904172345.6117@nanako3.lavabit.com>
@ 2009-09-04 10:47 ` Sverre Rabbelier
0 siblings, 0 replies; 18+ messages in thread
From: Sverre Rabbelier @ 2009-09-04 10:47 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Nanako Shiraishi, Junio C Hamano, git
Heya,
On Fri, Sep 4, 2009 at 10:23, Nanako Shiraishi<nanako3@lavabit.com> wrote:
> http://thread.gmane.org/gmane.comp.version-control.git/127121/focus=127520
I don't see anything in that thread that convinces me why this is the
better solution. Unless I'm reading it wrong Junio said "so this is
how you're going to do it", and Daniel said "yup".
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 10:34 ` Johannes Schindelin
@ 2009-09-04 10:50 ` Junio C Hamano
2009-09-04 12:33 ` Johannes Schindelin
0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2009-09-04 10:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The special case is "http://" and "https://" which might indicate foreign
> VCS repositories.
>
> In all other cases, I am afraid that you are complicating the glove.
>
> Remember: the whole purpose of the "foreign VCS" helpers is user
> convenience.
Sorry, but you completely lost me here.
Here are two URLs that follows your "user convenience" principle.
http://example.xz/repos/frotz.git/
http://example.xz/repo/frotz/trunk/
How do you tell, without relying on .git and trunk, the former is a git
repository and wants the dumb walker transport to fetch from, while the
latter is probably a svn and you would either use "svn checkout", or use
"git clone" on it via the svn helper?
Well, you don't.
One possible "convenient user interface" would be to say
svn+http://example.xz/repo/frotz/trunk/
(or use :: instead of + as the helper-name separator, as we agreed not to
decide on it)
This would give us
(1) it is clear that it literally is what you would give to git and
trigger the svn helper; and
(2) to people who know how canonical git URLs with foreign helper are
spelled, it also is clear that you can use "svn checkout" on
everything after "svn+" in it.
A corollary to this is that you can also use "git svn init" on it.
Compared to that, if you do not have any such prefix, how would that be
more convenient to the users?
Or perhaps you have an alternative in mind that is more convenient for the
users and that is not "use identically looking http://... for both", but
you are being unnecessarily cryptic by not spelling out what it is.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 10:50 ` Junio C Hamano
@ 2009-09-04 12:33 ` Johannes Schindelin
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2009-09-04 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
Hi,
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The special case is "http://" and "https://" which might indicate foreign
> > VCS repositories.
> >
> > In all other cases, I am afraid that you are complicating the glove.
> >
> > Remember: the whole purpose of the "foreign VCS" helpers is user
> > convenience.
>
> Sorry, but you completely lost me here.
My point was that the ambiguity _only_ applies to http:// and https://
URLs, as you illustrated yourself:
> Here are two URLs that follows your "user convenience" principle.
>
> http://example.xz/repos/frotz.git/
> http://example.xz/repo/frotz/trunk/
There is no ambiguity about hg://, svn://, etc. None.
Some "URLs" do not look like "URLs" at all, e.g. :ext:user@host:/module
for CVS repositories. I haven't really thought about a convenient way to
specify these, but I could imagine that indeed something like
"cvs::ext:usr@host:/module" would make sense, and still be an intuitive
interface that does not break down with "git clone".
Likewise, I imagine that "svn::http://example.xz/repo/frotz/trunk" (or
even "svn::std::http://example.xz/repo/frotz") are not _too_ unintuitive.
But my real point still stands: "git clone hg://example.xz/repos/blub"
should Just Work.
Oh, and I definitely do not want to expose an _implementation detail_ such
as "we use cURL" in the name of the remote helper. That would just be bad
style in my book.
> How do you tell, without relying on .git and trunk, the former is a git
> repository and wants the dumb walker transport to fetch from, while the
> latter is probably a svn and you would either use "svn checkout", or use
> "git clone" on it via the svn helper?
>
> Well, you don't.
>
> One possible "convenient user interface" would be to say
>
> svn+http://example.xz/repo/frotz/trunk/
>
> (or use :: instead of + as the helper-name separator, as we agreed not to
> decide on it)
Now that you mention it, the main issue was the ambiguity that
svn:/path/to/repo
should actually be an ssh "URL". But I think that the simple fact that a
"://" in the URL (and if that is not sufficient, something like a
"<vcs>::" prefix) make non-ssh URLs distinct enough to decide robustly
what type the URL is.
> This would give us
>
> (1) it is clear that it literally is what you would give to git and
> trigger the svn helper; and
>
> (2) to people who know how canonical git URLs with foreign helper are
> spelled, it also is clear that you can use "svn checkout" on
> everything after "svn+" in it.
The only problem is that you cannot use "git-remote-svn+http" as helper,
as "+" are not valid filename characters on Windows. However, you could
have a "git-remote-svn" handling both "svn://" and "svn+" prefixes.
> Compared to that, if you do not have any such prefix, how would that be
> more convenient to the users?
Indeed, I made myself misunderstood. I think that for _a lot_ of
repository URLs, there are naturally distinctive-enough prefixes. IMHO we
should make use of that, for a substantially improved user experience (as
opposed to, say, the user experience for unfortunate CVS users who would
like to establish a git-svn-like workflow).
Summary: I think that for most URLs, "<protocol>://" is enough to tell
which helper to call ("http://" means Git, tough).
For those URLs, where this is not sufficient, a "<vcs>+" should be good
enough, or if you really want, "<vcs>::". As the helper gets the complete
URL, it can figure out how to proceed from here, without any need for
core Git to know how.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 5:29 ` Sverre Rabbelier
[not found] ` <20090904172345.6117@nanako3.lavabit.com>
@ 2009-09-04 15:40 ` Daniel Barkalow
2009-09-04 17:14 ` Sverre Rabbelier
2009-09-04 17:23 ` Junio C Hamano
1 sibling, 2 replies; 18+ messages in thread
From: Daniel Barkalow @ 2009-09-04 15:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Instead of trying to make http://, https://, and ftp:// URLs
> > indicative of some sort of pattern of transport helper usage, make
> > them a special case which runs the "curl" helper, and leave the
> > mechanism by which arbitrary helpers will be chosen entirely to future
> > work.
>
> I'm sorry, I missed a few emails I think :(. Would you mind explaining
> why we chose to special-case the curl helpers instead of the symlink
> scheme?
It turns out that the method used to form URLs that use a helper doesn't
generalize well to other cases, because it interferes with the ssh-style
locations. Instead, some different mechanism needs to be made up to handle
arbitrary handlers that git doesn't know about. Since we want to keep
supporting "http://something", that'll have to be a special case anyway,
and so we might as well handle it by having git know what helpers to use
for things that we've always supported, and use a single descriptive name
for the helper that handles that collection of URLs.
As of this version, the idea is that there will be three ways helpers get
selected:
- git selects a helper based on the URL being something traditionally
supported internally; that is, git recognizes the URL and knows what to
run, if possible, to handle it
- git uses the "vcs" option if it is set
- something with the URL that we don't understand well enough yet to
design, but which doesn't seem to be possible to fit in as a single
rule with the first item.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 15:40 ` Daniel Barkalow
@ 2009-09-04 17:14 ` Sverre Rabbelier
2009-09-04 17:23 ` Junio C Hamano
1 sibling, 0 replies; 18+ messages in thread
From: Sverre Rabbelier @ 2009-09-04 17:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
Heya,
On Fri, Sep 4, 2009 at 17:40, Daniel Barkalow<barkalow@iabervon.org> wrote:
> As of this version, the idea is that there will be three ways helpers get
> selected:
How does this interact with wanting to support
"hg://example.org/example" by adding 'git-remote-hg' to you path? Does
it make that harder, or is it just not part of this series? I really
do think we should support that, and only resort to "svn::" or such if
the url is ambiguous (e.g., with a 'https://' prefix, etc).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 15:40 ` Daniel Barkalow
2009-09-04 17:14 ` Sverre Rabbelier
@ 2009-09-04 17:23 ` Junio C Hamano
2009-09-04 17:52 ` Sverre Rabbelier
2009-09-04 18:02 ` Johannes Schindelin
1 sibling, 2 replies; 18+ messages in thread
From: Junio C Hamano @ 2009-09-04 17:23 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Schindelin, Sverre Rabbelier, Junio C Hamano, git
Daniel Barkalow <barkalow@iabervon.org> writes:
> It turns out that the method used to form URLs that use a helper doesn't
> generalize well to other cases, because it interferes with the ssh-style
> locations. Instead, some different mechanism needs to be made up to handle
> arbitrary handlers that git doesn't know about. Since we want to keep
> supporting "http://something", that'll have to be a special case anyway,
> and so we might as well handle it by having git know what helpers to use
> for things that we've always supported, and use a single descriptive name
> for the helper that handles that collection of URLs.
>
> As of this version, the idea is that there will be three ways helpers get
> selected:
>
> - git selects a helper based on the URL being something traditionally
> supported internally; that is, git recognizes the URL and knows what to
> run, if possible, to handle it
>
> - git uses the "vcs" option if it is set
>
> - something with the URL that we don't understand well enough yet to
> design, but which doesn't seem to be possible to fit in as a single
> rule with the first item.
Thanks for a clear description.
I do not see that there is much difference between the above description
and what Dscho is advocating, and I do not see anything to get excited
about as Dscho seems to do. In his world, hg:// or any URL that begins
with <unknown>:// wants to be a short-hand to name the helper, and the
third rule whose detail is unspecified in the above list could be
something like:
- With an explicit <prefix-separator>, i.e.
<helper-name> <prefix-separator> <any-string>
tells the named helper git-remote-<helper-name> to interact with
repository that it can find using <any-string>. We do not interpret,
nor guess from, what <any-string> is, in this case.
- When all else fails, and the URL looks like <unknown>://<any-string>,
we see if git-remote-<unknown> is available and give it the whole
string (including the <unknown>::// part).
which means that what Dscho wants is already a subset of the future
direction planned for this series.
As to the "curl" indirection, if you consider the possiblity of someday
adding the transparently backward compatible cgi based server with updated
clients Gitney talked about, I am reasonably sure that we would want to
have a new helper, say http-cgi, and have interested people invoke it
using the "more explicit" escape hatch:
$ git clone http-cgi::http://repo.or.cz/w/alt-git.git/
while others can continue using the walker via a plain http://repo.or.cz/
URL. When http-cgi helper proves to be successful and everybody's server
upgrades, we might choose to swap the default, say in git 1.10.0 release,
while leaving the door open for people to choose the old helper via an
explicit curl::http://repo.or.cz/ URL.
In short, from where I sit, I do not see much disagreement in the
semantics and in the future direction between what Dscho is saying (unless
I again misunderstood what he said) and what this round wants to bring.
The only slight difference is that having an explicit excape hatch as the
foundation, that usually does not have to be spelled out but does allow
you to, keeps the concept cleaner, while keeping the usability of the end
result.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 17:23 ` Junio C Hamano
@ 2009-09-04 17:52 ` Sverre Rabbelier
2009-09-04 18:02 ` Johannes Schindelin
1 sibling, 0 replies; 18+ messages in thread
From: Sverre Rabbelier @ 2009-09-04 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Johannes Schindelin, git
Heya,
On Fri, Sep 4, 2009 at 19:23, Junio C Hamano<gitster@pobox.com> wrote:
> In short, from where I sit, I do not see much disagreement in the
> semantics and in the future direction between what Dscho is saying (unless
> I again misunderstood what he said) and what this round wants to bring.
I think Dscho's main worry matches what I asked about earlier, will we
be able to say "hg://example.org" or not.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 17:23 ` Junio C Hamano
2009-09-04 17:52 ` Sverre Rabbelier
@ 2009-09-04 18:02 ` Johannes Schindelin
2009-09-04 19:05 ` Daniel Barkalow
1 sibling, 1 reply; 18+ messages in thread
From: Johannes Schindelin @ 2009-09-04 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Sverre Rabbelier, git
Hi,
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It turns out that the method used to form URLs that use a helper
> > doesn't generalize well to other cases, because it interferes with the
> > ssh-style locations. Instead, some different mechanism needs to be
> > made up to handle arbitrary handlers that git doesn't know about.
> > Since we want to keep supporting "http://something", that'll have to
> > be a special case anyway, and so we might as well handle it by having
> > git know what helpers to use for things that we've always supported,
> > and use a single descriptive name for the helper that handles that
> > collection of URLs.
> >
> > As of this version, the idea is that there will be three ways helpers
> > get selected:
> >
> > - git selects a helper based on the URL being something traditionally
> > supported internally; that is, git recognizes the URL and knows
> > what to run, if possible, to handle it
> >
> > - git uses the "vcs" option if it is set
> >
> > - something with the URL that we don't understand well enough yet to
> > design, but which doesn't seem to be possible to fit in as a single
> > rule with the first item.
>
> Thanks for a clear description.
>
> I do not see that there is much difference between the above description
> and what Dscho is advocating, and I do not see anything to get excited
> about as Dscho seems to do.
I mainly take exception at complicating things with a "vcs" config
variable.
The way you describe it, I like it, as I do not see any mention of said
config variable there.
If you allow "git clone <URL>" for foreign vcs URLs, you do not need the
"vcs" variable. If you require that variable, you cannot allow an easy
clone, and you will earn my opposition.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 18:02 ` Johannes Schindelin
@ 2009-09-04 19:05 ` Daniel Barkalow
2009-09-04 19:35 ` Sverre Rabbelier
0 siblings, 1 reply; 18+ messages in thread
From: Daniel Barkalow @ 2009-09-04 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Sverre Rabbelier, git
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Junio C Hamano wrote:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> > > It turns out that the method used to form URLs that use a helper
> > > doesn't generalize well to other cases, because it interferes with the
> > > ssh-style locations. Instead, some different mechanism needs to be
> > > made up to handle arbitrary handlers that git doesn't know about.
> > > Since we want to keep supporting "http://something", that'll have to
> > > be a special case anyway, and so we might as well handle it by having
> > > git know what helpers to use for things that we've always supported,
> > > and use a single descriptive name for the helper that handles that
> > > collection of URLs.
> > >
> > > As of this version, the idea is that there will be three ways helpers
> > > get selected:
> > >
> > > - git selects a helper based on the URL being something traditionally
> > > supported internally; that is, git recognizes the URL and knows
> > > what to run, if possible, to handle it
> > >
> > > - git uses the "vcs" option if it is set
> > >
> > > - something with the URL that we don't understand well enough yet to
> > > design, but which doesn't seem to be possible to fit in as a single
> > > rule with the first item.
> >
> > Thanks for a clear description.
> >
> > I do not see that there is much difference between the above description
> > and what Dscho is advocating, and I do not see anything to get excited
> > about as Dscho seems to do.
>
> I mainly take exception at complicating things with a "vcs" config
> variable.
>
> The way you describe it, I like it, as I do not see any mention of said
> config variable there.
>
> If you allow "git clone <URL>" for foreign vcs URLs, you do not need the
> "vcs" variable. If you require that variable, you cannot allow an easy
> clone, and you will earn my opposition.
Some foreign vcses, including the only one I ever personally use, do not
have URLs, and require a bunch of options and paths to specify a
repository. I don't want to have to use:
url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
(actually, I don't even know what the normal thing is for a URL for
something that's split between multiple locations, or how URLs handle
"servers" that are arbitrary commands including options which make a
connection to the server)
For cases where the foreign vcs has something to put in the "url" spot,
you don't need to set "vcs". In fact, you are only allowed to set one or
the other of "vcs" and "url" with my current version. What you're
interested in is explicitly left for later, when we have a prototype
helper for such a foreign vcs and can try it out with potential users.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 19:05 ` Daniel Barkalow
@ 2009-09-04 19:35 ` Sverre Rabbelier
2009-09-04 20:10 ` Daniel Barkalow
2009-09-04 21:08 ` Johannes Schindelin
0 siblings, 2 replies; 18+ messages in thread
From: Sverre Rabbelier @ 2009-09-04 19:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Junio C Hamano, git
Heya,
On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org> wrote:
> Some foreign vcses, including the only one I ever personally use, do not
> have URLs, and require a bunch of options and paths to specify a
> repository. I don't want to have to use:
>
> url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
Btw, doesn't p4 have these config files that you can download that
contain the configuration? In that case
'p4://example.org/p4/main-development.configfile' would be very
convenient.
Regardless, I do think there should be some way to specify all this
outside of the url, but to me that's secondary. I think the primary
usecase is/should be cloning from some url in the form of
'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
or 'p4://.......', since those are both exceptions (the former being
an ambiguous url, and the latter being a non-url). Now I do understand
if you don't want to spend your time on implementing the specialized
url support since it doesn't scratch your itch, but at least your
series shouldn't impend supporting that in the near future.
> For cases where the foreign vcs has something to put in the "url" spot,
> you don't need to set "vcs". In fact, you are only allowed to set one or
> the other of "vcs" and "url" with my current version. What you're
> interested in is explicitly left for later, when we have a prototype
> helper for such a foreign vcs and can try it out with potential users.
I need to hurry up and get working on that hg implementation then :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 19:35 ` Sverre Rabbelier
@ 2009-09-04 20:10 ` Daniel Barkalow
2009-09-04 21:08 ` Johannes Schindelin
1 sibling, 0 replies; 18+ messages in thread
From: Daniel Barkalow @ 2009-09-04 20:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2258 bytes --]
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Some foreign vcses, including the only one I ever personally use, do not
> > have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
The only thing I know of which you might be thinking of is "client
specifications", which are like git superprojects. They're almost certain
to only specify one of the multiple locations that you want to have in the
same repository; the multiple locations are the paths you want to treat
as branches, and the client picks one branch of each project and places
it in some non-branch-specific location relative to other projects. (Of
course, someday I might want to support importing a client specification
as a git project with submodules, but it's got the same issues as
svn::externals without revision specifications seems to).
In any case, p4 doesn't have any easy generic way to specify how to
contact the server, and doesn't have anything client-side.
> Regardless, I do think there should be some way to specify all this
> outside of the url, but to me that's secondary. I think the primary
> usecase is/should be cloning from some url in the form of
> 'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
> or 'p4://.......', since those are both exceptions (the former being
> an ambiguous url, and the latter being a non-url). Now I do understand
> if you don't want to spend your time on implementing the specialized
> url support since it doesn't scratch your itch, but at least your
> series shouldn't impend supporting that in the near future.
I'm pretty sure that this series makes your primary usecase slightly
simpler to support, because it no longer is expected to handle the
ambiguous "http://" class of URLs.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 19:35 ` Sverre Rabbelier
2009-09-04 20:10 ` Daniel Barkalow
@ 2009-09-04 21:08 ` Johannes Schindelin
2009-09-04 22:18 ` Daniel Barkalow
1 sibling, 1 reply; 18+ messages in thread
From: Johannes Schindelin @ 2009-09-04 21:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Daniel Barkalow, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1650 bytes --]
Hi,
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> wrote:
> > Some foreign vcses, including the only one I ever personally use, do
> > not have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
If that's how p4 users initialize their working directories, then that is
the way to go.
And I cannot start to believe that the complicated way you described is
the common way to initialize p4 working directories, as that would tempt
the intelligence/enthusiasm of the average programmer.
> > For cases where the foreign vcs has something to put in the "url"
> > spot, you don't need to set "vcs". In fact, you are only allowed to
> > set one or the other of "vcs" and "url" with my current version. What
> > you're interested in is explicitly left for later, when we have a
> > prototype helper for such a foreign vcs and can try it out with
> > potential users.
>
> I need to hurry up and get working on that hg implementation then :).
Indeed you do. If only to prove that _this_ and the likes are something
to optimize for, not some obscure vcs config variable that only introduces
a little-exercized code path that's _prone_ to break and does not help
anybody.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 21:08 ` Johannes Schindelin
@ 2009-09-04 22:18 ` Daniel Barkalow
2009-09-04 22:36 ` Johannes Schindelin
0 siblings, 1 reply; 18+ messages in thread
From: Daniel Barkalow @ 2009-09-04 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2765 bytes --]
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
>
> > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > wrote:
> > > Some foreign vcses, including the only one I ever personally use, do
> > > not have URLs, and require a bunch of options and paths to specify a
> > > repository. I don't want to have to use:
> > >
> > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> >
> > Btw, doesn't p4 have these config files that you can download that
> > contain the configuration? In that case
> > 'p4://example.org/p4/main-development.configfile' would be very
> > convenient.
>
> If that's how p4 users initialize their working directories, then that is
> the way to go.
>
> And I cannot start to believe that the complicated way you described is
> the common way to initialize p4 working directories, as that would tempt
> the intelligence/enthusiasm of the average programmer.
Perforce is probably the single most popular system for git to import from
because it is such a monumental pain to use for anything at all that it's
easier to learn git, write a git importer, and use your git importer than
it is to actually use Perforce directly.
Of course, it's not really beyond the average programmer to get a p4
working directory, because whoever is running the server will have
provided a file to copy and instructions on setting an environment
variable. They don't know what the magic formula means; they just use it.
And they only work on one branch until that branch is done with,
and then they throw away that working directory, get a new working
directory, and never look at the other branch's history again (and
certainly never track anything across branches). Also, they have p4
experts who deal with merging branches so that stuff doesn't get lost when
moving to a new branch. And the experts have scripts built into the
release process that attempt to insure that things don't get lost. The
reason that my helper can't have a single location for a repository is
that the branches of a single project are strewn randomly about the
namespace, and a proper git import needs to know what to stitch into a
single repository.
For the matter of where the server is, Perforce supports just having a
"server:port" value, but if the organization uses this, there's no
authentication of users possible. Instead, organizations set up an ad hoc
collection of ssh proxies and give people a string which is the command to
go through those proxies, because Perforce only knows how to use rsh or a
command you provide that acts like rsh.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
2009-09-04 22:18 ` Daniel Barkalow
@ 2009-09-04 22:36 ` Johannes Schindelin
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2009-09-04 22:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Sverre Rabbelier, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4508 bytes --]
Hi,
On Fri, 4 Sep 2009, Daniel Barkalow wrote:
> On Fri, 4 Sep 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> >
> > > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > > wrote:
> > > > Some foreign vcses, including the only one I ever personally use, do
> > > > not have URLs, and require a bunch of options and paths to specify a
> > > > repository. I don't want to have to use:
> > > >
> > > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> > >
> > > Btw, doesn't p4 have these config files that you can download that
> > > contain the configuration? In that case
> > > 'p4://example.org/p4/main-development.configfile' would be very
> > > convenient.
> >
> > If that's how p4 users initialize their working directories, then that is
> > the way to go.
> >
> > And I cannot start to believe that the complicated way you described is
> > the common way to initialize p4 working directories, as that would tempt
> > the intelligence/enthusiasm of the average programmer.
>
> Perforce is probably the single most popular system for git to import
> from because it is such a monumental pain to use for anything at all
> that it's easier to learn git, write a git importer, and use your git
> importer than it is to actually use Perforce directly.
>
> Of course, it's not really beyond the average programmer to get a p4
> working directory, because whoever is running the server will have >
> provided a file to copy and instructions on setting an environment
> variable.
That is what we need to optimize for, then.
> They don't know what the magic formula means; they just use it. And they
> only work on one branch until that branch is done with, and then they
> throw away that working directory, get a new working directory, and
> never look at the other branch's history again (and certainly never
> track anything across branches). Also, they have p4 experts who deal
> with merging branches so that stuff doesn't get lost when moving to a
> new branch. And the experts have scripts built into the release process
> that attempt to insure that things don't get lost. The reason that my
> helper can't have a single location for a repository is that the
> branches of a single project are strewn randomly about the namespace,
> and a proper git import needs to know what to stitch into a single
> repository.
And why not having the different branches which are strewn randomly about
the namespace as separate remotes for a Git repository? After all, the
average p4 user will be wanting to work on _one_ branch, as you so aptly
described.
> For the matter of where the server is, Perforce supports just having a
> "server:port" value, but if the organization uses this, there's no
> authentication of users possible. Instead, organizations set up an ad
> hoc collection of ssh proxies and give people a string which is the
> command to go through those proxies, because Perforce only knows how to
> use rsh or a command you provide that acts like rsh.
That explains a tiny part of the long path you provided, but certainly not
all (I am especially curious what /bin/true thinks it's doing in that
URL).
If what you said about ssh is true, then it should be the same type of
invocation everywhere, and it should certainly be very easy to provide a
shortcut for that URL; no need for the _user_ (who could not care less how
ssh happens to be called) to remember.
Something like "git clone p4::ssh://p4ssh@projects/foo/bar-1.0/..." should
become a very easy and intuitive way for the average programmer to clone a
p4 branch into a Git repository.
Should the developer ever need to work with another branch of the same
project, very easy:
$ git remote add -f bar-1.1 p4::ssh://p4ssh@projects/foo/bar-1.1/...
$ git checkout -b my-1.1 bar-1.1/master
Now, I am not married to having more than one remote for multiple
branches, but there is _no_ reason why this has to be done at clone time,
if the average p4 user does not do that either. You can always teach
git-remote-p4 to behave sensibly and ask the user to
$ git config --add remote.origin.fetch \
+/foo/bar-1.1:refs/remotes/origin/bar-1.1
Note, these are two alternative suggestions. I am not trying to decide
what is better here, but I am convinced that both options are more
intuitive than the "vcs" variable.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-09-04 22:35 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-04 2:13 [PATCH 1/8] Make the "traditionally-supported" URLs a special case Daniel Barkalow
2009-09-04 5:29 ` Sverre Rabbelier
[not found] ` <20090904172345.6117@nanako3.lavabit.com>
2009-09-04 10:47 ` Sverre Rabbelier
2009-09-04 15:40 ` Daniel Barkalow
2009-09-04 17:14 ` Sverre Rabbelier
2009-09-04 17:23 ` Junio C Hamano
2009-09-04 17:52 ` Sverre Rabbelier
2009-09-04 18:02 ` Johannes Schindelin
2009-09-04 19:05 ` Daniel Barkalow
2009-09-04 19:35 ` Sverre Rabbelier
2009-09-04 20:10 ` Daniel Barkalow
2009-09-04 21:08 ` Johannes Schindelin
2009-09-04 22:18 ` Daniel Barkalow
2009-09-04 22:36 ` Johannes Schindelin
2009-09-04 9:04 ` Mike Ralphson
2009-09-04 10:34 ` Johannes Schindelin
2009-09-04 10:50 ` Junio C Hamano
2009-09-04 12:33 ` Johannes Schindelin
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.