Code

Merge branch 'maint'
authorJunio C Hamano <gitster@pobox.com>
Sat, 9 Aug 2008 08:40:08 +0000 (01:40 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sat, 9 Aug 2008 08:40:08 +0000 (01:40 -0700)
* maint:
  asciidoc markup fixes
  Fail properly when cloning from invalid HTTP URL

Conflicts:
Documentation/git-push.txt

1  2 
Documentation/git-push.txt
Documentation/git-rerere.txt
Documentation/pull-fetch-param.txt
transport.c

index 050c3ddae2732fdf4cb9f3b0f798e3d2d190fa4e,60d53391d263e890ba1fa9183b46a72d090a5749..45c96435fa66ab4b1b57b6a860a2fc264321cfe4
@@@ -9,9 -9,8 +9,9 @@@ git-push - Update remote refs along wit
  SYNOPSIS
  --------
  [verse]
 -'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
 -           [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
 +'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
 +         [--repo=all] [-f | --force] [-v | --verbose]
 +         [<repository> <refspec>...]
  
  DESCRIPTION
  -----------
@@@ -30,9 -29,9 +30,9 @@@ OPTION
        The "remote" repository that is destination of a push
        operation.  See the section <<URLS,GIT URLS>> below.
  
 -<refspec>::
 +<refspec>...::
-       The canonical format of each <refspec> parameter is
-       `+?<src>:<dst>`; that is, an optional plus `+`, followed
+       The canonical format of a <refspec> parameter is
+       `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
        by the source ref, followed by a colon `:`, followed by
        the destination ref.
  +
@@@ -68,8 -67,7 +68,8 @@@ nor in any Push line of the correspondi
  
  --mirror::
        Instead of naming each ref to push, specifies that all
 -      refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`
 +      refs under `$GIT_DIR/refs/` (which includes but is not
 +      limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
        be mirrored to the remote repository.  Newly created local
        refs will be pushed to the remote end, locally updated refs
        will be force updated on the remote end, and deleted refs
  
  --thin::
  --no-thin::
 -      These options are passed to `git-send-pack`.  Thin
 +      These options are passed to 'git-send-pack'.  Thin
        transfer spends extra cycles to minimize the number of
        objects to be sent and meant to be used on slower connection.
  
@@@ -181,11 -179,11 +181,11 @@@ git push origin :experimental:
        Find a ref that matches `experimental` in the `origin` repository
        (e.g. `refs/heads/experimental`), and delete it.
  
 -git push origin master:satellite/master::
 -      Find a ref that matches `master` in the source repository
 -      (most likely, it would find `refs/heads/master`), and update
 -      the ref that matches `satellite/master` (most likely, it would
 -      be `refs/remotes/satellite/master`) in `origin` repository with it.
 +git push origin master:satellite/master dev:satellite/dev::
 +      Use the source ref that matches `master` (e.g. `refs/heads/master`)
 +      to update the ref that matches `satellite/master` (most probably
 +      `refs/remotes/satellite/master`) in the `origin` repository, then
 +      do the same for `dev` and `satellite/dev`.
  
  git push origin master:refs/heads/experimental::
        Create the branch `experimental` in the `origin` repository
index 89f321b414212a555f1e0fb0ff0ce6f4c180fd06,8f12dc975910b14ecb9f11a07e0161755f412a52..64715c17da6c313a1cec4c353300eb0faee2313b
@@@ -7,7 -7,7 +7,7 @@@ git-rerere - Reuse recorded resolution 
  
  SYNOPSIS
  --------
 -'git-rerere' [clear|diff|status|gc]
 +'git rerere' ['clear'|'diff'|'status'|'gc']
  
  DESCRIPTION
  -----------
@@@ -30,26 -30,26 +30,26 @@@ enable this command
  COMMANDS
  --------
  
 -Normally, git-rerere is run without arguments or user-intervention.
 +Normally, 'git-rerere' is run without arguments or user-intervention.
  However, it has several commands that allow it to interact with
  its working state.
  
  'clear'::
  
  This resets the metadata used by rerere if a merge resolution is to be
 -is aborted.  Calling linkgit:git-am[1] --skip or linkgit:git-rebase[1]
 -[--skip|--abort] will automatically invoke this command.
 +aborted.  Calling 'git-am [--skip|--abort]' or 'git-rebase [--skip|--abort]'
 +will automatically invoke this command.
  
  'diff'::
  
  This displays diffs for the current state of the resolution.  It is
  useful for tracking what has changed while the user is resolving
  conflicts.  Additional arguments are passed directly to the system
 -diff(1) command installed in PATH.
 +'diff' command installed in PATH.
  
  'status'::
  
 -Like diff, but this only prints the filenames that will be tracked
 +Like 'diff', but this only prints the filenames that will be tracked
  for resolutions.
  
  'gc'::
@@@ -90,15 -90,15 +90,15 @@@ One way to do it is to pull master int
  
  The commits marked with `*` touch the same area in the same
  file; you need to resolve the conflicts when creating the commit
- marked with `+`.  Then you can test the result to make sure your
+ marked with `{plus}`.  Then you can test the result to make sure your
  work-in-progress still works with what is in the latest master.
  
  After this test merge, there are two ways to continue your work
  on the topic.  The easiest is to build on top of the test merge
- commit `+`, and when your work in the topic branch is finally
+ commit `{plus}`, and when your work in the topic branch is finally
  ready, pull the topic branch into master, and/or ask the
  upstream to pull from you.  By that time, however, the master or
- the upstream might have been advanced since the test merge `+`,
+ the upstream might have been advanced since the test merge `{plus}`,
  in which case the final commit graph would look like this:
  
  ------------
@@@ -142,33 -142,33 +142,33 @@@ finally ready and merged into the maste
  would require you to resolve the conflict, introduced by the
  commits marked with `*`.  However, often this conflict is the
  same conflict you resolved when you created the test merge you
 -blew away.  `git-rerere` command helps you to resolve this final
 +blew away.  'git-rerere' command helps you to resolve this final
  conflicted merge using the information from your earlier hand
  resolve.
  
 -Running `git-rerere` command immediately after a conflicted
 +Running the 'git-rerere' command immediately after a conflicted
  automerge records the conflicted working tree files, with the
  usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
  them.  Later, after you are done resolving the conflicts,
 -running `git-rerere` again records the resolved state of these
 +running 'git-rerere' again records the resolved state of these
  files.  Suppose you did this when you created the test merge of
  master into the topic branch.
  
 -Next time, running `git-rerere` after seeing a conflicted
 +Next time, running 'git-rerere' after seeing a conflicted
  automerge, if the conflict is the same as the earlier one
  recorded, it is noticed and a three-way merge between the
  earlier conflicted automerge, the earlier manual resolution, and
  the current conflicted automerge is performed by the command.
  If this three-way merge resolves cleanly, the result is written
  out to your working tree file, so you would not have to manually
 -resolve it.  Note that `git-rerere` leaves the index file alone,
 +resolve it.  Note that 'git-rerere' leaves the index file alone,
  so you still need to do the final sanity checks with `git diff`
 -(or `git diff -c`) and `git add` when you are satisfied.
 +(or `git diff -c`) and 'git-add' when you are satisfied.
  
 -As a convenience measure, `git-merge` automatically invokes
 -`git-rerere` when it exits with a failed automerge, which
 +As a convenience measure, 'git-merge' automatically invokes
 +'git-rerere' when it exits with a failed automerge, which
  records it if it is a new conflict, or reuses the earlier hand
 -resolve when it is not.  `git-commit` also invokes `git-rerere`
 +resolve when it is not.  'git-commit' also invokes 'git-rerere'
  when recording a merge result.  What this means is that you do
  not have to do anything special yourself (Note: you still have
  to set the config variable rerere.enabled to enable this command).
@@@ -178,8 -178,8 +178,8 @@@ resolution is recorded, and it will be 
  actual merge later with updated master and topic branch, as long
  as the earlier resolution is still applicable.
  
 -The information `git-rerere` records is also used when running
 -`git-rebase`.  After blowing away the test merge and continuing
 +The information 'git-rerere' records is also used when running
 +'git-rebase'.  After blowing away the test merge and continuing
  development on the topic branch:
  
  ------------
@@@ -198,7 -198,7 +198,7 @@@ you could run `git rebase master topic`
  up-to-date even before your topic is ready to be sent upstream.
  This would result in falling back to three-way merge, and it
  would conflict the same way the test merge you resolved earlier.
 -`git-rerere` is run by `git rebase` to help you resolve this
 +'git-rerere' is run by 'git-rebase' to help you resolve this
  conflict.
  
  
index 00a8d210476089257be3d09ac8a16d1f8e1dd8dc,f1577382791e54f1bca017425c8f29dced900feb..ebdd948cd23931e9bbc35bb304868ce46902e464
@@@ -6,7 -6,7 +6,7 @@@
  
  <refspec>::
        The canonical format of a <refspec> parameter is
-       `+?<src>:<dst>`; that is, an optional plus `+`, followed
+       `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
        by the source ref, followed by a colon `:`, followed by
        the destination ref.
  +
@@@ -32,7 -32,7 +32,7 @@@ must know this is the expected usage pa
  [NOTE]
  You never do your own development on branches that appear
  on the right hand side of a <refspec> colon on `Pull:` lines;
 -they are to be updated by `git-fetch`.  If you intend to do
 +they are to be updated by 'git-fetch'.  If you intend to do
  development derived from a remote branch `B`, have a `Pull:`
  line to track it (i.e. `Pull: B:remote-B`), and have a separate
  branch `my-B` to do your development on top of it.  The latter
@@@ -44,13 -44,13 +44,13 @@@ on the remote branch, merge it into you
  +
  [NOTE]
  There is a difference between listing multiple <refspec>
 -directly on `git-pull` command line and having multiple
 +directly on 'git-pull' command line and having multiple
  `Pull:` <refspec> lines for a <repository> and running
 -`git-pull` command without any explicit <refspec> parameters.
 +'git-pull' command without any explicit <refspec> parameters.
  <refspec> listed explicitly on the command line are always
  merged into the current branch after fetching.  In other words,
  if you list more than one remote refs, you would be making
 -an Octopus.  While `git-pull` run without any explicit <refspec>
 +an Octopus.  While 'git-pull' run without any explicit <refspec>
  parameter takes default <refspec>s from `Pull:` lines, it
  merges only the first <refspec> found into the current branch,
  after fetching all the remote refs.  This is because making an
diff --combined transport.c
index 6eb65b873afc9dfd457e974b63d88350bb8dc913,b3e3e61f9dddec8230532f7d248beba801a38123..71433d99978ddcc53c80fd6de4aee98871c6d8cf
@@@ -463,17 -463,14 +463,14 @@@ static struct ref *get_refs_via_curl(st
                run_active_slot(slot);
                if (results.curl_result != CURLE_OK) {
                        strbuf_release(&buffer);
-                       if (missing_target(&results)) {
-                               return NULL;
-                       } else {
-                               error("%s", curl_errorstr);
-                               return NULL;
-                       }
+                       if (missing_target(&results))
+                               die("%s not found: did you run git update-server-info on the server?", refs_url);
+                       else
+                               die("%s download error - %s", refs_url, curl_errorstr);
                }
        } else {
                strbuf_release(&buffer);
-               error("Unable to start request");
-               return NULL;
+               die("Unable to start HTTP request");
        }
  
        data = buffer.buf;
@@@ -711,8 -708,7 +708,8 @@@ static int is_local(const char *url
  {
        const char *colon = strchr(url, ':');
        const char *slash = strchr(url, '/');
 -      return !colon || (slash && slash < colon);
 +      return !colon || (slash && slash < colon) ||
 +              has_dos_drive_prefix(url);
  }
  
  static int is_file(const char *url)