[PATCH 1/8] Make the "traditionally-supported" URLs a special case

[PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Daniel Barkalow]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Sverre Rabbelier]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Sverre Rabbelier]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Daniel Barkalow]

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*

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Sverre Rabbelier]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Junio C Hamano]

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.

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Sverre Rabbelier]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Johannes Schindelin]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Daniel Barkalow]

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*

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Sverre Rabbelier]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Daniel Barkalow]

[-- 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*

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Johannes Schindelin]

[-- 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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Daniel Barkalow]

[-- 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*

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Johannes Schindelin]

[-- 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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Mike Ralphson]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Johannes Schindelin]

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

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Junio C Hamano]

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.

Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

[Johannes Schindelin]

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