From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 6 Feb 2013 00:13:32 +0000 (-0800)
Subject: Merge branch 'ta/doc-no-small-caps'
X-Git-Tag: v1.8.2-rc0~50
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/e34c7e2b51c02a761a034b877b852dc0dbccf101
Merge branch 'ta/doc-no-small-caps'
Update documentation to change "GIT" which was a poor-man's small
caps to "Git". The latter was the intended spelling.
Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.
* ta/doc-no-small-caps:
Documentation: StGit is the right spelling, not StGIT
Documentation: describe the "repository" in repository-layout
Documentation: add a description for 'gitfile' to glossary
Documentation: do not use undefined terms git-dir and git-file
Documentation: the name of the system is 'Git', not 'git'
Documentation: avoid poor-man's small caps GIT
---
e34c7e2b51c02a761a034b877b852dc0dbccf101
diff --cc Documentation/git-cvsimport.txt
index f059ea94da,1786d9dc96..d1bcda28f4
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@@ -18,13 -18,7 +18,13 @@@ SYNOPSI
DESCRIPTION
-----------
+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
+deprecated; it does not work with cvsps version 3 and later. If you are
+performing a one-shot import of a CVS repository consider using
+link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
+link:https://github.com/BartMassey/parsecvs[parsecvs].
+
- Imports a CVS repository into git. It will either create a new
+ Imports a CVS repository into Git. It will either create a new
repository, or incrementally import into an existing one.
Splitting the CVS log into patch sets is done by 'cvsps'.
diff --cc Documentation/git-p4.txt
index f70ef9ded2,3417cb3f59..c579fbc2b8
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@@ -107,16 -107,11 +107,16 @@@ This imports the specified depot int
'--branch' option can be used to specify a different branch to
be used for the p4 content.
- If a git repository includes branches 'refs/remotes/origin/p4', these
+ If a Git repository includes branches 'refs/remotes/origin/p4', these
will be fetched and consulted first during a 'git p4 sync'. Since
importing directly from p4 is considerably slower than pulling changes
- from a git remote, this can be useful in a multi-developer environment.
+ from a Git remote, this can be useful in a multi-developer environment.
+If there are multiple branches, doing 'git p4 sync' will automatically
+use the "BRANCH DETECTION" algorithm to try to partition new changes
+into the right branch. This can be overridden with the '--branch'
+option to specify just a single branch to update.
+
Rebase
~~~~~~
@@@ -178,14 -173,12 +178,14 @@@ subsequent 'sync' operations
--branch <branch>::
Import changes into given branch. If the branch starts with
- 'refs/', it will be used as is, otherwise the path 'refs/heads/'
- will be prepended. The default branch is 'master'. If used
- with an initial clone, no HEAD will be checked out.
+ 'refs/', it will be used as is. Otherwise if it does not start
+ with 'p4/', that prefix is added. The branch is assumed to
+ name a remote tracking, but this can be modified using
+ '--import-local', or by giving a full ref name. The default
+ branch is 'master'.
+
This example imports a new remote "p4/proj2" into an existing
- git repository:
+ Git repository:
+
----
$ git init
diff --cc Documentation/howto/maintain-git.txt
index 816c791502,86715735b3..33ae69c11f
--- a/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@@ -10,12 -10,9 +10,12 @@@ Content-type: text/asciido
How to maintain Git
===================
+Activities
+----------
+
- The maintainer's git time is spent on three activities.
+ The maintainer's Git time is spent on three activities.
- - Communication (60%)
+ - Communication (45%)
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
@@@ -87,22 -77,14 +87,22 @@@ this mailing list after each feature re
are found before new topics are merged to 'master'.
+A Typical Git Day
+-----------------
+
- A typical git day for the maintainer implements the above policy
+ A typical Git day for the maintainer implements the above policy
by doing the following:
- - Scan mailing list and #git channel log. Respond with review
- comments, suggestions etc. Kibitz. Collect potentially
- usable patches from the mailing list. Patches about a single
- topic go to one mailbox (I read my mail in Gnus, and type
- \C-o to save/append messages in files in mbox format).
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up solving. Send it out just like other
+ contributors do, and pick them up just like patches from other
+ contributors (see above).
- Review the patches in the saved mailboxes. Edit proposed log
message for typofixes and clarifications, and add Acks