Merge branch 'wk/doc-in-linux-3.x-era'

Update documentation to match more recent realities.

* wk/doc-in-linux-3.x-era:
Documentation: Update 'linux-2.6.git' -> 'linux.git'
Documentation: Update the NFS remote examples to use the staging repo
doc/clone: Pick more compelling paths for the --reference example
doc/clone: Remove the '--bare -l -s' example

diff --combined Documentation/user-manual.txt
index 644acce079df81ecd7c2cf8774b3e7fcba9c49d5,a13de937c4a057816f14ff0fd4f06228dcb43110..1bcf11b3971e7c09128f043b560c66af41332d79
--- 1/Documentation/user-manual.txt
--- 2/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@@ -57,17 -57,17 +57,17 @@@ download a copy of an existing reposito
  project in mind, here are some interesting examples:
  
  ------------------------------------------------
 -      # Git itself (approx. 10MB download):
 +      # Git itself (approx. 40MB download):
  $ git clone git://git.kernel.org/pub/scm/git/git.git
 -      # the Linux kernel (approx. 150MB download):
 -$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 +      # the Linux kernel (approx. 640MB download):
 +$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  ------------------------------------------------
  
  The initial clone may be time-consuming for a large project, but you
  will only need to clone once.
  
- The clone command creates a new directory named after the project (`git`
- or `linux-2.6` in the examples above).  After you cd into this
+ The clone command creates a new directory named after the project
+ (`git` or `linux` in the examples above).  After you cd into this
  directory, you will see that it contains a copy of the project files,
  called the <<def_working_tree,working tree>>, together with a special
  top-level directory named `.git`, which contains all the information
@@@ -431,19 -431,25 +431,25 @@@ You can also track branches from reposi
  cloned from, using linkgit:git-remote[1]:
  
  -------------------------------------------------
- $ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
- $ git fetch linux-nfs
- * refs/remotes/linux-nfs/master: storing branch 'master' ...
-   commit: bf81b46
+ $ git remote add staging git://git.kernel.org/.../gregkh/staging.git
+ $ git fetch staging
+ ...
+ From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
+  * [new branch]      master     -> staging/master
+  * [new branch]      staging-linus -> staging/staging-linus
+  * [new branch]      staging-next -> staging/staging-next
  -------------------------------------------------
  
  New remote-tracking branches will be stored under the shorthand name
- that you gave `git remote add`, in this case `linux-nfs`:
+ that you gave `git remote add`, in this case `staging`:
  
  -------------------------------------------------
  $ git branch -r
- linux-nfs/master
- origin/master
+   origin/HEAD -> origin/master
+   origin/master
+   staging/master
+   staging/staging-linus
+   staging/staging-next
  -------------------------------------------------
  
  If you run `git fetch <remote>` later, the remote-tracking branches
@@@ -455,9 -461,9 +461,9 @@@ a new stanza
  -------------------------------------------------
  $ cat .git/config
  ...
- [remote "linux-nfs"]
-       url = git://linux-nfs.org/pub/nfs-2.6.git
-       fetch = +refs/heads/*:refs/remotes/linux-nfs/*
+ [remote "staging"]
+       url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
+       fetch = +refs/heads/*:refs/remotes/staging/*
  ...
  -------------------------------------------------
  
@@@ -2156,7 -2162,7 +2162,7 @@@ To set this up, first create your work 
  tree:
  
  -------------------------------------------------
- $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git work
  $ cd work
  -------------------------------------------------
  
@@@ -2198,7 -2204,7 +2204,7 @@@ make it easy to push both branches to y
  -------------------------------------------------
  $ cat >> .git/config <<EOF
  [remote "mytree"]
-       url =  master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+       url =  master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux.git
        push = release
        push = test
  EOF
@@@ -4256,16 -4262,15 +4262,16 @@@ no longer need to call `setup_pager()` 
  Nowadays, `git log` is a builtin, which means that it is _contained_ in the
  command `git`.  The source side of a builtin is
  
 -- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
 -  and declared in `builtin.h`,
 +- a function called `cmd_<bla>`, typically defined in `builtin/<bla.c>`
 +  (note that older versions of Git used to have it in `builtin-<bla>.c`
 +  instead), and declared in `builtin.h`.
  
  - an entry in the `commands[]` array in `git.c`, and
  
  - an entry in `BUILTIN_OBJECTS` in the `Makefile`.
  
  Sometimes, more than one builtin is contained in one source file.  For
 -example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`,
 +example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin/log.c`,
  since they share quite a bit of code.  In that case, the commands which are
  _not_ named like the `.c` file in which they live have to be listed in
  `BUILT_INS` in the `Makefile`.
@@@ -4288,10 -4293,10 +4294,10 @@@ For the sake of clarity, let's stay wit
  - is plumbing, and
  
  - was around even in the initial commit (it literally went only through
 -  some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c`
 +  some 20 revisions as `cat-file.c`, was renamed to `builtin/cat-file.c`
    when made a builtin, and then saw less than 10 versions).
  
 -So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what
 +So, look into `builtin/cat-file.c`, search for `cmd_cat_file()` and look what
  it does.
  
  ------------------------------------------------------------------
@@@ -4367,7 -4372,7 +4373,7 @@@ Another example: Find out what to do i
  builtin:
  
  -------------------------------------------------
 -$ git log --no-merges --diff-filter=A builtin-*.c
 +$ git log --no-merges --diff-filter=A builtin/*.c
  -------------------------------------------------
  
  You see, Git is actually the best tool to find out about the source of Git