From: Junio C Hamano Date: Wed, 6 Feb 2013 00:13:32 +0000 (-0800) Subject: Merge branch 'ta/doc-no-small-caps' X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=e34c7e2b51c02a761a034b877b852dc0dbccf101;p=git.git 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 f059ea94d,1786d9dc9..d1bcda28f --- 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 f70ef9ded,3417cb3f5..c579fbc2b --- 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 :: 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 816c79150,86715735b..33ae69c11 --- 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