mirror of
https://github.com/git/git
synced 2024-07-02 15:48:44 +00:00
doc: keep first level section header in upper case
When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Nguyễn Thái Ngọc Duy
Junio C Hamano
parent
1f1cddd558
commit
76a8788c14
|
|
@ -193,7 +193,7 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
|
|||
for command-line options).
|
||||
|
||||
|
||||
Configuration
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
The optional configuration variable `core.excludesFile` indicates a path to a
|
||||
|
|
@ -226,7 +226,7 @@ Because this example lets the shell expand the asterisk (i.e. you are
|
|||
listing the files explicitly), it does not consider
|
||||
`subdir/git-foo.sh`.
|
||||
|
||||
Interactive mode
|
||||
INTERACTIVE MODE
|
||||
----------------
|
||||
When the command enters the interactive mode, it shows the
|
||||
output of the 'status' subcommand, and then goes into its
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ When `git apply` is used as a "better GNU patch", the user can pass
|
|||
the `--unsafe-paths` option to override this safety check. This option
|
||||
has no effect when `--index` or `--cached` is in use.
|
||||
|
||||
Configuration
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
apply.ignoreWhitespace::
|
||||
|
|
@ -251,7 +251,7 @@ apply.whitespace::
|
|||
When no `--whitespace` flag is given from the command
|
||||
line, this configuration item is used as the default.
|
||||
|
||||
Submodules
|
||||
SUBMODULES
|
||||
----------
|
||||
If the patch contains any changes to submodules then 'git apply'
|
||||
treats these changes as follows.
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ CONFIGURATION
|
|||
`--list` is used or implied. The default is to use a pager.
|
||||
See linkgit:git-config[1].
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Start development from a known tag::
|
||||
|
|
@ -318,7 +318,7 @@ See linkgit:git-fetch[1].
|
|||
is currently checked out) does not have all commits from the test branch.
|
||||
|
||||
|
||||
Notes
|
||||
NOTES
|
||||
-----
|
||||
|
||||
If you are creating a branch that you want to checkout immediately, it is
|
||||
|
|
|
|||
|
|
@ -92,8 +92,8 @@ It is okay to err on the side of caution, causing the bundle file
|
|||
to contain objects already in the destination, as these are ignored
|
||||
when unpacking at the destination.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Assume you want to transfer the history from a repository R1 on machine A
|
||||
to another repository R2 on machine B.
|
||||
|
|
|
|||
|
|
@ -273,7 +273,7 @@ or `--mirror` is given)
|
|||
:git-clone: 1
|
||||
include::urls.txt[]
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
* Clone from upstream:
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ allowing access over SSH.
|
|||
------
|
||||
|
||||
[[dbbackend]]
|
||||
Database Backend
|
||||
DATABASE BACKEND
|
||||
----------------
|
||||
|
||||
'git-cvsserver' uses one database per Git head (i.e. CVS module) to
|
||||
|
|
@ -321,7 +321,7 @@ git-cvsserver, as described above.
|
|||
When these environment variables are set, the corresponding
|
||||
command-line arguments may not be used.
|
||||
|
||||
Eclipse CVS Client Notes
|
||||
ECLIPSE CVS CLIENT NOTES
|
||||
------------------------
|
||||
|
||||
To get a checkout with the Eclipse CVS client:
|
||||
|
|
@ -346,7 +346,7 @@ offer. In that case CVS_SERVER is ignored, and you will have to replace
|
|||
the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
|
||||
so that calling 'cvs' effectively calls 'git-cvsserver'.
|
||||
|
||||
Clients known to work
|
||||
CLIENTS KNOWN TO WORK
|
||||
---------------------
|
||||
|
||||
- CVS 1.12.9 on Debian
|
||||
|
|
@ -354,7 +354,7 @@ Clients known to work
|
|||
- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
|
||||
- TortoiseCVS
|
||||
|
||||
Operations supported
|
||||
OPERATIONS SUPPORTED
|
||||
--------------------
|
||||
|
||||
All the operations required for normal use are supported, including
|
||||
|
|
@ -424,7 +424,7 @@ For best consistency with 'cvs', it is probably best to override the
|
|||
defaults by setting `gitcvs.usecrlfattr` to true,
|
||||
and `gitcvs.allBinary` to "guess".
|
||||
|
||||
Dependencies
|
||||
DEPENDENCIES
|
||||
------------
|
||||
'git-cvsserver' depends on DBD::SQLite.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,14 +37,14 @@ include::diff-options.txt[]
|
|||
|
||||
include::diff-format.txt[]
|
||||
|
||||
Operating Modes
|
||||
OPERATING MODES
|
||||
---------------
|
||||
You can choose whether you want to trust the index file entirely
|
||||
(using the `--cached` flag) or ask the diff logic to show any files
|
||||
that don't match the stat state as being "tentatively changed". Both
|
||||
of these operations are very useful indeed.
|
||||
|
||||
Cached Mode
|
||||
CACHED MODE
|
||||
-----------
|
||||
If `--cached` is specified, it allows you to ask:
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ So doing a `git diff-index --cached` is basically very useful when you are
|
|||
asking yourself "what have I already marked for being committed, and
|
||||
what's the difference to a previous tree".
|
||||
|
||||
Non-cached Mode
|
||||
NON-CACHED MODE
|
||||
---------------
|
||||
The "non-cached" mode takes a different approach, and is potentially
|
||||
the more useful of the two in that what it does can't be emulated with
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ include::pretty-options.txt[]
|
|||
include::pretty-formats.txt[]
|
||||
|
||||
|
||||
Limiting Output
|
||||
LIMITING OUTPUT
|
||||
---------------
|
||||
If you're only interested in differences in a subset of files, for
|
||||
example some architecture-specific files, you might do:
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ smaller output, and it is usually easy to quickly confirm that there is
|
|||
no private data in the stream.
|
||||
|
||||
|
||||
Limitations
|
||||
LIMITATIONS
|
||||
-----------
|
||||
|
||||
Since 'git fast-import' cannot tag trees, you will not be
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ Performance and Compression Tuning
|
|||
fastimport.unpackLimit::
|
||||
See linkgit:git-config[1]
|
||||
|
||||
Performance
|
||||
PERFORMANCE
|
||||
-----------
|
||||
The design of fast-import allows it to import large projects in a minimum
|
||||
amount of memory usage and processing time. Assuming the frontend
|
||||
|
|
@ -155,7 +155,7 @@ faster if the source data is stored on a different drive than the
|
|||
destination Git repository (due to less IO contention).
|
||||
|
||||
|
||||
Development Cost
|
||||
DEVELOPMENT COST
|
||||
----------------
|
||||
A typical frontend for fast-import tends to weigh in at approximately 200
|
||||
lines of Perl/Python/Ruby code. Most developers have been able to
|
||||
|
|
@ -165,7 +165,7 @@ an ideal situation, given that most conversion tools are throw-away
|
|||
(use once, and never look back).
|
||||
|
||||
|
||||
Parallel Operation
|
||||
PARALLEL OPERATION
|
||||
------------------
|
||||
Like 'git push' or 'git fetch', imports handled by fast-import are safe to
|
||||
run alongside parallel `git repack -a -d` or `git gc` invocations,
|
||||
|
|
@ -186,7 +186,7 @@ this only be used on an otherwise quiet repository. Using --force
|
|||
is not necessary for an initial import into an empty repository.
|
||||
|
||||
|
||||
Technical Discussion
|
||||
TECHNICAL DISCUSSION
|
||||
--------------------
|
||||
fast-import tracks a set of branches in memory. Any branch can be created
|
||||
or modified at any point during the import process by sending a
|
||||
|
|
@ -204,7 +204,7 @@ directory also allows fast-import to run very quickly, as it does not
|
|||
need to perform any costly file update operations when switching
|
||||
between branches.
|
||||
|
||||
Input Format
|
||||
INPUT FORMAT
|
||||
------------
|
||||
With the exception of raw file data (which Git does not interpret)
|
||||
the fast-import input format is text (ASCII) based. This text based
|
||||
|
|
@ -1131,7 +1131,7 @@ If the `--done` command-line option or `feature done` command is
|
|||
in use, the `done` command is mandatory and marks the end of the
|
||||
stream.
|
||||
|
||||
Responses To Commands
|
||||
RESPONSES TO COMMANDS
|
||||
---------------------
|
||||
New objects written by fast-import are not available immediately.
|
||||
Most fast-import commands have no visible effect until the next
|
||||
|
|
@ -1160,7 +1160,7 @@ To avoid deadlock, such frontends must completely consume any
|
|||
pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before
|
||||
performing writes to fast-import that might block.
|
||||
|
||||
Crash Reports
|
||||
CRASH REPORTS
|
||||
-------------
|
||||
If fast-import is supplied invalid input it will terminate with a
|
||||
non-zero exit status and create a crash report in the top level of
|
||||
|
|
@ -1247,7 +1247,7 @@ An example crash:
|
|||
END OF CRASH REPORT
|
||||
====
|
||||
|
||||
Tips and Tricks
|
||||
TIPS AND TRICKS
|
||||
---------------
|
||||
The following tips and tricks have been collected from various
|
||||
users of fast-import, and are offered here as suggestions.
|
||||
|
|
@ -1349,7 +1349,7 @@ Your users will feel better knowing how much of the data stream
|
|||
has been processed.
|
||||
|
||||
|
||||
Packfile Optimization
|
||||
PACKFILE OPTIMIZATION
|
||||
---------------------
|
||||
When packing a blob fast-import always attempts to deltify against the last
|
||||
blob written. Unless specifically arranged for by the frontend,
|
||||
|
|
@ -1380,7 +1380,7 @@ to force recomputation of all deltas can significantly reduce the
|
|||
final packfile size (30-50% smaller can be quite typical).
|
||||
|
||||
|
||||
Memory Utilization
|
||||
MEMORY UTILIZATION
|
||||
------------------
|
||||
There are a number of factors which affect how much memory fast-import
|
||||
requires to perform an import. Like critical sections of core
|
||||
|
|
@ -1458,7 +1458,7 @@ and lazy loading of subtrees, allows fast-import to efficiently import
|
|||
projects with 2,000+ branches and 45,114+ files in a very limited
|
||||
memory footprint (less than 2.7 MiB per active branch).
|
||||
|
||||
Signals
|
||||
SIGNALS
|
||||
-------
|
||||
Sending *SIGUSR1* to the 'git fast-import' process ends the current
|
||||
packfile early, simulating a `checkpoint` command. The impatient
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ rewrite, the exit status is `2`. On any other error, the exit status may be
|
|||
any other non-zero value.
|
||||
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Suppose you want to remove a file (containing confidential information
|
||||
|
|
@ -406,7 +406,7 @@ git filter-branch --index-filter \
|
|||
|
||||
|
||||
|
||||
Checklist for Shrinking a Repository
|
||||
CHECKLIST FOR SHRINKING A REPOSITORY
|
||||
------------------------------------
|
||||
|
||||
git-filter-branch can be used to get rid of a subset of files,
|
||||
|
|
@ -445,7 +445,7 @@ warned.
|
|||
(or if your git-gc is not new enough to support arguments to
|
||||
`--prune`, use `git repack -ad; git prune` instead).
|
||||
|
||||
Notes
|
||||
NOTES
|
||||
-----
|
||||
|
||||
git-filter-branch allows you to make complex shell-scripted rewrites
|
||||
|
|
|
|||
|
|
@ -57,8 +57,8 @@ merge.summary::
|
|||
Synonym to `merge.log`; this is deprecated and will be removed in
|
||||
the future.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
---------
|
||||
$ git fetch origin master
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ be performed as well.
|
|||
Force `git gc` to run even if there may be another `git gc`
|
||||
instance running on this repository.
|
||||
|
||||
Configuration
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
The optional configuration variable `gc.reflogExpire` can be
|
||||
|
|
@ -144,7 +144,7 @@ old a stale working tree should be before `git worktree prune` deletes
|
|||
it. Default is "3 months ago".
|
||||
|
||||
|
||||
Notes
|
||||
NOTES
|
||||
-----
|
||||
|
||||
'git gc' tries very hard not to delete objects that are referenced
|
||||
|
|
|
|||
|
|
@ -293,7 +293,7 @@ providing this option will cause it to die.
|
|||
For more details about the <pathspec> syntax, see the 'pathspec' entry
|
||||
in linkgit:gitglossary[7].
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
`git grep 'time_t' -- '*.[ch]'`::
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ OPTIONS
|
|||
The remote refs to update.
|
||||
|
||||
|
||||
Specifying the Refs
|
||||
SPECIFYING THE REFS
|
||||
-------------------
|
||||
|
||||
A '<ref>' specification can be either a single pattern, or a pair
|
||||
|
|
|
|||
|
|
@ -136,8 +136,8 @@ Using direct mode with SSL:
|
|||
.........................
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig
|
||||
to specify your account settings:
|
||||
|
||||
|
|
|
|||
|
|
@ -93,8 +93,8 @@ OPTIONS
|
|||
--max-input-size=<size>::
|
||||
Die, if the pack is larger than <size>.
|
||||
|
||||
Note
|
||||
----
|
||||
NOTES
|
||||
-----
|
||||
|
||||
Once the index has been created, the list of object names is sorted
|
||||
and the SHA-1 hash of that list is printed to stdout. If --stdin was
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ followed by the ("attr/<eolattr>").
|
|||
Files to show. If no files are given all files which match the other
|
||||
specified criteria are shown.
|
||||
|
||||
Output
|
||||
OUTPUT
|
||||
------
|
||||
'git ls-files' just outputs the filenames unless `--stage` is specified in
|
||||
which case it outputs:
|
||||
|
|
@ -208,7 +208,7 @@ quoted as explained for the configuration variable `core.quotePath`
|
|||
verbatim and the line is terminated by a NUL byte.
|
||||
|
||||
|
||||
Exclude Patterns
|
||||
EXCLUDE PATTERNS
|
||||
----------------
|
||||
|
||||
'git ls-files' can use a list of "exclude patterns" when
|
||||
|
|
|
|||
|
|
@ -61,8 +61,8 @@ OPTIONS
|
|||
--always::
|
||||
Show uniquely abbreviated commit object as fallback.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Given a commit, find out where it is relative to the local refs. Say somebody
|
||||
wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
|
||||
|
|
|
|||
|
|
@ -29,8 +29,8 @@ Submit Git changes back to p4 using 'git p4 submit'. The command
|
|||
the updated p4 remote branch.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
* Clone a repository:
|
||||
+
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -56,8 +56,8 @@ OPTIONS
|
|||
reachable from any of our references, keep objects
|
||||
reachable from listed <head>s.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
To prune objects not used by your repository or another that
|
||||
borrows from your repository via its
|
||||
|
|
@ -67,7 +67,7 @@ borrows from your repository via its
|
|||
$ git prune $(cd ../another && git rev-parse --all)
|
||||
------------
|
||||
|
||||
Notes
|
||||
NOTES
|
||||
-----
|
||||
|
||||
In most cases, users will not need to call 'git prune' directly, but
|
||||
|
|
|
|||
|
|
@ -423,7 +423,7 @@ reason::
|
|||
refs, no explanation is needed. For a failed ref, the reason for
|
||||
failure is described.
|
||||
|
||||
Note about fast-forwards
|
||||
NOTE ABOUT FAST-FORWARDS
|
||||
------------------------
|
||||
|
||||
When an update changes a branch (or more in general, a ref) that used to
|
||||
|
|
@ -510,7 +510,7 @@ overwrite it. In other words, "git push --force" is a method reserved for
|
|||
a case where you do mean to lose history.
|
||||
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
`git push`::
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ OPTIONS
|
|||
The id of the tree object(s) to be read/merged.
|
||||
|
||||
|
||||
Merging
|
||||
MERGING
|
||||
-------
|
||||
If `-m` is specified, 'git read-tree' can perform 3 kinds of
|
||||
merge, a single tree merge if only 1 tree is given, a
|
||||
|
|
@ -382,7 +382,7 @@ middle of doing, and when your working tree is ready (i.e. you
|
|||
have finished your work-in-progress), attempt the merge again.
|
||||
|
||||
|
||||
Sparse checkout
|
||||
SPARSE CHECKOUT
|
||||
---------------
|
||||
|
||||
"Sparse checkout" allows populating the working directory sparsely.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ OPTIONS
|
|||
<directory>::
|
||||
The repository to sync into.
|
||||
|
||||
pre-receive Hook
|
||||
PRE-RECEIVE HOOK
|
||||
----------------
|
||||
Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
|
||||
and is executable, it will be invoked once with no parameters. The
|
||||
|
|
@ -116,7 +116,7 @@ bail out if the update is not to be supported.
|
|||
|
||||
See the notes on the quarantine environment below.
|
||||
|
||||
update Hook
|
||||
UPDATE HOOK
|
||||
-----------
|
||||
Before each ref is updated, if $GIT_DIR/hooks/update file exists
|
||||
and is executable, it is invoked once per ref, with three parameters:
|
||||
|
|
@ -138,7 +138,7 @@ ensure the ref will actually be updated, it is only a prerequisite.
|
|||
As such it is not a good idea to send notices (e.g. email) from
|
||||
this hook. Consider using the post-receive hook instead.
|
||||
|
||||
post-receive Hook
|
||||
POST-RECEIVE HOOK
|
||||
-----------------
|
||||
After all refs were updated (or attempted to be updated), if any
|
||||
ref update was successful, and if $GIT_DIR/hooks/post-receive
|
||||
|
|
@ -198,7 +198,7 @@ after it was updated by 'git-receive-pack', but before the hook was able
|
|||
to evaluate it. It is recommended that hooks rely on sha1-new
|
||||
rather than the current value of refname.
|
||||
|
||||
post-update Hook
|
||||
POST-UPDATE HOOK
|
||||
----------------
|
||||
After all other processing, if at least one ref was updated, and
|
||||
if $GIT_DIR/hooks/post-update file exists and is executable, then
|
||||
|
|
@ -216,7 +216,7 @@ if the repository is packed and is served via a dumb transport.
|
|||
exec git update-server-info
|
||||
|
||||
|
||||
Quarantine Environment
|
||||
QUARANTINE ENVIRONMENT
|
||||
----------------------
|
||||
|
||||
When `receive-pack` takes in objects, they are placed into a temporary
|
||||
|
|
|
|||
|
|
@ -55,14 +55,14 @@ some tunnel.
|
|||
the vhost field in the git:// service request (to rest of the argument).
|
||||
Default is not to send vhost in such request (if sent).
|
||||
|
||||
ENVIRONMENT VARIABLES:
|
||||
----------------------
|
||||
ENVIRONMENT VARIABLES
|
||||
---------------------
|
||||
|
||||
GIT_TRANSLOOP_DEBUG::
|
||||
If set, prints debugging information about various reads/writes.
|
||||
|
||||
ENVIRONMENT VARIABLES PASSED TO COMMAND:
|
||||
----------------------------------------
|
||||
ENVIRONMENT VARIABLES PASSED TO COMMAND
|
||||
---------------------------------------
|
||||
|
||||
GIT_EXT_SERVICE::
|
||||
Set to long name (git-upload-pack, etc...) of service helper needs
|
||||
|
|
@ -73,8 +73,8 @@ GIT_EXT_SERVICE_NOPREFIX::
|
|||
to invoke.
|
||||
|
||||
|
||||
EXAMPLES:
|
||||
---------
|
||||
EXAMPLES
|
||||
--------
|
||||
This remote helper is transparently used by Git when
|
||||
you use commands such as "git fetch <URL>", "git clone <URL>",
|
||||
, "git push <URL>" or "git remote add <nick> <URL>", where <URL>
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ The remote configuration is achieved using the `remote.origin.url` and
|
|||
`remote.origin.fetch` configuration variables. (See
|
||||
linkgit:git-config[1]).
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
* Add a new remote, fetch, and check out a branch from it
|
||||
|
|
|
|||
|
|
@ -46,8 +46,8 @@ ref that is different from the ref you have locally, you can use the
|
|||
its remote name.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Imagine that you built your work on your `master` branch on top of
|
||||
the `v1.0` release, and want it to be integrated to the project.
|
||||
|
|
|
|||
|
|
@ -458,8 +458,8 @@ sendemail.confirm::
|
|||
one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm`
|
||||
in the previous section for the meaning of these values.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
Use gmail as the smtp server
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
To use 'git send-email' to send your patches through the GMail SMTP server,
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ be in a separate packet, and the list must end with a flush packet.
|
|||
The remote refs to update.
|
||||
|
||||
|
||||
Specifying the Refs
|
||||
SPECIFYING THE REFS
|
||||
-------------------
|
||||
|
||||
There are three ways to specify which refs to update on the
|
||||
|
|
|
|||
|
|
@ -62,8 +62,8 @@ permissions.
|
|||
If a `no-interactive-login` command exists, then it is run and the
|
||||
interactive shell is aborted.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
To disable interactive logins, displaying a greeting instead:
|
||||
|
||||
|
|
|
|||
|
|
@ -173,8 +173,8 @@ The "fixes" branch adds one commit "Introduce "reset type" flag to
|
|||
The current branch is "master".
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
If you keep your primary branches immediately under
|
||||
`refs/heads`, and topic branches in subdirectories of
|
||||
|
|
|
|||
|
|
@ -120,8 +120,8 @@ $ git show-ref --heads --hash
|
|||
...
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
To show all references called "master", whether tags or heads or anything
|
||||
else, and regardless of how deep in the reference naming hierarchy they are,
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ EXAMPLES
|
|||
Concatenates the contents of said Makefiles in the head
|
||||
of the branch `master`.
|
||||
|
||||
Discussion
|
||||
DISCUSSION
|
||||
----------
|
||||
|
||||
include::i18n.txt[]
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ will remove the intended effect of the option.
|
|||
cleaner names.
|
||||
The same applies to directories ending '/' and paths with '//'
|
||||
|
||||
Using --refresh
|
||||
USING --REFRESH
|
||||
---------------
|
||||
`--refresh` does not calculate a new sha1 file or bring the index
|
||||
up to date for mode/content changes. But what it *does* do is to
|
||||
|
|
@ -239,7 +239,7 @@ the stat entry is out of date.
|
|||
For example, you'd want to do this after doing a 'git read-tree', to link
|
||||
up the stat index details with the proper files.
|
||||
|
||||
Using --cacheinfo or --info-only
|
||||
USING --CACHEINFO OR --INFO-ONLY
|
||||
--------------------------------
|
||||
`--cacheinfo` is used to register a file that is not in the
|
||||
current working directory. This is useful for minimum-checkout
|
||||
|
|
@ -261,7 +261,7 @@ useful when the file is available, but you do not wish to update the
|
|||
object database.
|
||||
|
||||
|
||||
Using --index-info
|
||||
USING --INDEX-INFO
|
||||
------------------
|
||||
|
||||
`--index-info` is a more powerful mechanism that lets you feed
|
||||
|
|
@ -317,7 +317,7 @@ $ git ls-files -s
|
|||
------------
|
||||
|
||||
|
||||
Using ``assume unchanged'' bit
|
||||
USING ``ASSUME UNCHANGED'' BIT
|
||||
------------------------------
|
||||
|
||||
Many operations in Git depend on your filesystem to have an
|
||||
|
|
@ -350,7 +350,7 @@ the index (use `git update-index --really-refresh` if you want
|
|||
to mark them as "assume unchanged").
|
||||
|
||||
|
||||
Examples
|
||||
EXAMPLES
|
||||
--------
|
||||
To update and refresh only the files already checked out:
|
||||
|
||||
|
|
@ -387,7 +387,7 @@ M foo.c
|
|||
<9> now it checks with lstat(2) and finds it has been changed.
|
||||
|
||||
|
||||
Skip-worktree bit
|
||||
SKIP-WORKTREE BIT
|
||||
-----------------
|
||||
|
||||
Skip-worktree bit can be defined in one (long) sentence: When reading
|
||||
|
|
@ -407,7 +407,7 @@ Although this bit looks similar to assume-unchanged bit, its goal is
|
|||
different from assume-unchanged bit's. Skip-worktree also takes
|
||||
precedence over assume-unchanged bit when both are set.
|
||||
|
||||
Split index
|
||||
SPLIT INDEX
|
||||
-----------
|
||||
|
||||
This mode is designed for repositories with very large indexes, and
|
||||
|
|
@ -432,7 +432,7 @@ To avoid deleting a shared index file that is still used, its
|
|||
modification time is updated to the current time everytime a new split
|
||||
index based on the shared index file is either created or read from.
|
||||
|
||||
Untracked cache
|
||||
UNTRACKED CACHE
|
||||
---------------
|
||||
|
||||
This cache is meant to speed up commands that involve determining
|
||||
|
|
@ -490,7 +490,7 @@ As with the bug described above the solution is to one-off do a "git
|
|||
status" run with `core.untrackedCache=false` to flush out the leftover
|
||||
bad data.
|
||||
|
||||
File System Monitor
|
||||
FILE SYSTEM MONITOR
|
||||
-------------------
|
||||
|
||||
This feature is intended to speed up git operations for repos that have
|
||||
|
|
@ -518,7 +518,7 @@ file system monitor is added to or removed from the index the next time
|
|||
a command reads the index. When `--[no-]fsmonitor` are used, the file
|
||||
system monitor is immediately added to or removed from the index.
|
||||
|
||||
Configuration
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
The command honors `core.filemode` configuration variable. If
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ modifications are performed. Note that while each individual
|
|||
<ref> is updated or deleted atomically, a concurrent reader may
|
||||
still see a subset of the modifications.
|
||||
|
||||
Logging Updates
|
||||
LOGGING UPDATES
|
||||
---------------
|
||||
If config parameter "core.logAllRefUpdates" is true and the ref is one under
|
||||
"refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or
|
||||
|
|
|
|||
|
|
@ -23,14 +23,14 @@ OPTIONS
|
|||
as well. (However, the configuration variables listing functionality
|
||||
is deprecated in favor of `git config -l`.)
|
||||
|
||||
EXAMPLE
|
||||
EXAMPLES
|
||||
--------
|
||||
$ git var GIT_AUTHOR_IDENT
|
||||
Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
|
||||
|
||||
|
||||
VARIABLES
|
||||
----------
|
||||
---------
|
||||
GIT_AUTHOR_IDENT::
|
||||
The author of a piece of code.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ variable exists then 'git web{litdd}browse' will treat the specified tool
|
|||
as a custom command and will use a shell eval to run the command with
|
||||
the URLs passed as arguments.
|
||||
|
||||
Note about konqueror
|
||||
NOTE ABOUT KONQUEROR
|
||||
--------------------
|
||||
|
||||
When 'konqueror' is specified by a command-line option or a
|
||||
|
|
|
|||
|
|
@ -1141,8 +1141,8 @@ to:
|
|||
------------
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
If you have these three `gitattributes` file:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user