From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 9 Jul 2007 01:28:31 +0000 (-0700)
Subject: Merge branch 'maint'
X-Git-Tag: v1.5.3-rc1~39
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/5c054a985a5b7e758f48353ac03582c9b2a9f919?ds=inline;hp=-c

Merge branch 'maint'

* maint:
user-manual: fix directory name in git-archive example
user-manual: more explanation of push and pull usage
tutorial: Fix typo
user-manual: grammar and style fixes
---

5c054a985a5b7e758f48353ac03582c9b2a9f919
diff --combined Documentation/tutorial.txt
index 53403c6db3,965ec00a6b..bd9fbee99a
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@@ -304,7 -304,7 +304,7 @@@ it easier
  $ git remote add bob /home/bob/myrepo
  ------------------------------------------------
  
- With this, you can perform the first operation alone using the
+ With this, Alice can perform the first operation alone using the
  "git fetch" command without merging them with her own branch,
  using:
  
@@@ -354,7 -354,7 +354,7 @@@ used for pulls
  
  -------------------------------------
  $ git config --get remote.origin.url
 -/home/bob/myrepo
 +/home/alice/project
  -------------------------------------
  
  (The complete configuration created by git-clone is visible using
diff --combined Documentation/user-manual.txt
index c23077c724,d6caff4248..14825c6411
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@@ -154,11 -154,11 +154,11 @@@ Author: Jamal Hadi Salim <hadi@cyberus.
  Date:   Sat Dec 2 22:22:25 2006 -0800
  
      [XFRM]: Fix aevent structuring to be more complete.
 -    
 +
      aevents can not uniquely identify an SA. We break the ABI with this
      patch, but consensus is that since it is not yet utilized by any
      (known) application then it is fine (better do it now than later).
 -    
 +
      Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: David S. Miller <davem@davemloft.net>
  
@@@ -167,7 -167,7 +167,7 @@@ index 8be626f..d7aac9d 10064
  --- a/Documentation/networking/xfrm_sync.txt
  +++ b/Documentation/networking/xfrm_sync.txt
  @@ -47,10 +47,13 @@ aevent_id structure looks like:
 - 
 +
      struct xfrm_aevent_id {
                struct xfrm_usersa_id           sa_id;
  +             xfrm_address_t                  saddr;
@@@ -890,7 -890,7 +890,7 @@@ $ git archive --format=tar --prefix=pro
  -------------------------------------------------
  
  will use HEAD to produce a tar archive in which each filename is
- preceded by "prefix/".
+ preceded by "project/".
  
  If you're releasing a new version of a software project, you may want
  to simultaneously make a changelog to include in the release
@@@ -1057,7 -1057,7 +1057,7 @@@ $ git sho
  -------------------------------------------------
  
  As a special shortcut,
 -		
 +
  -------------------------------------------------
  $ git commit -a
  -------------------------------------------------
@@@ -1528,9 -1528,9 +1528,9 @@@ dangling tree b24c2473f1fd3d91352a62479
  -------------------------------------------------
  
  Dangling objects are not a problem.  At worst they may take up a little
- extra disk space.  They can sometimes provide a last-resort method of
- recovery lost work--see <<dangling-objects>> for details.  However, if
- you want, you may remove them with gitlink:git-prune[1] or the --prune
+ extra disk space.  They can sometimes provide a last-resort method for
+ recovering lost work--see <<dangling-objects>> for details.  However, if
+ you wish, you can remove them with gitlink:git-prune[1] or the --prune
  option to gitlink:git-gc[1]:
  
  -------------------------------------------------
@@@ -1555,7 -1555,7 +1555,7 @@@ history
  
  Fortunately, git also keeps a log, called a "reflog", of all the
  previous values of each branch.  So in this case you can still find the
 -old history using, for example, 
 +old history using, for example,
  
  -------------------------------------------------
  $ git log master@{1}
@@@ -1631,7 -1631,7 +1631,7 @@@ If you decide you want the history back
  reference pointing to it, for example, a new branch:
  
  ------------------------------------------------
 -$ git branch recovered-branch 7281251ddd 
 +$ git branch recovered-branch 7281251ddd
  ------------------------------------------------
  
  Other types of dangling objects (blobs and trees) are also possible, and
@@@ -1772,7 -1772,7 +1772,7 @@@ repository, but it works just as well i
  
  If you and the maintainer both have accounts on the same machine, then
  you can just pull changes from each other's repositories directly;
- commands that accepts repository URLs as arguments will also accept a
+ commands that accept repository URLs as arguments will also accept a
  local directory name:
  
  -------------------------------------------------
@@@ -1780,6 -1780,15 +1780,15 @@@ $ git clone /path/to/repositor
  $ git pull /path/to/other/repository
  -------------------------------------------------
  
+ or an ssh url:
+ 
+ -------------------------------------------------
+ $ git clone ssh://yourhost/~you/repository
+ -------------------------------------------------
+ 
+ For projects with few developers, or for synchronizing a few private
+ repositories, this may be all you need.
+ 
  However, the more common way to do this is to maintain a separate public
  repository (usually on a different host) for others to pull changes
  from.  This is usually more convenient, and allows you to cleanly
@@@ -1794,7 -1803,7 +1803,7 @@@ like this
  
                          you push
    your personal repo ------------------> your public repo
 -  	^                                     |
 +	^                                     |
  	|                                     |
  	| you pull                            | they pull
  	|                                     |
@@@ -1802,6 -1811,8 +1811,8 @@@
          |               they push             V
    their public repo <------------------- their repo
  
+ We explain how to do this in the following sections.
+ 
  [[setting-up-a-public-repository]]
  Setting up a public repository
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@@ -1913,6 -1924,12 +1924,12 @@@ proceeding the branch name by a plus si
  $ git push ssh://yourserver.com/~you/proj.git +master
  -------------------------------------------------
  
+ Note that the target of a "push" is normally a
+ <<def_bare_repository,bare>> repository.  You can also push to a
+ repository that has a checked-out working tree, but the working tree
+ will not be updated by the push.  This may lead to unexpected results if
+ the branch you push to is the currently checked-out branch!
+ 
  As with git-fetch, you may also set up configuration options to
  save typing; so, for example, after
  
@@@ -2360,7 -2377,7 +2377,7 @@@ the result would create a new merge com
          \        \
           a--b--c--m <-- mywork
  ................................................
 - 
 +
  However, if you prefer to keep the history in mywork a simple series of
  commits without any merges, you may instead choose to use
  gitlink:git-rebase[1]:
@@@ -2736,7 -2753,7 +2753,7 @@@ must have at least one root, and while 
  root objects together into one project by creating a commit object which
  has two or more separate roots as its ultimate parents, that's probably
  just going to confuse people.  So aim for the notion of "one root object
 -per project", even if git itself does not enforce that. 
 +per project", even if git itself does not enforce that.
  
  A <<def_tag_object,"tag" object>> symbolically identifies and can be
  used to sign other objects. It contains the identifier and type of
@@@ -2955,15 -2972,15 +2972,15 @@@ cache, and the normal operation is to r
  known tree object, or update/compare it with a live tree that is being
  developed.  If you blow the directory cache away entirely, you generally
  haven't lost any information as long as you have the name of the tree
 -that it described. 
 +that it described.
  
 -At the same time, the index is at the same time also the
 -staging area for creating new trees, and creating a new tree always
 -involves a controlled modification of the index file.  In particular,
 -the index file can have the representation of an intermediate tree that
 -has not yet been instantiated.  So the index can be thought of as a
 -write-back cache, which can contain dirty information that has not yet
 -been written back to the backing store.
 +At the same time, the index is also the staging area for creating
 +new trees, and creating a new tree always involves a controlled
 +modification of the index file.  In particular, the index file can
 +have the representation of an intermediate tree that has not yet been
 +instantiated.  So the index can be thought of as a write-back cache,
 +which can contain dirty information that has not yet been written back
 +to the backing store.
  
  
  
@@@ -2975,7 -2992,7 +2992,7 @@@ Generally, all "git" operations work o
  work *purely* on the index file (showing the current state of the
  index), but most operations move data to and from the index file. Either
  from the database or from the working directory. Thus there are four
 -main combinations: 
 +main combinations:
  
  [[working-directory-to-index]]
  working directory -> index
@@@ -3438,7 -3455,7 +3455,7 @@@ because you interrupted a "git fetch" w
  leaving _some_ of the new objects in the object database, but just
  dangling and useless.
  
 -Anyway, once you are sure that you're not interested in any dangling 
 +Anyway, once you are sure that you're not interested in any dangling
  state, you can just prune all unreachable objects:
  
  ------------------------------------------------
@@@ -3449,12 -3466,12 +3466,12 @@@ and they'll be gone. But you should onl
  repository - it's kind of like doing a filesystem fsck recovery: you
  don't want to do that while the filesystem is mounted.
  
 -(The same is true of "git-fsck" itself, btw - but since 
 -git-fsck never actually *changes* the repository, it just reports 
 -on what it found, git-fsck itself is never "dangerous" to run. 
 -Running it while somebody is actually changing the repository can cause 
 -confusing and scary messages, but it won't actually do anything bad. In 
 -contrast, running "git prune" while somebody is actively changing the 
 +(The same is true of "git-fsck" itself, btw - but since
 +git-fsck never actually *changes* the repository, it just reports
 +on what it found, git-fsck itself is never "dangerous" to run.
 +Running it while somebody is actually changing the repository can cause
 +confusing and scary messages, but it won't actually do anything bad. In
 +contrast, running "git prune" while somebody is actively changing the
  repository is a *BAD* idea).
  
  [[birdview-on-the-source-code]]