git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Daniel Barkalow <barkalow@iabervon.org>,
	Gabriel Filion <lelutin@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Sverre Rabbelier <srabbelier@gmail.com>,
	Michael J Gruber <git@drmicha.warpmail.net>,
	Git Mailing List <git@vger.kernel.org>,
	Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Subject: Re: [PATCH v3] Documentation/remote-helpers: Add invocation section
Date: Tue, 30 Mar 2010 14:50:55 -0500	[thread overview]
Message-ID: <20100330195055.GA10977@progeny.tock> (raw)
In-Reply-To: <f3271551003301218k4828c44id700b4865001baf9@mail.gmail.com>

Ramkumar Ramachandra wrote:

> +INVOCATION
> +----------
> +
> +Remote helper programs are invoked with one or (optionally) two
> +command line arguments. The first argument specifies a remote
> +repository as it would be in git; typically, it is either the name of
> +a configured remote or just a URL.

Yes, better.

> The second argument, if present, is
> +a URL, and serves to resolve ambiguities that may arise when only the
> +first argument is specified (i.e. when a remote has more than one
> +configured URL).

This seems to suggest that the remote helper should pay attention
primarily to the first argument and then use the second argument to
figure out some detail.  But AFAICT that is not true.

As I understand it, there are two cases.  I will call them the
“Subversion-like” (URL-based) and the “Perforce-like” (no URL) cases.
See [1] for an example of where I am getting this from, or see [2] for
more explanation of what I mean.

A hypothetical ‘git remote-svn’ would not need to examine its first
argument at all, unless it wants to use it to name a store of additional
per-remote data.  From its perspective, the second argument is not to
disambiguate.  Instead, the second argument is all that matters.

A hypothetical ‘git remote-p4’ might not understand URLs at all.
If so, it should error out if the first argument does not correspond to
a [remote "foo"] stanza or a second argument is supplied.

Regards,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/125374/focus=125410
[2] Examples:

In the Subversion-like case, the remote vcs uses a URL to identify the
repository.  So the configuration might look like

	[remote "upstream"]
	vcs = svn
	url = http://svn.example.com/some/project
	svn-fetch = branches/*:refs/remotes/upstream/*:
	svn-fetch = trunk:refs/remotes/upstream/trunk
	svn-fetch = tags/*:refs/tags/*

or

	[remote "upstream"]
	url = svn://svn.example.com/some/project
	svn-fetch = trunk:refs/remotes/upstream/master

There may be some cases in which this supposed URL should not actually be
a URL, as in:

	[remote "upstream"]
	vcs = svn
	url = /path/to/local/repo
	svn-fetch = :refs/remotes/upstream/master

and for this reason, the rule is that the URL can be an arbitrary string.

In the Perforce-like case, there is additional configuration required to
describe a repository _anyway_, so there is no need for a URL.  The
configuration looks like this:

	[remote "upstream"]
		vcs = p4
	[p4 "origin"]
		find-server-command = ssh bunch of complicated options
		random-p4-option = ...
		random-other-p4-option = ...

(or so I hear).  This case is quite weird in my opinion, but anyway,
there is no URL.

      parent reply	other threads:[~2010-03-30 19:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 19:18 [PATCH v3] Documentation/remote-helpers: Add invocation section Ramkumar Ramachandra
2010-03-30 19:28 ` Ramkumar Ramachandra
2010-03-30 19:50 ` Jonathan Nieder [this message]

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=20100330195055.GA10977@progeny.tock \
    --to=jrnieder@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ilari.liusvaara@elisanet.fi \
    --cc=lelutin@gmail.com \
    --cc=srabbelier@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).