Add an 'Invocation' section to specify what the command line arguments
mean. Also include a link to git-remote in the 'See Also' section.
Signed-off-by: Ramkumar Ramachandra <redacted>
---
Changes: The second argument may be an arbitrary string as
Jonathan pointed out.
Documentation/git-remote-helpers.txt | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index 7a5569c..b0e7d54 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -7,7 +7,7 @@ git-remote-helpers - Helper programs to interact with
remote repositories
SYNOPSIS
--------
-'git remote-<transport>' <remote>
+'git remote-<transport>' <repository> [<URL>]
DESCRIPTION
-----------
@@ -38,6 +38,34 @@ transport protocols, such as 'git-remote-http',
'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INVOCATION
+----------
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
+
+When git encounters a URL of the form '<transport>://<address>', where
+'<transport>' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-<transport>' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '<transport>::<address>' explicitly instructs git to
+invoke 'git remote-<transport>' with '<address>' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '<address>', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote.<name>.vcs' set to
+'<transport>', git explicitly invokes 'git remote-<transport>' with
+'<name>' as the first argument. If set, the second argument is
+'remote.<name>.url'; otherwise, the second argument is omitted.
+
COMMANDS
--------
@@ -206,6 +234,10 @@ OPTIONS
must not rely on this option being set before
connect request occurs.
+SEE ALSO
+--------
+linkgit:git-remote[1]
+
Documentation
-------------
Documentation by Daniel Barkalow and Ilari Liusvaara
--
1.7.0.3
Hi Junio,
I see that you've applied v8 of my patch to pu, but there's a small
change in this revision:
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index 8838388..6ffc0da 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -44,9 +44,8 @@ INVOCATION
Remote helper programs are invoked with one or (optionally) two
arguments. The first argument specifies a remote repository as in git;
it is either the name of a configured remote or a URL. The second
-argument specifies a URL of the form '<transport>://<address>' or
-'<transport>::<address>', where '<address>' may be an arbitrary
-string.
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
When git encounters a URL of the form '<transport>://<address>', where
'<transport>' is a protocol that it cannot handle natively, it
-- Ram
You keep sending a broken patch. I've queued v7 and replaced with v8 and
both times I had to fix them in my editor.
I'm not replacing v8 with this tonight, as my pre-push test cycles are
already running (finished in one vm and continuing in another). Please
check what I queued and make sure your future patches applies on top of
what I have.
Thanks.
You keep sending a broken patch. I've queued v7 and replaced with v8 and
both times I had to fix them in my editor.
Oh, thanks for telling me- I should make sure that my future patches
aren't broken.
Can someone tell me what I'm doing wrong? Earlier, Junio also had a
problem with one of my patches being corrupt. I used git-imap-send and
the GMail web interface to fill out the "to", "cc" and some comments.
I'm not replacing v8 with this tonight, as my pre-push test cycles are
already running (finished in one vm and continuing in another).
Okay, no issues.
Please
check what I queued and make sure your future patches applies on top of
what I have.
Right, so you can just squash them. Also, I think I'm sending in
patches too fast so I'll slow down and rebase them on top of `pu`
every time.
Do tell me anything else that I can do to make my patches easier to
review and apply in future.
-- Ram
Ramkumar Ramachandra wrote:
Right, so you can just squash them. Also, I think I'm sending in
patches too fast so I'll slow down and rebase them on top of `pu`
every time.
Thank you for this. FWIW I find it useful when discussing a piece of
code or documentation to bounce back and forth multiple versions of
small fragments. Then once the discussion has settled down, it can be
useful to see the big picture again, with the new changes
incorporated.
If you want to make sure the latest version of a patch is always
available, that is a noble goal, too, but I think a frequently-
rebased public branch for your patch series is a better way to achieve
that.
Unrelated: in case you are interested, the git-resurrect.sh script
from contrib can extract topic branches from pu, if you want to see
Junio’s topic branch for your patch.
Cheers,
Jonathan