<p><em>git-count-objects</em> [-v]</p>

<h2>OPTIONS</h2>

<div class="sectionbody">

-v

In addition to the number of loose objects and disk

space consumed, it reports the number of in-pack

objects, and number of objects that can be removed by

running <tt>git-prune-packed</tt>.

Last updated 04-May-2006 08:01:36 UTC

'git-count-objects' [-v]

OPTIONS

-------

-v::

In addition to the number of loose objects and disk

space consumed, it reports the number of in-pack

objects, and number of objects that can be removed by

running `git-prune-packed`.

all lines matching the key (and optionally the value_regex).

--get-regexp

Like --get-all, but interprets the name as a regular expression.

core.preferSymlinkRefs

Instead of the default "symref" format for HEAD

and other symbolic reference files, use symbolic links.

This is sometimes needed to work with old scripts that

expect HEAD to be a symbolic link.

Last updated 04-May-2006 08:01:37 UTC

all lines matching the key (and optionally the value_regex).

--get-regexp::

Like --get-all, but interprets the name as a regular expression.

<meta name="generator" content="AsciiDoc 7.0.2" />

<a id="ref_bare_repository"></a>bare repository

A <a href="#ref_bare_repository">bare repository</a> is normally an appropriately

named <a href="#ref_directory">directory</a> with a <tt>.git</tt> suffix that does not

have a locally checked-out copy of any of the files under

<a href="#ref_revision">revision</a> control. That is, all of the <tt>git</tt>

administrative and control files that would normally be present in the

hidden <tt>.git</tt> sub-<a href="#ref_directory">directory</a> are directly present in

the <tt><a href="#ref_repository">repository</a>.git</tt> <a href="#ref_directory">directory</a>

instead, and no other files are present and checked out. Usually

publishers of public repositories make bare repositories available.

<a id="ref_cherry-picking"></a>cherry-picking

In <a href="#ref_SCM">SCM</a> jargon, "cherry pick" means to choose a subset of

changes out of a series of changes (typically commits) and record them

as a new series of changes on top of different codebase. In GIT, this is

performed by "git cherry-pick" command to extract the change introduced

by an existing <a href="#ref_commit">commit</a> and to record it based on the tip

of the current <a href="#ref_branch">branch</a> as a new <a href="#ref_commit">commit</a>.

<a href="#ref_head">head</a>. Also see "<a href="#ref_dirty">dirty</a>".

<a id="ref_fast_forward"></a>fast forward

A fast-forward is a special type of <a href="#ref_merge">merge</a> where you have a

<a href="#ref_revision">revision</a> and you are "merging" another

<a href="#ref_branch">branch</a>'s changes that happen to be a descendant of what

you have. In such these cases, you do not make a new <a href="#ref_merge">merge</a>

<a href="#ref_commit">commit</a> but instead just update to his

<a href="#ref_revision">revision</a>. This will happen frequently on a

<a href="#ref_tracking_branch">tracking branch</a> of a remote

<a href="#ref_repository">repository</a>.

<a id="ref_hook"></a>hook

During the normal execution of several git commands, call-outs are made

to optional scripts that allow a developer to add functionality or

checking. Typically, the hooks allow for a command to be pre-verified

and potentially aborted, and allow for a post-notification after the

operation is done. The <a href="#ref_hook">hook</a> scripts are found in the

<tt>$GIT_DIR/hooks/</tt> <a href="#ref_directory">directory</a>, and are enabled by simply

making them executable.

The default development <a href="#ref_branch">branch</a>. Whenever you create a git

development, though that is purely conventional and not required.

The default upstream <a href="#ref_tracking_branch">tracking branch</a>. Most

projects have at least one upstream project which they track. By default

<em><a href="#ref_origin">origin</a></em> is used for that purpose. New upstream updates

will be fetched into this <a href="#ref_branch">branch</a>; you should never

<a href="#ref_commit">commit</a> to it yourself.

<a id="ref_pickaxe"></a>pickaxe

The term <a href="#ref_pickaxe">pickaxe</a> refers to an option to the diffcore

routines that help select changes that add or delete a given text

string. With the &#8212;<a href="#ref_pickaxe">pickaxe</a>-all option, it can be used to

view the full <a href="#ref_changeset">changeset</a> that introduced or removed,

say, a particular line of text. See <a href="git-diff.html">git-diff(1)</a>.

A 40-byte hex representation of a <a href="#ref_SHA1">SHA1</a> or a name that

denotes a particular <a href="#ref_object">object</a>. These may be stored in

<a id="ref_refspec"></a>refspec

A <a href="#ref_refspec">refspec</a> is used by <a href="#ref_fetch">fetch</a> and

<a href="#ref_push">push</a> to describe the mapping between remote <a href="#ref_ref">ref</a>

and local <a href="#ref_ref">ref</a>. They are combined with a colon in the format

&lt;src&gt;:&lt;dst&gt;, preceded by an optional plus sign, +. For example: <tt>git

<a href="#ref_fetch">fetch</a> $URL

refs/heads/<a href="#ref_master">master</a>:refs/heads/<a href="#ref_origin">origin</a></tt> means

"grab the <a href="#ref_master">master</a> <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>

from the $URL and store it as my <a href="#ref_origin">origin</a>

<a href="#ref_branch">branch</a> <a href="#ref_head">head</a>". And <tt>git <a href="#ref_push">push</a>

$URL refs/heads/<a href="#ref_master">master</a>:refs/heads/to-upstream</tt> means

"publish my <a href="#ref_master">master</a> <a href="#ref_branch">branch</a>

<a href="#ref_head">head</a> as to-upstream <a href="#ref_master">master</a> <a href="#ref_head">head</a>

at $URL". See also <a href="git-push.html">git-push(1)</a>

<a id="ref_topic_branch"></a>topic branch

A regular git <a href="#ref_branch">branch</a> that is used by a developer to

identify a conceptual line of development. Since branches are very easy

and inexpensive, it is often desirable to have several small branches

that each contain very well defined concepts or small incremental yet

related changes.

<a id="ref_tracking_branch"></a>tracking branch

A regular git <a href="#ref_branch">branch</a> that is used to follow changes from

another <a href="#ref_repository">repository</a>. A <a href="#ref_tracking_branch">tracking branch</a> should not contain direct modifications or have local commits

made to it. A <a href="#ref_tracking_branch">tracking branch</a> can usually be

identified as the right-hand-side <a href="#ref_ref">ref</a> in a Pull:

<a href="#ref_refspec">refspec</a>.

Last updated 04-May-2006 08:01:37 UTC