![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 1befca98d49583b42e652b4ce21fccb89b5b5cdb..5c891f1169b35e53bccc19f0423b5b7e98db720b 100644 (file)
directory for a repository associated with your working tree, or
`<project>.git` directory for a public 'bare' repository. It is
also possible to have a working tree where `.git` is a plain
-ascii file containing `gitdir: <path>`, i.e. the path to the
+ASCII file containing `gitdir: <path>`, i.e. the path to the
real git repository).
objects::
Object store associated with this repository. Usually
an object store is self sufficient (i.e. all the objects
that are referred to by an object found in it are also
- found in it), but there are couple of ways to violate
- it.
+ found in it), but there are a few ways to violate it.
+
-. You could populate the repository by running a commit walker
-without `-a` option. Depending on which options are given, you
-could have only commit objects without associated blobs and
-trees this way, for example. A repository with this kind of
-incomplete object store is not suitable to be published to the
-outside world but sometimes useful for private repository.
-. You also could have an incomplete but locally usable repository
-by cloning shallowly. See linkgit:git-clone[1].
-. You can be using `objects/info/alternates` mechanism, or
-`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
+. You could have an incomplete but locally usable repository
+by creating a shallow clone. See linkgit:git-clone[1].
+. You could be using the `objects/info/alternates` or
+`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
objects from other object stores. A repository with this kind
of incomplete object store is not suitable to be published for
use with dumb transports but otherwise is OK as long as
-`objects/info/alternates` points at the right object stores
-it borrows from.
+`objects/info/alternates` points at the object stores it
+borrows from.
objects/[0-9a-f][0-9a-f]::
- Traditionally, each object is stored in its own file.
- They are split into 256 subdirectories using the first
- two letters from its object name to keep the number of
- directory entries `objects` directory itself needs to
- hold. Objects found here are often called 'unpacked'
- (or 'loose') objects.
+ A newly created object is stored in its own file.
+ The objects are splayed over 256 subdirectories using
+ the first two characters of the sha1 object name to
+ keep the number of directory entries in `objects`
+ itself to a manageable number. Objects found
+ here are often called 'unpacked' (or 'loose') objects.
objects/pack::
Packs (files that store many object in compressed form,
are available in this object store. Whenever a pack is
added or removed, `git update-server-info` should be run
to keep this file up-to-date if the repository is
- published for dumb transports. 'git-repack' does this
+ published for dumb transports. 'git repack' does this
by default.
objects/info/alternates::
refs::
References are stored in subdirectories of this
- directory. The 'git-prune' command knows to keep
+ directory. The 'git prune' command knows to preserve
objects reachable from refs found in this directory and
its subdirectories.
+
HEAD can also record a specific commit directly, instead of
being a symref to point at the current branch. Such a state
-is often called 'detached HEAD', and almost all commands work
-identically as normal. See linkgit:git-checkout[1] for
-details.
+is often called 'detached HEAD.' See linkgit:git-checkout[1]
+for details.
branches::
A slightly deprecated way to store shorthands to be used
- to specify URL to 'git-fetch', 'git-pull' and 'git-push'
- commands is to store a file in `branches/<name>` and
- give 'name' to these commands in place of 'repository'
- argument.
+ to specify a URL to 'git fetch', 'git pull' and 'git push'.
+ A file can be stored as `branches/<name>` and then
+ 'name' can be given to these commands in place of
+ 'repository' argument. See the REMOTES section in
+ linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories.
hooks::
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
- 'git-init' is run, but all of them are disabled by
+ 'git init' is run, but all of them are disabled by
default. To enable, the `.sample` suffix has to be
removed from the filename by renaming.
Read linkgit:githooks[5] for more details about
This file helps dumb transports discover what refs are
available in this repository. If the repository is
published for dumb transports, this file should be
- regenerated by 'git-update-server-info' every time a tag
+ regenerated by 'git update-server-info' every time a tag
or branch is created or modified. This is normally done
from the `hooks/update` hook, which is run by the
- 'git-receive-pack' command when you 'git-push' into the
+ 'git-receive-pack' command when you 'git push' into the
repository.
info/grafts::
info/exclude::
This file, by convention among Porcelains, stores the
exclude pattern list. `.gitignore` is the per-directory
- ignore file. 'git-status', 'git-add', 'git-rm' and
- 'git-clean' look at it but the core git commands do not look
+ ignore file. 'git status', 'git add', 'git rm' and
+ 'git clean' look at it but the core git commands do not look
at it. See also: linkgit:gitignore[5].
remotes::
- Stores shorthands to be used to give URL and default
- refnames to interact with remote repository to
- 'git-fetch', 'git-pull' and 'git-push' commands.
+ Stores shorthands for URL and default refnames for use
+ when interacting with remote repositories via 'git fetch',
+ 'git pull' and 'git push' commands. See the REMOTES section
+ in linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories.
logs::
Records of changes made to refs are stored in this