![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 46e56e8)
raw | patch | inline | side by side (parent: 46e56e8)
| author | Jonathan Nieder <jrnieder@uchicago.edu> | |
| Mon, 30 Jun 2008 06:09:04 +0000 (01:09 -0500) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Wed, 2 Jul 2008 00:20:15 +0000 (17:20 -0700) |
Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
131 files changed:
index 2b0ccb3c93db565d8c102aa784449186190a000f..011a7436529f50e8b128f19d30bbeb0bdc82375b 100644 (file)
SYNOPSIS
--------
[verse]
-'git-add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--update | -u] [--refresh] [--ignore-errors] [--]
<filepattern>...
index 46544a07694a90db908729b6badf92370f37226b..1296b91172054bef9cda3fe11824b360d4446220 100644 (file)
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
SYNOPSIS
--------
[verse]
-'git-am' [--signoff] [--keep] [--utf8 | --no-utf8]
+'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
<mbox>|<Maildir>...
-'git-am' [--skip | --resolved]
+'git am' [--skip | --resolved]
DESCRIPTION
-----------
index da15379ae53046b2c6384e505c9e28595171fa66..d05ec197b549e6956041c246321de494c685a265 100644 (file)
SYNOPSIS
--------
-git-annotate [options] file [revision]
+git annotate [options] file [revision]
DESCRIPTION
-----------
index c5ee636fa94e6d60dacf99a383ec868c1d7a82bd..138f735fd3d9d21a1f10fa014853e545cb07c03b 100644 (file)
SYNOPSIS
--------
[verse]
-'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
+'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
[--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
index 603117c796619ba9c1ed93ae0646bd242cbd37b2..ffd01ae5496e8052e6aacb0ad827116f6e9ca32b 100644 (file)
SYNOPSIS
--------
[verse]
-'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
<archive/branch>[:<git-branch>] ...
DESCRIPTION
index 9b5f3ae5ed8cf6b79545f09d68797490c69f6596..1b0d7829f0de0776148400632f39d47dd9d19a43 100644 (file)
SYNOPSIS
--------
[verse]
-'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
+'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
index 3ca0d330ad06e76d73657189c5f90e0994ba4505..fdb040b07fdfaec2a739c9a843435d4728f71632 100644 (file)
git bisect log
git bisect run <cmd>...
-This command uses 'git-rev-list --bisect' option to help drive the
+This command uses 'git rev-list --bisect' option to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
index 8f4fb46685624d07f5940eb973a7fd03aefb5aa0..738249a97ed42baa0c9fbec39f45dcb2583d0fd6 100644 (file)
SYNOPSIS
--------
[verse]
-'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
+'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
index 0fd58083eb2afdb7fed7ebf01bab3b5e1cae1421..dce8c45ce92d513409094cf3084efe8466ae44d5 100644 (file)
SYNOPSIS
--------
[verse]
-'git-branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
+'git branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
[-v [--abbrev=<length> | --no-abbrev]]
[--contains <commit>]
-'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
-'git-branch' (-m | -M) [<oldbranch>] <newbranch>
-'git-branch' (-d | -D) [-r] <branchname>...
+'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git branch' (-m | -M) [<oldbranch>] <newbranch>
+'git branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
index f6a06129abfbd79a9cbb2b7d8f2d5902923ef594..9b1b13dbb64bbdd8d6593dc86da7403120ff95bd 100644 (file)
SYNOPSIS
--------
[verse]
-'git-bundle' create <file> <git-rev-list args>
-'git-bundle' verify <file>
-'git-bundle' list-heads <file> [refname...]
-'git-bundle' unbundle <file> [refname...]
+'git bundle' create <file> <git-rev-list args>
+'git bundle' verify <file>
+'git bundle' list-heads <file> [refname...]
+'git bundle' unbundle <file> [refname...]
DESCRIPTION
-----------
and move it afterwards to help build the bundle.
------------
-$ git-bundle create mybundle master ^lastR2bundle
+$ git bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
------------
Then you move mybundle from A to B, and in R2 on B:
------------
-$ git-bundle verify mybundle
-$ git-fetch mybundle master:localRef
+$ git bundle verify mybundle
+$ git fetch mybundle master:localRef
------------
With something like this in the config in R2:
index f58013ca605631437e5a4806cdd07dba18d8a982..d35e8a04fe28b095b5405ae2e0b09e3ab448bf63 100644 (file)
SYNOPSIS
--------
[verse]
-'git-cat-file' [-t | -s | -e | -p | <type>] <object>
-'git-cat-file' [--batch | --batch-check] < <list-of-objects>
+'git cat-file' [-t | -s | -e | -p | <type>] <object>
+'git cat-file' [--batch | --batch-check] < <list-of-objects>
DESCRIPTION
-----------
index ef16b93982f92dd0bc567a3c9bdeaa7703eeac3a..abe1f1b7ddb4e47ac6c9ba327cb6f2c7e2b5fc9e 100644 (file)
SYNOPSIS
--------
-'git-check-attr' attr... [--] pathname...
+'git check-attr' attr... [--] pathname...
DESCRIPTION
-----------
index c560c0aa6de5d01de7e954b10e3e170b94641d5b..12cdfcd37679fb66ed7e9b0c950e172db90af868 100644 (file)
SYNOPSIS
--------
-'git-check-ref-format' <refname>
+'git check-ref-format' <refname>
DESCRIPTION
-----------
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
- linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
+ linkgit:git-cat-file[1] "git cat-file blob v1.3.3:refs.c".
GIT
index 676203b2ebcc1261dc5ad8d0ab8caa0bc730112c..daa6aee558cadebed1570c7c4efe36991010647f 100644 (file)
SYNOPSIS
--------
[verse]
-'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--stage=<number>|all]
[--temp]
[-z] [--stdin]
The order of the flags used to matter, but not anymore.
-Just doing `git-checkout-index` does nothing. You probably meant
-`git-checkout-index -a`. And if you want to force it, you want
-`git-checkout-index -f -a`.
+Just doing `git checkout-index` does nothing. You probably meant
+`git checkout-index -a`. And if you want to force it, you want
+`git checkout-index -f -a`.
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" behavior is that from scripts you are
supposed to be able to do:
----------------
-$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
----------------
which will force all existing `*.h` files to be replaced with their
since git-checkout-index accepts --stdin it would be faster to use:
----------------
-$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
+$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
----------------
The `--` is just a good idea when you know the rest will be filenames;
To update and refresh only the files already checked out::
+
----------------
-$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
Using `git-checkout-index` to "export an entire tree"::
Just read the desired tree into the index, and do:
+
----------------
-$ git-checkout-index --prefix=git-export-dir/ -a
+$ git checkout-index --prefix=git-export-dir/ -a
----------------
+
-`git-checkout-index` will "export" the index into the specified
+`git checkout-index` will "export" the index into the specified
directory.
+
The final "/" is important. The exported name is literally just
Export files with a prefix::
+
----------------
-$ git-checkout-index --prefix=.merged- Makefile
+$ git checkout-index --prefix=.merged- Makefile
----------------
+
This will check out the currently cached copy of `Makefile`
index 3ad9760a4d6949837c1e186402c9810b59a0138d..fd048ea62e11145593caadd2f7d4917971d20f8d 100644 (file)
SYNOPSIS
--------
[verse]
-'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
-'git-checkout' [<tree-ish>] <paths>...
+'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
+'git checkout' [<tree-ish>] <paths>...
DESCRIPTION
-----------
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
-the index file (i.e. it runs `git-checkout-index -f -u`), or
+the index file (i.e. it runs `git checkout-index -f -u`), or
from a named commit. In
this case, the `-f` and `-b` options are meaningless and giving
either of them results in an error. <tree-ish> argument can be
(`v2.6.18` in the above example).
You can use usual git commands while in this state. You can use
-`git-reset --hard $othercommit` to further move around, for
+`git reset --hard $othercommit` to further move around, for
example. You can make changes and create a new commit on top of
a detached HEAD. You can even create a merge by using `git
merge $othercommit`.
index 5ac9cfb0ef2e2eb26ebe5cce6a5c7ed54d4e39ec..197ef944ad2937908d3ce0c66a6f8d4ca46b8814 100644 (file)
SYNOPSIS
--------
-'git-cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
DESCRIPTION
-----------
index ef7caf61e1d344ea447b0b874063cabc0a83fdec..d63d33b88658209289c1c7a31fcbd5ed60a01260 100644 (file)
SYNOPSIS
--------
-'git-cherry' [-v] <upstream> [<head>] [<limit>]
+'git cherry' [-v] <upstream> [<head>] [<limit>]
DESCRIPTION
-----------
index 37a82ee4b8ed2dc939e56140821a42d452e1b4b5..f001f8f8daa20a59ad0888fb4d488f11d85b1774 100644 (file)
SYNOPSIS
--------
[verse]
-'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
+'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
DESCRIPTION
-----------
index 7973e6af4c2aa31ea9ae9b91b4c4cd5ee2256762..852b4785dada4f6e70049ec82757fc801b9b77c9 100644 (file)
SYNOPSIS
--------
[verse]
-'git-clone' [--template=<template_directory>]
+'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
index 728c2fae892f0a4a66e9fb1854a7e31f4a5f4917..620c45f735e17c652652e9424998f5db1e3f42a5 100644 (file)
SYNOPSIS
--------
-'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
+'git commit-tree' <tree> [-p <parent commit>]\* < changelog
DESCRIPTION
-----------
index 656d4db593ee5291e5fe8f74761754fd01e090d5..c351424b3fe534f0dbe62dd82ea2ea8633dcdb4f 100644 (file)
SYNOPSIS
--------
[verse]
-'git-commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
+'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
your working tree are temporarily stored to a staging area
called the "index" with linkgit:git-add[1]. A file can be
reverted back, only in the index but not in the working tree,
-to that of the last commit with `git-reset HEAD -- <file>`,
+to that of the last commit with `git reset HEAD -- <file>`,
which effectively reverts `git-add` and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
index c90421ee7f3b6a3fe1f08c4868b5652d4d7db569..d0a0d307985267bc2ea275279a0fe2971522fb71 100644 (file)
SYNOPSIS
--------
[verse]
-'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
-'git-config' [<file-option>] [type] --add name value
-'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
-'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
-'git-config' [<file-option>] --unset name [value_regex]
-'git-config' [<file-option>] --unset-all name [value_regex]
-'git-config' [<file-option>] --rename-section old_name new_name
-'git-config' [<file-option>] --remove-section name
-'git-config' [<file-option>] [-z|--null] -l | --list
-'git-config' [<file-option>] --get-color name [default]
-'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
+'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
+'git config' [<file-option>] [type] --add name value
+'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
+'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
+'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
+'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
+'git config' [<file-option>] --unset name [value_regex]
+'git config' [<file-option>] --unset-all name [value_regex]
+'git config' [<file-option>] --rename-section old_name new_name
+'git config' [<file-option>] --remove-section name
+'git config' [<file-option>] [-z|--null] -l | --list
+'git config' [<file-option>] --get-color name [default]
+'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
DESCRIPTION
-----------
index 1ba85a259a2d8896b5634f3496542b5561dbf2de..c069cc8b04a63084856b60814669457c95dac2db 100644 (file)
SYNOPSIS
--------
-'git-count-objects' [-v]
+'git count-objects' [-v]
DESCRIPTION
-----------
In addition to the number of loose objects and disk
space consumed, it reports the number of in-pack
objects, number of packs, and number of objects that can be
- removed by running `git-prune-packed`.
+ removed by running `git prune-packed`.
Author
index 5fa91e51ad70c3fed2bf3170bf14268f410aec5f..614c2e5e89d16db42123e6e921aa34f23a1d1409 100644 (file)
SYNOPSIS
--------
-'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
-$ git-cvsexportcommit -v <commit-sha1>
+$ git cvsexportcommit -v <commit-sha1>
$ cvs commit -F .msg <files>
------------
Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+
------------
- $ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
+ $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
@@ -104,7 +104,7 @@ Merge pending patches into CVS automatically -- only if you really know what you
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
-$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
+$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
------------
Author
index 2f9b35f6229143f566f31e1ef6de290572181608..7890851dedb0f07ebd35ed8375c5b06dc9328295 100644 (file)
SYNOPSIS
--------
[verse]
-'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
+'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
You should *never* do any work of your own on the branches that are
created by git-cvsimport. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to 'git merge' incremental imports, or
+to work with; after that, you need to 'git-merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
index 3310ae25ff75c302e6b9088a0807aee340ad69c7..2401516f011783b0fdcaba7dde02e6cad21de3c1 100644 (file)
Usage:
[verse]
-'git-cvsserver' [options] [pserver|server] [<directory> ...]
+'git cvsserver' [options] [pserver|server] [<directory> ...]
OPTIONS
-------
index b71eb94d54e4ca351a8664e84210e136559a2a2c..266458bed80ac15db2f6c6e083a8d496a0d9810f 100644 (file)
SYNOPSIS
--------
[verse]
-'git-daemon' [--verbose] [--syslog] [--export-all]
+'git daemon' [--verbose] [--syslog] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
[--interpolated-path=pathtemplate]
index 9f6f4831864a3112119bc7d7fec22aa7a72225e5..b6c86c2aeaa33cb2d72863dfdbaecc887ef1aa5b 100644 (file)
SYNOPSIS
--------
-'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
DESCRIPTION
-----------
With something like git.git current tree, I get:
- [torvalds@g5 git]$ git-describe parent
+ [torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
Doing a "git-describe" on a tag-name will just show the tag name:
- [torvalds@g5 git]$ git-describe v1.0.4
+ [torvalds@g5 git]$ git describe v1.0.4
v1.0.4
With --all, the command can use branch heads as references, so
SEARCH STRATEGY
---------------
-For each committish supplied "git describe" will first look for
+For each committish supplied "git-describe" will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
-If an exact match was not found "git describe" will walk back
+If an exact match was not found "git-describe" will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
abbreviation of the input committish's SHA1.
index 8a64869d2705071afe3d1a122b6b85a086413a0a..378f34964ca6813a67516f3943ce741df0f4132a 100644 (file)
SYNOPSIS
--------
-'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
+'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
DESCRIPTION
-----------
index f6e844fe61f66c02a448e7d8e48e9fecc6393bd0..2474745254540d8caf39448d86f752f25d41f2c4 100644 (file)
SYNOPSIS
--------
-'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
+'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
DESCRIPTION
-----------
*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
- git-diff-index --cached HEAD
+ git diff-index --cached HEAD
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an "git-update-index" to make that effective in the index file.
-"git-diff-files" wouldn't show anything at all, since the index file
+"git diff-files" wouldn't show anything at all, since the index file
matches my working directory. But doing a "git-diff-index" does:
- torvalds@ppc970:~/git> git-diff-index --cached HEAD
+ torvalds@ppc970:~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
You can see easily that the above is a rename.
-In fact, "git-diff-index --cached" *should* always be entirely equivalent to
+In fact, "git diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
have not actually done a "git-update-index" on it yet - there is no
"object" associated with the new state, and you get:
- torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
+ torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
index 56caeb2d26f2f8eab1234be6f146201ded5b098a..7d41a0f6cdd9e555db4c097f6ff477884fd797be 100644 (file)
SYNOPSIS
--------
[verse]
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--root] [<common diff options>]
<tree-ish> [<tree-ish>] [<path>...]
If you're only interested in differences in a subset of files, for
example some architecture-specific files, you might do:
- git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
+ git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
and it will only show you what changed in those two directories.
Or if you are searching for what changed in just `kernel/sched.c`, just do
- git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
+ git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
and it will ignore all differences to other files.
An example of normal usage is:
- torvalds@ppc970:~/git> git-diff-tree 5319e4......
+ torvalds@ppc970:~/git> git diff-tree 5319e4......
*100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
which tells you that the last commit changed just one file (it's from
index 7acd428964a9e6ffc4b876ce01731c1daf3a72bc..c53eba557d0a242a0d8553d9569ce8b2eb86331b 100644 (file)
SYNOPSIS
--------
-'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
+'git diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
Show changes between two trees, a tree and the working tree, a
tree and the index file, or the index file and the working tree.
-'git-diff' [--options] [--] [<path>...]::
+'git diff' [--options] [--] [<path>...]::
This form is to view the changes you made relative to
the index (staging area for the next commit). In other
compare the two files / directories. This behavior can be
forced by --no-index.
-'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
+'git diff' [--options] --cached [<commit>] [--] [<path>...]::
This form is to view the changes you staged for the next
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
-'git-diff' [--options] <commit> [--] [<path>...]::
+'git diff' [--options] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
branch name to compare with the tip of a different
branch.
-'git-diff' [--options] <commit> <commit> [--] [<path>...]::
+'git diff' [--options] <commit> <commit> [--] [<path>...]::
This is to view the changes between two arbitrary
<commit>.
-'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
+'git diff' [--options] <commit>..<commit> [--] [<path>...]::
This is synonymous to the previous form. If <commit> on
one side is omitted, it will have the same effect as
using HEAD instead.
-'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
+'git diff' [--options] <commit>\...<commit> [--] [<path>...]::
This form is to view the changes on the branch containing
and up to the second <commit>, starting at a common ancestor
- of both <commit>. "git-diff A\...B" is equivalent to
- "git-diff $(git-merge-base A B) B". You can omit any one
+ of both <commit>. "git diff A\...B" is equivalent to
+ "git diff $(git-merge-base A B) B". You can omit any one
of <commit>, which has the same effect as using HEAD instead.
Just in case if you are doing something exotic, it should be
index 277a547a026f69faa0d923ca8a9f191608de7294..b21cd77505124ee4f8784b52249e02ef66c253ef 100644 (file)
SYNOPSIS
--------
-'git-fast-export [options]' | 'git-fast-import'
+'git fast-export [options]' | 'git fast-import'
DESCRIPTION
-----------
index 395c055f9571bfe66edd335ca84ac2c515ad2b86..8881686fa77357a6bff9b38ea42e818e8a2a8b99 100644 (file)
SYNOPSIS
--------
-frontend | 'git-fast-import' [options]
+frontend | 'git fast-import' [options]
DESCRIPTION
-----------
------------------
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,
-or any other Git operation (including `git prune`, as loose objects
+or any other Git operation (including `git-prune`, as loose objects
are never used by fast-import).
fast-import does not lock the branch or tag refs it is actively importing.
remove the leading part of the line, for example:
====
- frontend | git-fast-import | sed 's/^progress //'
+ frontend | git fast-import | sed 's/^progress //'
====
Placing a `progress` command immediately after a `checkpoint` will
M 777 inline bob
END_OF_INPUT
- $ git-fast-import <in
+ $ git fast-import <in
fatal: Corrupt mode: M 777 inline bob
fast-import: dumping crash report to .git/fast_import_crash_8434
index 282fcaf17fed50ac51129dde8fcf105c1b9c11d9..ff328abd2bce697b103f7313112d0e6394a0ad30 100644 (file)
SYNOPSIS
--------
-'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
+'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
index 489b2b17e69c0a0f6b2df0ce4b2da6f38f809546..e4b529710c414b0e5ab2836f8f8ffbf680ed78f5 100644 (file)
SYNOPSIS
--------
-'git-fetch' <options> <repository> <refspec>...
+'git fetch' <options> <repository> <refspec>...
DESCRIPTION
The ref names and their object names of fetched refs are stored
in `.git/FETCH_HEAD`. This information is left for a later merge
-operation done by "git merge".
+operation done by "git-merge".
When <refspec> stores the fetched result in tracking branches,
the tags that point at these branches are automatically
index ea77f1fce505fbb9c1691f7e75aa014e7a1d5be5..924afb28c381164877c079e9e1de33a523493d7f 100644 (file)
SYNOPSIS
--------
[verse]
-'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
+'git filter-branch' [--env-filter <command>] [--tree-filter <command>]
[--index-filter <command>] [--parent-filter <command>]
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--subdirectory-filter <directory>]
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
-point to the top-most revision that a 'git rev-list' of this range
+point to the top-most revision that a 'git-rev-list' of this range
will print.
*NOTE* the changes introduced by the commits, and which are not reverted
index 2a7cfb980b7f0b6fa2bd741b3601467f07025691..46d4a4acac713ebba26ea600e647161ee687a977 100644 (file)
SYNOPSIS
--------
[verse]
-git-fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
-git-fmt-merge-msg [--log | --no-log] -F <file>
+git fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
+git fmt-merge-msg [--log | --no-log] -F <file>
DESCRIPTION
-----------
index b347bfbb14784a4292124a4575086411a4697527..29c29f88302b5680f639d8ed007c2a2e4b08fdf9 100644 (file)
SYNOPSIS
--------
[verse]
-'git-for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
+'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
[--sort=<key>]\* [--format=<format>] [<pattern>...]
DESCRIPTION
------------
#!/bin/sh
-git-for-each-ref --count=3 --sort='-*authordate' \
+git for-each-ref --count=3 --sort='-*authordate' \
--format='From: %(*authorname) %(*authoremail)
Subject: %(*subject)
Date: %(*authordate)
------------
#!/bin/sh
-git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
while read entry
do
eval "$entry"
fi
'
-eval=`git-for-each-ref --shell --format="$fmt" \
+eval=`git for-each-ref --shell --format="$fmt" \
--sort='*objecttype' \
--sort=-taggerdate \
refs/tags`
index 4dafa39a9211d9d35498f4c88418713b1aa33284..ce1af821b7d43c757388f3d6b22df1d14703809b 100644 (file)
SYNOPSIS
--------
[verse]
-'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
+'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
[--attach[=<boundary>] | --inline[=<boundary>]]
[-s | --signoff] [<common diff options>]
[-n | --numbered | -N | --no-numbered]
index 6e9f717642e6db0caf6182ea49bbb60d2bc9583d..965a8279c1b17df6fbf82f4fbcadbd254049a7d5 100644 (file)
SYNOPSIS
--------
-'git-fsck-objects' ...
+'git fsck-objects' ...
DESCRIPTION
-----------
index 9846c859cf3f4c76525aae124e0ef516fa55779f..c26b40a31fb0c6710ae9f75d7db9f3f3a2540cad 100644 (file)
SYNOPSIS
--------
[verse]
-'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
So for example
- git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
+ git fsck --unreachable HEAD $(cat .git/refs/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
index 6ace615d807e3afe91800094e13797fc15d2bae4..587ce14512a1cd58a4b5aa80a4bab53b77a3c624 100644 (file)
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
SYNOPSIS
--------
-'git-gc' [--aggressive] [--auto] [--quiet]
+'git gc' [--aggressive] [--auto] [--quiet]
DESCRIPTION
-----------
few hundred changesets or so.
--auto::
- With this option, `git gc` checks whether any housekeeping is
+ With this option, `git-gc` checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
operations that could create many loose objects.
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
-`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
index c13bf98697e8e4aef236583f1dbcab21780b5013..5a047b08c9718f874db4c0cba35b1d9f391f4432 100644 (file)
SYNOPSIS
--------
-'git-get-tar-commit-id' < <tarfile>
+'git get-tar-commit-id' < <tarfile>
DESCRIPTION
index 1b646b73f069e72bc6faa3a058d61ace77c9934c..cbda116581cd638ae1cfda1218d37f1a2b446c73 100644 (file)
SYNOPSIS
--------
[verse]
-'git-grep' [--cached]
+'git grep' [--cached]
[-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
[-v | --invert-match] [-h|-H] [--full-name]
[-E | --extended-regexp] [-G | --basic-regexp]
index cf3dce8a4a77d480a719260b7c8549c16f7c8e17..ca232e08660d2120864fe9d7cd138321f169f937 100644 (file)
SYNOPSIS
--------
-'git-hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
+'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
DESCRIPTION
-----------
index 70fb635291876e20acbc75451c875dcecffa9056..e7c796155fdd0ad644decf5dc488c6d780a2d164 100644 (file)
SYNOPSIS
--------
-'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
+'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
DESCRIPTION
-----------
index d69b20549bf956a5c7c3f64f5315a17ec71af038..aef383e0b142bd603b77620cad720c102d70c4b7 100644 (file)
SYNOPSIS
--------
-'git-http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
+'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
DESCRIPTION
-----------
index f4fdc242839d52ea97a32780526b133655ef9762..27d3de973f88ccf8dc643c8b152aacf156234aa6 100644 (file)
SYNOPSIS
--------
-'git-imap-send'
+'git imap-send'
DESCRIPTION
Typical usage is something like:
-git-format-patch --signoff --stdout --attach origin | git-imap-send
+git format-patch --signoff --stdout --attach origin | git imap-send
CONFIGURATION
index 6409363ae5e80264b5b45d50bd9a0180ec68e05b..902056153efdafef4955591de3dd8b716c947ebe 100644 (file)
SYNOPSIS
--------
[verse]
-'git-index-pack' [-v] [-o <index-file>] <pack-file>
-'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+'git index-pack' [-v] [-o <index-file>] <pack-file>
+'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
[<pack-file>]
index 439cabb737a48e009ea0a3a4e5bb323c1b2ccca9..1fd0ff2610a1375bcf0defe2a234b2dee1a7997a 100644 (file)
SYNOPSIS
--------
-'git-init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
DESCRIPTION
index 792643c80916f4b72704f046c0de89d8d55fa17c..45244737fda157b81078574ae482ee4a478e9c43 100644 (file)
SYNOPSIS
--------
-'git-init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
+
----------------
$ cd /path/to/my/codebase
-$ git-init <1>
-$ git-add . <2>
+$ git init <1>
+$ git add . <2>
----------------
+
<1> prepare /path/to/my/codebase/.git directory
index 7da5b8d9a9af04a5bf2188523587b086301bfd67..522a58d10e214ee489bea7fdd6b649055e0712d6 100644 (file)
SYNOPSIS
--------
[verse]
-'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
+'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
[--browser=<browser>]
-'git-instaweb' [--start] [--stop] [--restart]
+'git instaweb' [--start] [--stop] [--restart]
DESCRIPTION
-----------
index db61bc96c7e23132c41bb75724d669a6224a3d76..cf1ab7beee07db9c71d8857224eedafc29544422 100644 (file)
SYNOPSIS
--------
-'git-log' <option>...
+'git log' <option>...
DESCRIPTION
-----------
index 4dc475e0de14ea5daf8594f023dd6f6d1993c867..602b8d5d4de8f7649cb88e6622108c012f484933 100644 (file)
SYNOPSIS
--------
-'git-lost-found'
+'git lost-found'
DESCRIPTION
-----------
index 560594e25fdb4ef73aaaba55576c41d704f9ef8b..adcec3c242c94724df2c1336c49206d8e2e70022 100644 (file)
SYNOPSIS
--------
[verse]
-'git-ls-files' [-z] [-t] [-v]
+'git ls-files' [-z] [-t] [-v]
(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
(-[c|d|o|i|s|u|k|m])\*
[-x <pattern>|--exclude=<pattern>]
index f92f3ca1860f9d3e0d5b3f21674a9c2baf61b4d9..061909d3f4bf6abf4f5c183a91c01295266e5c55 100644 (file)
SYNOPSIS
--------
[verse]
-'git-ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
+'git ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
<repository> <refs>...
DESCRIPTION
index d9881fbbbedb84f400bf0b630dcb60acd5ad4e9e..1cdec222a1998d90df750d7dfeb8f9b528965aed 100644 (file)
SYNOPSIS
--------
[verse]
-'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
+'git ls-tree' [-d] [-r] [-t] [-l] [-z]
[--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
<tree-ish> [paths...]
index 6a73b7371a271c27a3ecd377ff7210de552ad6f3..87cfa45147b46e78ac9a781802cc66fa33218c87 100644 (file)
SYNOPSIS
--------
-'git-mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
+'git mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
DESCRIPTION
whitespaces, (3) '[' up to ']', typically '[PATCH]', and
then prepends "[PATCH] ". This flag forbids this
munging, and is most useful when used to read back
- 'git format-patch -k' output.
+ 'git-format-patch -k' output.
-u::
The commit log message, author name and author email are
index 9a2aedd480c24018d12bde419b69f865be2b8825..acd712b1cd75164acb78df38942aa1a35e4d80ca 100644 (file)
SYNOPSIS
--------
-'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
+'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
DESCRIPTION
-----------
index bbe85123977e3fc11abc2fc9f16489215b4bd7a3..91057359060e9354e35afc8b6b693a976c06d9ec 100644 (file)
SYNOPSIS
--------
-'git-merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>
DESCRIPTION
-----------
"git-merge-base" finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B 'git-merge-base A
+the two commits. That is, given two commits A and B 'git merge-base A
B' will output a commit which is reachable from both A and B through
the parent relationship.
index 149f1310519bb5b732fca0926f786f80a153f8da..2a683f14e624565efea46032b20c73ee79f4124b 100644 (file)
SYNOPSIS
--------
[verse]
-'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
This option may be given up to three times, and
specifies labels to be used in place of the
corresponding file names in conflict reports. That is,
- `git-merge-file -L x -L y -L z a b c` generates output that
+ `git merge-file -L x -L y -L z a b c` generates output that
looks like it came from files x, y and z instead of
from files a, b and c.
index a0ead2bbf33d7b244ec94e6f7dc06c062e52cb8d..fb55e92e3b63d5dbaa63e2ea92be2441436da794 100644 (file)
SYNOPSIS
--------
-'git-merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
+'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
DESCRIPTION
-----------
Examples:
- torvalds@ppc970:~/merge-test> git-merge-index cat MM
+ torvalds@ppc970:~/merge-test> git merge-index cat MM
This is MM from the original tree. # original
This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
or
- torvalds@ppc970:~/merge-test> git-merge-index cat AA MM
+ torvalds@ppc970:~/merge-test> git merge-index cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
index b785e0f6e0c02ef688d4c6a60e19939aafd1a8d3..dbb0c18668ff0fb60c31c12b02c27d92b430c24a 100644 (file)
SYNOPSIS
--------
-'git-merge-tree' <base-tree> <branch1> <branch2>
+'git merge-tree' <base-tree> <branch1> <branch2>
DESCRIPTION
-----------
index 55bc3674797366496d7c1ca1f5b6564b06c01de1..7e328ea9dcf3a58a149b0b9bf40729be03f916b3 100644 (file)
SYNOPSIS
--------
[verse]
-'git-merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
+'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
[-m <msg>] <remote> <remote>...
-'git-merge' <msg> HEAD <remote>...
+'git merge' <msg> HEAD <remote>...
DESCRIPTION
-----------
commits (usually, branch head or tag), and the index file must
exactly match the
tree of `HEAD` commit (i.e. the contents of the last commit) when
-it happens. In other words, `git-diff --cached HEAD` must
+it happens. In other words, `git diff --cached HEAD` must
report no changes.
[NOTE]
3. For conflicting paths, the index file records up to three
versions; stage1 stores the version from the common ancestor,
stage2 from `HEAD`, and stage3 from the remote branch (you
- can inspect the stages with `git-ls-files -u`). The working
+ can inspect the stages with `git ls-files -u`). The working
tree files have the result of "merge" program; i.e. 3-way
merge result with familiar conflict markers `<<< === >>>`.
up working tree changes made by 2. and 3.; `git-reset` can
be used for this.
- * Resolve the conflicts. `git-diff` would report only the
+ * Resolve the conflicts. `git diff` would report only the
conflicting paths because of the above 2. and 3.. Edit the
working tree files into a desirable shape, `git-add` or `git-rm`
them, to make the index file contain what the merge result
index 83525609c6ff3e4d82c9e8021b3107517c682496..fc1b03002651d168ed068adeec0475f870f46f16 100644 (file)
SYNOPSIS
--------
-'git-mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [<file>]...
DESCRIPTION
-----------
If one or more <file> parameters are given, the merge tool program will
be run to resolve differences on each file. If no <file> names are
-specified, `git mergetool` will run the merge tool program on every file
+specified, `git-mergetool` will run the merge tool program on every file
with merge conflicts.
OPTIONS
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
-If a merge resolution program is not specified, `git mergetool`
+If a merge resolution program is not specified, `git-mergetool`
will use the configuration variable `merge.tool`. If the
-configuration variable `merge.tool` is not set, `git mergetool`
+configuration variable `merge.tool` is not set, `git-mergetool`
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `mergetool.<tool>.path`. For example, you
can configure the absolute path to kdiff3 by setting
-`mergetool.kdiff3.path`. Otherwise, `git mergetool` assumes the
+`mergetool.kdiff3.path`. Otherwise, `git-mergetool` assumes the
tool is available in PATH.
+
Instead of running one of the known merge tool programs
-`git mergetool` can be customized to run an alternative program
+`git-mergetool` can be customized to run an alternative program
by specifying the command line to invoke in a configration
variable `mergetool.<tool>.cmd`.
+
-When `git mergetool` is invoked with this tool (either through the
+When `git-mergetool` is invoked with this tool (either through the
`-t` or `--tool` option or the `merge.tool` configuration
variable) the configured command line will be invoked with `$BASE`
set to the name of a temporary file containing the common base for
If the custom merge tool correctly indicates the success of a
merge resolution with its exit code then the configuration
variable `mergetool.<tool>.trustExitCode` can be set to `true`.
-Otherwise, `git mergetool` will prompt the user to indicate the
+Otherwise, `git-mergetool` will prompt the user to indicate the
success of the resolution after the custom tool has exited.
Author
index 232bc1a338468274f4304bea684f148b5b58aee8..8bcc11443dce7322ac5b0fa70e07b2465f762615 100644 (file)
SYNOPSIS
--------
-'git-mktag' < signature_file
+'git mktag' < signature_file
DESCRIPTION
-----------
index 1ddbf00afccf93d2c31d3c6d0deabd82ff4fe779..0be32e26126c075b408f37212f8658394b272297 100644 (file)
SYNOPSIS
--------
-'git-mktree' [-z]
+'git mktree' [-z]
DESCRIPTION
-----------
index 339190600a292eca9b56771316118481236d46fb..9c5660275b326661bf7dc9a5162e5177b8a62b0f 100644 (file)
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
SYNOPSIS
--------
-'git-mv' <options>... <args>...
+'git mv' <options>... <args>...
DESCRIPTION
-----------
This script is used to move or rename a file, directory or symlink.
- git-mv [-f] [-n] <source> <destination>
- git-mv [-f] [-n] [-k] <source> ... <destination directory>
+ git mv [-f] [-n] <source> <destination>
+ git mv [-f] [-n] [-k] <source> ... <destination directory>
In the first form, it renames <source>, which must exist and be either
a file, symlink or directory, to <destination>.
index ffac3f8f564bf5f5e2ca317b986db9b01f5dc026..b2d40a7e70d3bbc68edb2676746fbf83b8a67de0 100644 (file)
SYNOPSIS
--------
[verse]
-'git-name-rev' [--tags] [--refs=<pattern>]
+'git name-rev' [--tags] [--refs=<pattern>]
( --all | --stdin | <committish>... )
DESCRIPTION
index f4d8d68e34b223f6ed06bceca706f9b91232c15f..c4ac3a792140eb8968a67015e0ddcb92d347d09a 100644 (file)
SYNOPSIS
--------
[verse]
-'git-pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
+'git pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
[--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
[--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
index 6737326f0b63108a9ecbd746824363e20f9a2ae2..95bf39978eabd00c3b288fe5b2f70a87c0fcfdad 100644 (file)
SYNOPSIS
--------
-'git-pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
+'git pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
DESCRIPTION
-----------
following command useful when wanting to remove packs which contain unreachable
objects.
-git-fsck --full --unreachable | cut -d ' ' -f3 | \
-git-pack-redundant --all | xargs rm
+git fsck --full --unreachable | cut -d ' ' -f3 | \
+git pack-redundant --all | xargs rm
OPTIONS
-------
index c0718468d563e7ee5f8bd37c5f583ec7dc9d3d62..a5244d35f49f10b7954d8fa52164663e3d167d4b 100644 (file)
SYNOPSIS
--------
-'git-pack-refs' [--all] [--no-prune]
+'git pack-refs' [--all] [--no-prune]
DESCRIPTION
-----------
A recommended practice to deal with a repository with too many
refs is to pack its refs with `--all --prune` once, and
-occasionally run `git-pack-refs \--prune`. Tags are by
+occasionally run `git pack-refs \--prune`. Tags are by
definition stationary and are not expected to change. Branch
heads will be packed with the initial `pack-refs --all`, but
only the currently active branch heads will become unpacked,
index bb8a079254e7fed097504cd181eee71a888d2280..c9970f5ab661abf1b23d762649d85bc37be244e5 100644 (file)
SYNOPSIS
--------
-'git-patch-id' < <patch>
+'git patch-id' < <patch>
DESCRIPTION
-----------
index ffbf93a7993cee0386c42bef1c827a8488f04d8e..05027d2c9386d1963e739cd1538ffe71e0c36c0a 100644 (file)
SYNOPSIS
--------
-'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
+'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
DESCRIPTION
-----------
index f330b8a5b9bbd89414571456659fefcbf812254f..b5f26cee132622185457d92522fb932302dec97d 100644 (file)
SYNOPSIS
--------
-'git-prune-packed' [-n] [-q]
+'git prune-packed' [-n] [-q]
DESCRIPTION
index ec335d6fab6e9639a7f7d93c5b88002e2192fd4c..10930000c54346a3cc81266a3808566c15f15d7e 100644 (file)
objects unreachable from any of these head objects from the object database.
In addition, it
prunes the unpacked objects that are also found in packs by
-running `git prune-packed`.
+running `git-prune-packed`.
Note that unreachable, packed objects will remain. If this is
not desired, see linkgit:git-repack[1].
`.git/objects/info/alternates`:
------------
-$ git prune $(cd ../another && $(git-rev-parse --all))
+$ git prune $(cd ../another && $(git rev-parse --all))
------------
Notes
index d0f1595f7e9051b5d58d1dba030ea3a7d80bdab5..99eb7eda366dd8a01aa1ed19ea7efb8a7f39b38c 100644 (file)
SYNOPSIS
--------
-'git-pull' <options> <repository> <refspec>...
+'git pull' <options> <repository> <refspec>...
DESCRIPTION
index f3d5d883a7e4e42c47670eeeef41799b1cb0c228..176379134ee7bc106dc9f54982218129559b7e99 100644 (file)
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
DESCRIPTION
index 0600379394ee7c2b00743379170b9a4718bf7db6..d4037de5124010e9c90dcc97e8b64e6011dbed21 100644 (file)
SYNOPSIS
--------
[verse]
-'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
+'git quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
DESCRIPTION
index 58fb906ef68e8b800b0616a5655aa757a362ed6e..1a57f580717e55afcdb463dc9acbb20b7b0dc218 100644 (file)
SYNOPSIS
--------
-'git-read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
DESCRIPTION
being read, the stat info from the index is used. (In other words, the
index's stat()s take precedence over the merged tree's).
-That means that if you do a `git-read-tree -m <newtree>` followed by a
-`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
+That means that if you do a `git read-tree -m <newtree>` followed by a
+`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
the stuff that really changed.
This is used to avoid unnecessary false hits when `git-diff-files` is
Two Tree Merge
~~~~~~~~~~~~~~
-Typically, this is invoked as `git-read-tree -m $H $M`, where $H
+Typically, this is invoked as `git read-tree -m $H $M`, where $H
is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
fast forward situation).
2. The user wants to fast-forward to $M.
-In this case, the `git-read-tree -m $H $M` command makes sure
+In this case, the `git read-tree -m $H $M` command makes sure
that no local change is lost as the result of this "merge".
Here are the "carry forward" rules:
When this form of git-read-tree returns successfully, you can
see what "local changes" you made are carried forward by running
-`git-diff-index --cached $M`. Note that this does not
-necessarily match `git-diff-index --cached $H` would have
+`git diff-index --cached $M`. Note that this does not
+necessarily match `git diff-index --cached $H` would have
produced before such a two tree merge. This is because of cases
18 and 19 --- if you already had the changes in $M (e.g. maybe
-you picked it up via e-mail in a patch form), `git-diff-index
+you picked it up via e-mail in a patch form), `git diff-index
--cached $H` would have told you about the change before this
-merge, but it would not show in `git-diff-index --cached $M`
+merge, but it would not show in `git diff-index --cached $M`
output after two-tree merge.
This means that you can do
----------------
-$ git-read-tree -m <tree1> <tree2> <tree3>
+$ git read-tree -m <tree1> <tree2> <tree3>
----------------
and you will end up with an index with all of the <tree1> entries in
committed last to your repository:
----------------
-$ JC=`git-rev-parse --verify "HEAD^0"`
-$ git-checkout-index -f -u -a $JC
+$ JC=`git rev-parse --verify "HEAD^0"`
+$ git checkout-index -f -u -a $JC
----------------
You do random edits, without running git-update-index. And then
since you pulled from him:
----------------
-$ git-fetch git://.... linus
+$ git fetch git://.... linus
$ LT=`cat .git/FETCH_HEAD`
----------------
then does the right thing. So with the following sequence:
----------------
-$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
-$ git-merge-index git-merge-one-file -a
+$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
+$ git merge-index git-merge-one-file -a
$ echo "Merge with Linus" | \
- git-commit-tree `git-write-tree` -p $JC -p $LT
+ git commit-tree `git write-tree` -p $JC -p $LT
----------------
what you would commit is a pure merge between $JC and $LT without
index 7166414355e7469c5aeae0262f3902ce7398c989..2753f7470177c471e574d8be397cca0c1549b1a5 100644 (file)
SYNOPSIS
--------
[verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
[-s <strategy> | --strategy=<strategy>]
[-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
[--onto <newbase>] <upstream> [<branch>]
-'git-rebase' --continue | --skip | --abort
+'git rebase' --continue | --skip | --abort
DESCRIPTION
-----------
From this point, the result of either of the following commands:
- git-rebase master
- git-rebase master topic
+ git rebase master
+ git rebase master topic
would be:
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
-will be skipped. For example, running `git-rebase master` on the
+will be skipped. For example, running `git rebase master` on the
following history (in which A' and A introduce the same set of changes,
but have different committer information):
We can get this using the following command:
- git-rebase --onto master next topic
+ git rebase --onto master next topic
Another example of --onto option is to rebase part of a
then the command
- git-rebase --onto master topicA topicB
+ git rebase --onto master topicA topicB
would result in:
then the command
- git-rebase --onto topicA~5 topicA~3 topicA
+ git rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
parameter can be any valid commit-ish.
In case of conflict, git-rebase will stop at the first problematic commit
-and leave conflict markers in the tree. You can use git diff to locate
+and leave conflict markers in the tree. You can use git-diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell git that the conflict has been resolved,
typically this would be done with
-----------------
In interactive mode, you can mark commits with the action "edit". However,
-this does not necessarily mean that 'git rebase' expects the result of this
+this does not necessarily mean that 'git-rebase' expects the result of this
edit to be exactly one commit. Indeed, you can undo the commit, or you can
add other commits. This can be used to split a commit into two:
index a70c7168f60f8cbb6666a34334114e2759424ccd..8c696296a7cec2dc15147961f6bcde93e1135044 100644 (file)
SYNOPSIS
--------
-'git-receive-pack' <directory>
+'git receive-pack' <directory>
DESCRIPTION
-----------
if expr "$oval" : '0*$' >/dev/null
then
echo "Created a new ref, with the following commits:"
- git-rev-list --pretty "$nval"
+ git rev-list --pretty "$nval"
else
echo "New commits:"
- git-rev-list --pretty "$nval" "^$oval"
+ git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Changes to ref $ref" commit-list@mydomain
done
left for git-receive-pack to do at that point is to exit itself
anyway.
-This hook can be used, for example, to run "git-update-server-info"
+This hook can be used, for example, to run "git update-server-info"
if the repository is packed and is served via a dumb transport.
#!/bin/sh
- exec git-update-server-info
+ exec git update-server-info
SEE ALSO
index f6dafd4495f8f24d1f6759c5c2e7ee5d387e31a5..25ff8f9dcbe0db52675338f1429e9169052b9cf1 100644 (file)
SYNOPSIS
--------
-'git-relink' [--safe] <dir> [<dir>]\* <master_dir>
+'git relink' [--safe] <dir> [<dir>]\* <master_dir>
DESCRIPTION
-----------
index 345943a26466dab73034b41698c54ca317cc4d75..32db0aed11bee4fd97785fcd963dc3f5461f5657 100644 (file)
SYNOPSIS
--------
[verse]
-'git-remote' [-v | --verbose]
-'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
-'git-remote' rm <name>
-'git-remote' show [-n] <name>
-'git-remote' prune [-n | --dry-run] <name>
-'git-remote' update [group]
+'git remote' [-v | --verbose]
+'git remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote' rm <name>
+'git remote' show [-n] <name>
+'git remote' prune [-n | --dry-run] <name>
+'git remote' update [group]
DESCRIPTION
-----------
index 9011d06e7dc84a5d6f7079fe8d3471a47736e1f6..6bc5975379894075808240493e59be3f65b336ea 100644 (file)
SYNOPSIS
--------
-'git-repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
+'git repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
DESCRIPTION
-----------
Also runs linkgit:git-prune-packed[1].
-l::
- Pass the `--local` option to `git pack-objects`, see
+ Pass the `--local` option to `git-pack-objects`, see
linkgit:git-pack-objects[1].
-f::
- Pass the `--no-reuse-delta` option to `git pack-objects`, see
+ Pass the `--no-reuse-delta` option to `git-pack-objects`, see
linkgit:git-pack-objects[1].
-q::
- Pass the `-q` option to `git pack-objects`, see
+ Pass the `-q` option to `git-pack-objects`, see
linkgit:git-pack-objects[1].
-n::
Do not update the server information with
- `git update-server-info`. This option skips
+ `git-update-server-info`. This option skips
updating local catalog files needed to publish
this repository (or a direct copy of it)
over HTTP or FTP. See gitlink:git-update-server-info[1].
index 2ca39946b715f54e7deb451f7b59644fede08a84..e5bdb5533e61687874ad36d30534b2ac9e58d7cb 100644 (file)
SYNOPSIS
--------
-'git-repo-config' ...
+'git repo-config' ...
DESCRIPTION
index c71d86985ea2136e7c7da5e4ca758ca7ef675409..ca6843032a47617b348a3862be8beb5ce6f28ed6 100644 (file)
SYNOPSIS
--------
-'git-request-pull' <start> <url> [<end>]
+'git request-pull' <start> <url> [<end>]
DESCRIPTION
-----------
index 8030ec4d01de8cf2c7a62a7b1fd8d917e6d14b53..d712f62c5f8f02561992119f5dd2bcd4c6b2902d 100644 (file)
SYNOPSIS
--------
-'git-rerere' [clear|diff|status|gc]
+'git rerere' [clear|diff|status|gc]
DESCRIPTION
-----------
up-to-date even before your topic is ready to be sent upstream.
This would result in falling back to three-way merge, and it
would conflict the same way the test merge you resolved earlier.
-`git-rerere` is run by `git rebase` to help you resolve this
+`git-rerere` is run by `git-rebase` to help you resolve this
conflict.
index c9b09503210cd23a3528bd67cbbf8577d1e670e2..61ec6dca8b7e011cd7fff3eaaeb601e587b7188c 100644 (file)
command:
-----------------------------------------------------------------------
- $ git-rev-list foo bar ^baz
+ $ git rev-list foo bar ^baz
-----------------------------------------------------------------------
means "list all the commits which are included in 'foo' and 'bar', but
the following may be used interchangeably:
-----------------------------------------------------------------------
- $ git-rev-list origin..HEAD
- $ git-rev-list HEAD ^origin
+ $ git rev-list origin..HEAD
+ $ git rev-list HEAD ^origin
-----------------------------------------------------------------------
Another special notation is "'<commit1>'...'<commit2>'" which is useful
between the two operands. The following two commands are equivalent:
-----------------------------------------------------------------------
- $ git-rev-list A B --not $(git-merge-base --all A B)
- $ git-rev-list A...B
+ $ git rev-list A B --not $(git merge-base --all A B)
+ $ git rev-list A...B
-----------------------------------------------------------------------
linkgit:git-rev-list[1] is a very essential git program, since it
index 59e95adf42d1d481d636929a0b3ad79eebc53426..e9fb2b15795e213580ee78230d3db0b28dddc698 100644 (file)
SYNOPSIS
--------
-'git-rev-parse' [ --option ] <args>...
+'git rev-parse' [ --option ] <args>...
DESCRIPTION
-----------
A similar notation "`r1\...r2`" is called symmetric difference
of `r1` and `r2` and is defined as
-"`r1 r2 --not $(git-merge-base --all r1 r2)`".
+"`r1 r2 --not $(git merge-base --all r1 r2)`".
It is the set of commits that are reachable from either one of
`r1` or `r2` but not from both.
An option group Header
C? option C with an optional argument"
-eval `echo "$OPTS_SPEC" | git-rev-parse --parseopt -- "$@" || echo exit $?`
+eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
------------
EXAMPLES
index 5b49b813862c5318701e40f1a798ca04cd1d3a63..3d0c5aba93391ed6bb3ffcc9a3919450b3520395 100644 (file)
SYNOPSIS
--------
-'git-revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
+'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
DESCRIPTION
-----------
index d88554bedcaa9acdf8828e9abe6d5169e32446a3..41e00d9a6ab45b2f072db840f677c0194805d17f 100644 (file)
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
SYNOPSIS
--------
-'git-rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
+'git rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
DESCRIPTION
-----------
Remove files from the index, or from the working tree and the index.
-`git rm` will not remove a file from just your working directory.
+`git-rm` will not remove a file from just your working directory.
(There is no option to remove a file only from the work tree
and yet keep it in the index; use `/bin/rm` if you want to do that.)
The files being removed have to be identical to the tip of the branch,
EXAMPLES
--------
-git-rm Documentation/\\*.txt::
+git rm Documentation/\\*.txt::
Removes all `\*.txt` files from the index that are under the
`Documentation` directory and any of its subdirectories.
+
example; this lets git, and not the shell, expand the pathnames
of files and subdirectories under the `Documentation/` directory.
-git-rm -f git-*.sh::
+git rm -f git-*.sh::
Because this example lets the shell expand the asterisk
(i.e. you are listing the files explicitly), it
does not remove `subdir/git-foo.sh`.
index dc7eb7bd4ef81a1272ba272678d8da4a330eb543..afbb294a7faadc7ff6d4039246dc1c085575cd4f 100644 (file)
SYNOPSIS
--------
-'git-send-email' [options] <file|directory> [... file|directory]
+'git send-email' [options] <file|directory> [... file|directory]
index ba2fdaec08913e921189395e7feb2ed4d229ece5..dba015fbe9aac0364361406766710ccf758a4b55 100644 (file)
SYNOPSIS
--------
-'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
DESCRIPTION
-----------
index daa64d4d8165a0dfe5d87f54cd44c4bb6b476eba..b55301bb97126fec336e55bb4b94b9e19385df6f 100644 (file)
SYNOPSIS
--------
[verse]
-git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e] [-w]
-git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
+git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
+git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
DESCRIPTION
-----------
-Summarizes 'git log' output in a format suitable for inclusion
+Summarizes 'git-log' output in a format suitable for inclusion
in release announcements. Each commit will be grouped by author and
the first line of the commit message will be shown.
index de9e8f885f794692bcc45b871e791ebbd7c806cd..b9228dc88716275735d03b64336e6b3e438b7ea3 100644 (file)
SYNOPSIS
--------
[verse]
-'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
+'git show-branch' [--all] [--remotes] [--topo-order] [--current]
[--more=<n> | --list | --independent | --merge-base]
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
-'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
+'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
DESCRIPTION
-----------
index 891f0eff27557acddd1212eae62aca293525d5dd..4227cbbd9a40676fa1c00c593214c41b32bf412a 100644 (file)
SYNOPSIS
--------
-'git-show-index' < idx-file
+'git show-index' < idx-file
DESCRIPTION
index 6b99529b6bb659ec1e1ffd741208ef03762c0356..c1f03d4bd760398fef5e81b667b7742756cd2e70 100644 (file)
SYNOPSIS
--------
[verse]
-'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
[-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
-'git-show-ref' --exclude-existing[=pattern]
+'git show-ref' --exclude-existing[=pattern]
DESCRIPTION
-----------
allows you to do things like
-----------------------------------------------------------------------------
- git-show-ref --quiet --verify -- "refs/heads/$headname" ||
+ git show-ref --quiet --verify -- "refs/heads/$headname" ||
echo "$headname is not a valid branch"
-----------------------------------------------------------------------------
index baaf2bc8feefe4fb88a1ec43d2f70bbfdfe6fbf6..44570d92d48e4e3c0ff97561cab7684935bd1fb9 100644 (file)
SYNOPSIS
--------
-'git-show' [options] <object>...
+'git show' [options] <object>...
DESCRIPTION
-----------
index baa4f55b48ac2fad72b18651a98bc542d1f38f5c..f994679d953a80921627f5107b8680c7e7f7bab2 100644 (file)
SYNOPSIS
--------
[verse]
-'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
-'git-stash' [save [<message>]]
+'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' [save [<message>]]
DESCRIPTION
-----------
-Use 'git-stash' when you want to record the current state of the
+Use 'git stash' when you want to record the current state of the
working directory and the index, but want to go back to a clean
working directory. The command saves your local modifications away
and reverts the working directory to match the `HEAD` commit.
The modifications stashed away by this command can be listed with
`git-stash list`, inspected with `git-stash show`, and restored
(potentially on top of a different commit) with `git-stash apply`.
-Calling git-stash without any arguments is equivalent to `git-stash
+Calling git stash without any arguments is equivalent to `git stash
save`. A stash is by default listed as "WIP on 'branchname' ...", but
you can give a more descriptive message on the command line when
you create one.
save [<message>]::
- Save your local modifications to a new 'stash', and run `git-reset
+ Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. This is the default action when no
subcommand is given. The <message> part is optional and gives
the description along with the stashed state.
Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
- it will accept any format known to `git-diff` (e.g., `git-stash show
+ it will accept any format known to `git-diff` (e.g., `git stash show
-p stash@\{1}` to view the second most recent stash in patch form).
apply [--index] [<stash>]::
index fef62b16df365301f01f4c129fdba02fef84234a..c9d4a046c70bea973612d002c997fbdba9aa3aa6 100644 (file)
SYNOPSIS
--------
-'git-status' <options>...
+'git status' <options>...
DESCRIPTION
-----------
tree and the index file, and paths in the working tree that are not
tracked by git (and are not ignored by linkgit:gitignore[5]). The first
are what you _would_ commit by running `git commit`; the second and
-third are what you _could_ commit by running `git add` before running
+third are what you _could_ commit by running `git-add` before running
`git commit`.
The command takes the same set of options as `git-commit`; it
If there is no path that is different between the index file and
the current HEAD commit (i.e., there is nothing to commit by running
-`git-commit`), the command exits with non-zero status.
+`git commit`), the command exits with non-zero status.
OUTPUT
index 8421a39f26ac4807afd42e8f3ac084686b170871..7508c0e42d2cd50ac522fc80a3a866411b7b51c5 100644 (file)
SYNOPSIS
--------
-'git-stripspace' [-s | --strip-comments] < <stream>
+'git stripspace' [-s | --strip-comments] < <stream>
DESCRIPTION
-----------
index 441ae1483bf57aca849c0470c6e19e963c9ebf19..c1deec98d1540666d2cb5f5aec0bb6d264700ded 100644 (file)
SYNOPSIS
--------
[verse]
-'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
-'git-submodule' [--quiet] status [--cached] [--] [<path>...]
-'git-submodule' [--quiet] init [--] [<path>...]
-'git-submodule' [--quiet] update [--init] [--] [<path>...]
-'git-submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
+'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
+'git submodule' [--quiet] status [--cached] [--] [<path>...]
+'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] update [--init] [--] [<path>...]
+'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
COMMANDS
index c350ad0f83b413fa4c7810195f64cdfbbfdd1717..6ddfed3a9c81e32a3175b22d4f5e1a5a5f931e16 100644 (file)
SYNOPSIS
--------
-'git-svn' <command> [options] [arguments]
+'git svn' <command> [options] [arguments]
DESCRIPTION
-----------
client converts the UTC time to the local time (or based on the TZ=
environment). This command has the same behaviour.
+
-Any other arguments are passed directly to `git log'
+Any other arguments are passed directly to `git-log'
'blame'::
Show what revision and author last modified each line of a file. The
arguments are passed directly to git-blame.
+
--git-format;;
- Produce output in the same format as `git blame', but with
+ Produce output in the same format as `git-blame', but with
SVN revision numbers instead of git commit hashes. In this mode,
changes that haven't been committed to SVN (including local
working-copy edits) are shown as revision 0.
------------------------------------------------------------------------
# Clone a repo (like git clone):
- git-svn clone http://svn.foo.org/project/trunk
+ git svn clone http://svn.foo.org/project/trunk
# Enter the newly cloned directory:
cd trunk
# You should be on master branch, double-check with git-branch
git commit ...
# Something is committed to SVN, rebase your local changes against the
# latest changes in SVN:
- git-svn rebase
+ git svn rebase
# Now commit your changes (that were committed previously using git) to SVN,
# as well as automatically updating your working HEAD:
- git-svn dcommit
+ git svn dcommit
# Append svn:ignore settings to the default git exclude file:
- git-svn show-ignore >> .git/info/exclude
+ git svn show-ignore >> .git/info/exclude
------------------------------------------------------------------------
Tracking and contributing to an entire Subversion-managed project
------------------------------------------------------------------------
# Clone a repo (like git clone):
- git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+ git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
# Reset your master to trunk (or any other branch, replacing 'trunk'
people (or one person with multiple machines) want to use
git-svn to interact with the same Subversion repository, you can
do the initial 'git-svn clone' to a repository on a server and
-have each person clone that repository with 'git clone':
+have each person clone that repository with 'git-clone':
------------------------------------------------------------------------
# Do the initial import on a server
- ssh server "cd /pub && git-svn clone http://svn.foo.org/project
+ ssh server "cd /pub && git svn clone http://svn.foo.org/project
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
- git-init
+ git init
git remote add origin server:/pub/project
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
- git-svn init http://svn.foo.org/project
+ git svn init http://svn.foo.org/project
# Pull the latest changes from Subversion
- git-svn rebase
+ git svn rebase
------------------------------------------------------------------------
REBASE VS. PULL/MERGE
Originally, git-svn recommended that the remotes/git-svn branch be
pulled or merged from. This is because the author favored
-'git-svn set-tree B' to commit a single head rather than the
-'git-svn set-tree A..B' notation to commit multiple commits.
+'git svn set-tree B' to commit a single head rather than the
+'git svn set-tree A..B' notation to commit multiple commits.
-If you use 'git-svn set-tree A..B' to commit several diffs and you do
+If you use 'git svn set-tree A..B' to commit several diffs and you do
not have the latest remotes/git-svn merged into my-branch, you should
-use 'git-svn rebase' to update your work branch instead of 'git pull' or
+use 'git svn rebase' to update your work branch instead of 'git pull' or
'git merge'. 'pull/merge' can cause non-linear history to be flattened
when committing into SVN, which can lead to merge commits reversing
previous commits in SVN.
index 3d3a059c5e2e91bff2de173c5d6f8107d10b7e62..243e26ebf16e2f03106c36ef0c625529b9f44c89 100644 (file)
SYNOPSIS
--------
-'git-symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
+'git symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
DESCRIPTION
-----------
index 0c41711115a0d49adf399ac2400bac91a9027a57..95531349a29486964071d2e761b188ffad87f8d2 100644 (file)
SYNOPSIS
--------
[verse]
-'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
-'git-tag' -d <name>...
-'git-tag' [-n[<num>]] -l [<pattern>]
-'git-tag' -v <name>...
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git tag' -d <name>...
+'git tag' [-n[<num>]] -l [<pattern>]
+'git tag' -v <name>...
DESCRIPTION
-----------
. The insane thing.
You really want to call the new version "X" too, 'even though'
-others have already seen the old one. So just use "git tag -f"
+others have already seen the old one. So just use "git-tag -f"
again, as if you hadn't already published the old one.
However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
-"git pull" on your tree shouldn't just make them overwrite the old
+"git-pull" on your tree shouldn't just make them overwrite the old
one.
If somebody got a release tag from you, you cannot just change
You would notice "please pull" messages on the mailing list says
repo URL and branch name alone. This is designed to be easily
-cut&pasted to "git fetch" command line:
+cut&pasted to "git-fetch" command line:
------------
Linus, please pull from
index 74ed06525e8f920017469301f9773e4b36080ee9..4995dc245a8a9fd340b3bfd08c9917d99da56c34 100644 (file)
SYNOPSIS
--------
-'git-tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
+'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
DESCRIPTION
-----------
index d0552b2c74b25c12e99ba071bb91f12ccd29681a..995db9feadf68df6f22de745d90790a145128e44 100644 (file)
SYNOPSIS
--------
-'git-unpack-file' <blob>
+'git unpack-file' <blob>
DESCRIPTION
-----------
index b9c4279a880c722a1e751469244f79323e618eb8..ae17cc2b44751fb57780a4b41be65fad1d65c1f8 100644 (file)
SYNOPSIS
--------
-'git-unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
+'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
DESCRIPTION
index bbb0a6ad57187c4387412a08ff301ddfc7173726..5295702fd38bfe5eb70f327b9d5adafa09d90817 100644 (file)
SYNOPSIS
--------
[verse]
-'git-update-index'
+'git update-index'
[--add] [--remove | --force-remove] [--replace]
[--refresh] [-q] [--unmerged] [--ignore-missing]
[--cacheinfo <mode> <object> <file>]\*
To pretend you have a file with mode and sha1 at path, say:
----------------
-$ git-update-index --cacheinfo mode sha1 path
+$ git update-index --cacheinfo mode sha1 path
----------------
'--info-only' is used to register files without placing them in the object
option. To unset, use `--no-assume-unchanged`.
The command looks at `core.ignorestat` configuration variable. When
-this is true, paths updated with `git-update-index paths...` and
+this is true, paths updated with `git update-index paths...` and
paths updated with other git commands that update both index and
working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
and `git-read-tree -u`) are automatically marked as "assume
unchanged". Note that "assume unchanged" bit is *not* set if
-`git-update-index --refresh` finds the working tree file matches
-the index (use `git-update-index --really-refresh` if you want
+`git update-index --refresh` finds the working tree file matches
+the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
To update and refresh only the files already checked out:
----------------
-$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
On an inefficient filesystem with `core.ignorestat` set::
index bae2c8b7eced2042af0437b1e92cc73636c7cfa5..9639f705afafab6fcf0cd21ad2693627ab42f66d 100644 (file)
SYNOPSIS
--------
-'git-update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
+'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
DESCRIPTION
-----------
Given two arguments, stores the <newvalue> in the <ref>, possibly
-dereferencing the symbolic refs. E.g. `git-update-ref HEAD
+dereferencing the symbolic refs. E.g. `git update-ref HEAD
<newvalue>` updates the current branch head to the new object.
Given three arguments, stores the <newvalue> in the <ref>,
possibly dereferencing the symbolic refs, after verifying that
the current value of the <ref> matches <oldvalue>.
-E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
+E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>`
updates the master branch head to <newvalue> only if its current
value is <oldvalue>. You can specify 40 "0" or an empty string
as <oldvalue> to make sure that the ref you are creating does
In general, using
- git-update-ref HEAD "$head"
+ git update-ref HEAD "$head"
should be a _lot_ safer than doing
Logging Updates
---------------
If config parameter "core.logAllRefUpdates" is true or the file
-"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
+"$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
symbolic refs before creating the log name) describing the change
in ref value. Log lines are formatted as:
index 010241082111c0650f063844b34e8c9d9616433f..bc1207a317b9c1e93ba35c5a9e82a5e243b4a42e 100644 (file)
SYNOPSIS
--------
-'git-update-server-info' [--force]
+'git update-server-info' [--force]
DESCRIPTION
-----------
index e49f68f68e490d7230963eec06b91ab09c34e19a..bbd7617587084b0c66fd8e0b9f623cac50be2c03 100644 (file)
SYNOPSIS
--------
-'git-upload-archive' <directory>
+'git upload-archive' <directory>
DESCRIPTION
-----------
index bac465e13f2b2d0aaadaedf00fd03ab6f3f9a62c..b8e49dce4a19a4d7083459468f27c273c1d91fea 100644 (file)
SYNOPSIS
--------
-'git-upload-pack' [--strict] [--timeout=<n>] <directory>
+'git upload-pack' [--strict] [--timeout=<n>] <directory>
DESCRIPTION
-----------
index 67e8e1f93a37d19183a41b1119569d980cc43eea..10d1e19cc051364f5ad1e7d830211864f5e735ce 100644 (file)
SYNOPSIS
--------
-'git-var' [ -l | <variable> ]
+'git var' [ -l | <variable> ]
DESCRIPTION
-----------
EXAMPLE
--------
- $ git-var GIT_AUTHOR_IDENT
+ $ git var GIT_AUTHOR_IDENT
Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
index 478f236996eac55c8142d48de8bda1456b426d4a..8536a183617f1175d35fb192c7f43e8735278f8e 100644 (file)
SYNOPSIS
--------
-'git-verify-pack' [-v] [--] <pack>.idx ...
+'git verify-pack' [-v] [--] <pack>.idx ...
DESCRIPTION
index dffba8906ae27bbb305f14732c390eea39bbdca5..2231f6d0c785b1632afc22afb479fc0757061c0c 100644 (file)
SYNOPSIS
--------
-'git-verify-tag' <tag>...
+'git verify-tag' <tag>...
DESCRIPTION
-----------
index e80a7c1cc4c1b62bc4fbdb0a91f063022542d38d..c2cd216df01709d5c27e192aca0502c2f2ab16ed 100644 (file)
SYNOPSIS
--------
-'git-web--browse' [OPTIONS] URL/FILE ...
+'git web--browse' [OPTIONS] URL/FILE ...
DESCRIPTION
-----------
When the browser, specified by options or configuration variables, is
not among the supported ones, then the corresponding
'browser.<tool>.cmd' configuration variable will be looked up. If this
-variable exists then "git web--browse" will treat the specified tool
+variable exists then "git-web--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.
cmd = A_PATH_TO/konqueror
------------------------------------------------
-Note about git config --global
+Note about git-config --global
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that these configuration variables should probably be set using
index f5d39c7870b9f6d07c8fadd3823df5d56da2dfe0..d7fad1532936d909f9daf59f209e9c59c17c74c5 100644 (file)
SYNOPSIS
--------
-'git-whatchanged' <option>...
+'git whatchanged' <option>...
DESCRIPTION
-----------
Examples
--------
-git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+git whatchanged -p v2.6.12.. include/scsi drivers/scsi::
Show as patches the commits since version 'v2.6.12' that changed
any file in the include/scsi or drivers/scsi subdirectories
-git-whatchanged --since="2 weeks ago" \-- gitk::
+git whatchanged --since="2 weeks ago" \-- gitk::
Show the changes during the last two weeks to the file 'gitk'.
The "--" is necessary to avoid confusion with the *branch* named
index 8744f6535d4c411b620e1504c92a04791f0246df..19d979bcc7952c2960053ee0c884d05a5dd64ecf 100644 (file)
SYNOPSIS
--------
-'git-write-tree' [--missing-ok] [--prefix=<prefix>/]
+'git write-tree' [--missing-ok] [--prefix=<prefix>/]
DESCRIPTION
-----------
index 6e67990f64372855dd665da4747a7f7c235ac856..e96d3cdcac04f5c07ab801da582bba75e341d6ad 100644 (file)
These attributes affect how the contents stored in the
repository are copied to the working tree files when commands
-such as `git checkout` and `git merge` run. They also affect how
+such as `git-checkout` and `git-merge` run. They also affect how
git stores the contents you prepare in the working tree in the
-repository upon `git add` and `git commit`.
+repository upon `git-add` and `git-commit`.
`crlf`
^^^^^^
a conversion done to the files in the work tree, but there are a
few exceptions. Even though...
-- "git add" itself does not touch the files in the work tree, the
+- "git-add" itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
-- "git apply" to update a text file with a patch does touch the files
+- "git-apply" to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
-- "git diff" itself does not touch the files in the work tree, it is
- often run to inspect the changes you intend to next "git add". To
+- "git-diff" itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next "git-add". To
catch potential problems early, safety triggers.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
-The attribute `diff` affects if `git diff` generates textual
+The attribute `diff` affects if `git-diff` generates textual
patch for the path or just says `Binary files differ`. It also
can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
line.
index 6bb32a8258de4fae12c7d7b76395af9c7ec69277..ce197d59f4b75a93238ccb5c219fbab63f6d5858 100644 (file)
------------------------------------------------
$ mkdir git-tutorial
$ cd git-tutorial
-$ git-init
+$ git init
------------------------------------------------
to which git will reply
So to populate the index with the two files you just created, you can do
------------------------------------------------
-$ git-update-index --add hello example
+$ git update-index --add hello example
------------------------------------------------
and you have now told git to track those two files.
you'll have to use the object name, not the filename of the object:
----------------
-$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
----------------
where the `-t` tells `git-cat-file` to tell you what the "type" of the
regular file), and you can see the contents with
----------------
-$ git-cat-file "blob" 557db03
+$ git cat-file "blob" 557db03
----------------
which will print out "Hello World". The object `557db03` is nothing
`git-diff-files` command:
------------
-$ git-diff-files
+$ git diff-files
------------
Oops. That wasn't very readable. It just spit out its own internal
differences as a patch, using the `-p` flag:
------------
-$ git-diff-files -p
+$ git diff-files -p
diff --git a/hello b/hello
index 557db03..263414f 100644
--- a/hello
what is recorded in the index, and what is currently in the working
tree. That's very useful.
-A common shorthand for `git-diff-files -p` is to just write `git
+A common shorthand for `git diff-files -p` is to just write `git
diff`, which will do the same thing.
------------
tree was all about, along with information of how we came to that state.
Creating a tree object is trivial, and is done with `git-write-tree`.
-There are no options or other input: git-write-tree will take the
+There are no options or other input: git write-tree will take the
current index state, and write an object that describes that whole
index. In other words, we're now tying together all the different
filenames with their contents (and their permissions), and we're
creating the equivalent of a git "directory" object:
------------------------------------------------
-$ git-write-tree
+$ git write-tree
------------------------------------------------
and this will just output the name of the resulting tree, in this case
----------------
which is another incomprehensible object name. Again, if you want to,
-you can use `git-cat-file -t 8988d\...` to see that this time the object
+you can use `git cat-file -t 8988d\...` to see that this time the object
is not a "blob" object, but a "tree" object (you can also use
-`git-cat-file` to actually output the raw object contents, but you'll see
+`git cat-file` to actually output the raw object contents, but you'll see
mainly a binary mess, so that's less interesting).
However -- normally you'd never use `git-write-tree` on its own, because
all with a sequence of simple shell commands:
------------------------------------------------
-$ tree=$(git-write-tree)
-$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
-$ git-update-ref HEAD $commit
+$ tree=$(git write-tree)
+$ commit=$(echo 'Initial commit' | git commit-tree $tree)
+$ git update-ref HEAD $commit
------------------------------------------------
In this case this creates a totally new commit that is not related to
state in the working tree, and how they don't have to match, even
when we commit things.
-As before, if we do `git-diff-files -p` in our git-tutorial project,
+As before, if we do `git diff-files -p` in our git-tutorial project,
we'll still see the same difference we saw last time: the index file
hasn't changed by the act of committing anything. However, now that we
have committed something, we can also learn to use a new command:
But now we can do
----------------
-$ git-diff-index -p HEAD
+$ git diff-index -p HEAD
----------------
(where `-p` has the same meaning as it did in `git-diff-files`), and it
working tree, but when given the `\--cached` flag, it is told to
instead compare against just the index cache contents, and ignore the
current working tree state entirely. Since we just wrote the index
-file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
+file to HEAD, doing `git diff-index \--cached -p HEAD` should thus return
an empty set of differences, and that's exactly what it does.
[NOTE]
update the index cache:
------------------------------------------------
-$ git-update-index hello
+$ git update-index hello
------------------------------------------------
(note how we didn't need the `\--add` flag this time, since git knew
about the file already).
Note what happens to the different `git-diff-\*` versions here. After
-we've updated `hello` in the index, `git-diff-files -p` now shows no
-differences, but `git-diff-index -p HEAD` still *does* show that the
+we've updated `hello` in the index, `git diff-files -p` now shows no
+differences, but `git diff-index -p HEAD` still *does* show that the
current state is different from the state we committed. In fact, now
`git-diff-index` shows the same difference whether we use the `--cached`
flag or not, since now the index is coherent with the working tree.
the same diff that we've already seen several times, we can now do
----------------
-$ git-diff-tree -p HEAD
+$ git diff-tree -p HEAD
----------------
(again, `-p` means to show the difference as a human-readable patch),
powerful)
----------------
-$ git-whatchanged -p
+$ git whatchanged -p
----------------
and you will see exactly what has changed in the repository over its
So after you do a `cp -a` to create a new copy, you'll want to do
+
----------------
-$ git-update-index --refresh
+$ git update-index --refresh
----------------
+
in the new repository to make sure that the index file is up-to-date.
so usually you'll precede the `git-update-index` with a
----------------
-$ git-read-tree --reset HEAD
-$ git-update-index --refresh
+$ git read-tree --reset HEAD
+$ git update-index --refresh
----------------
which will force a total index re-build from the tree pointed to by `HEAD`.
It resets the index contents to `HEAD`, and then the `git-update-index`
makes sure to match up all index entries with the checked-out files.
If the original repository had uncommitted changes in its
-working tree, `git-update-index --refresh` notices them and
+working tree, `git update-index --refresh` notices them and
tells you they need to be updated.
The above can also be written as simply
with the `git xyz` interfaces. You can learn things by just looking
at what the various git scripts do. For example, `git reset` used to be
the above two lines implemented in `git-reset`, but some things like
-`git status` and `git commit` are slightly more complex scripts around
+`git-status` and `git-commit` are slightly more complex scripts around
the basic git commands.
Many (most?) public remote repositories will not contain any of
followed by
----------------
-$ git-read-tree HEAD
+$ git read-tree HEAD
----------------
to populate the index. However, now you have populated the index, and
those, you'd check them out with
----------------
-$ git-checkout-index -u -a
+$ git checkout-index -u -a
----------------
where the `-u` flag means that you want the checkout to keep the index
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
-doing both `git-update-index hello` and `git commit` by just giving the
+doing both `git update-index hello` and `git commit` by just giving the
filename directly to `git commit`, with an `-i` flag (it tells
git to 'include' that file in addition to what you have done to
the index file so far when making the commit). The `-m` flag is to give the
environment, is `git show-branch`.
------------------------------------------------
-$ git-show-branch --topo-order --more=1 master mybranch
+$ git show-branch --topo-order --more=1 master mybranch
* [master] Merge work in mybranch
! [mybranch] Some work.
--
Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
-`git merge` to get the "upstream changes" back to your branch.
+`git-merge` to get the "upstream changes" back to your branch.
------------
$ git checkout mybranch
The command it uses is `git-merge-base`:
------------
-$ mb=$(git-merge-base HEAD mybranch)
+$ mb=$(git merge-base HEAD mybranch)
------------
The command writes the commit object name of the common ancestor
tell it by:
------------
-$ git-name-rev $mb
+$ git name-rev $mb
my-first-tag
------------
this:
------------
-$ git-read-tree -m -u $mb HEAD mybranch
+$ git read-tree -m -u $mb HEAD mybranch
------------
This is the same `git-read-tree` command we have already seen,
inspect the index file with this command:
------------
-$ git-ls-files --stage
+$ git ls-files --stage
100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
To look at only non-zero stages, use `\--unmerged` flag:
------------
-$ git-ls-files --unmerged
+$ git ls-files --unmerged
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
`git-merge-index` command:
------------
-$ git-merge-index git-merge-one-file hello
+$ git merge-index git-merge-one-file hello
Auto-merging hello.
merge: warning: conflicts during merge
ERROR: Merge conflict in hello.
--stage` again at this point:
------------
-$ git-ls-files --stage
+$ git ls-files --stage
100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
------------
This is the state of the index file and the working file after
-`git merge` returns control back to you, leaving the conflicting
+`git-merge` returns control back to you, leaving the conflicting
merge for you to resolve. Notice that the path `hello` is still
-unmerged, and what you see with `git diff` at this point is
+unmerged, and what you see with `git-diff` at this point is
differences since stage 2 (i.e. your version).
done only once.
[NOTE]
-`git push` uses a pair of programs,
+`git-push` uses a pair of programs,
`git-send-pack` on your local machine, and `git-receive-pack`
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
`.git`, we do things slightly differently:
------------
-$ GIT_DIR=my-git.git git-init
+$ GIT_DIR=my-git.git git init
------------
Make sure this directory is available for others you want your
If you plan to publish this repository to be accessed over http,
you should do `chmod +x my-git.git/hooks/post-update` at this
point. This makes sure that every time you push into this
-repository, `git-update-server-info` is run.
+repository, `git update-server-info` is run.
Your "public repository" is now ready to accept your changes.
Come back to the machine you have your private repository. From
3. Push into the public repository from your primary
repository.
-4. `git repack` the public repository. This establishes a big
+4. `git-repack` the public repository. This establishes a big
pack that contains the initial set of objects as the
- baseline, and possibly `git prune` if the transport
+ baseline, and possibly `git-prune` if the transport
used for pulling from your repository supports packed
repositories.
6. Push your changes to the public repository, and announce it
to the public.
-7. Every once in a while, "git repack" the public repository.
+7. Every once in a while, "git-repack" the public repository.
Go back to step 5. and continue working.
A recommended work cycle for a "subsystem maintainer" who works
on that project and has an own "public repository" goes like this:
-1. Prepare your work repository, by `git clone` the public
+1. Prepare your work repository, by `git-clone` the public
repository of the "project lead". The URL used for the
initial cloning is stored in the remote.origin.url
configuration variable.
point at the repository you are borrowing from.
4. Push into the public repository from your primary
- repository. Run `git repack`, and possibly `git prune` if the
+ repository. Run `git-repack`, and possibly `git-prune` if the
transport used for pulling from your repository supports
packed repositories.
"project lead" and possibly your "sub-subsystem
maintainers" to pull from it.
-7. Every once in a while, `git repack` the public repository.
+7. Every once in a while, `git-repack` the public repository.
Go back to step 5. and continue working.
not have a "public" repository is somewhat different. It goes
like this:
-1. Prepare your work repository, by `git clone` the public
+1. Prepare your work repository, by `git-clone` the public
repository of the "project lead" (or a "subsystem
maintainer", if you work on a subsystem). The URL used for
the initial cloning is stored in the remote.origin.url
index d65265835d7c322317dab598a2c839ed4c8be375..518d5d6d195bddc019df22e4409b23aed967e717 100644 (file)
[NOTE]
================================
The `pull` command knows where to get updates from because of certain
-configuration variables that were set by the first `git clone`
+configuration variables that were set by the first `git-clone`
command; see `git config -l` and the linkgit:git-config[1] man
page for details.
================================
------------------------------------------------
to "push" those commits to the shared repository. If someone else has
-updated the repository more recently, `git push`, like `cvs commit`, will
+updated the repository more recently, `git-push`, like `cvs commit`, will
complain, in which case you must pull any changes before attempting the
push again.
-In the `git push` command above we specify the name of the remote branch
-to update (`master`). If we leave that out, `git push` tries to update
+In the `git-push` command above we specify the name of the remote branch
+to update (`master`). If we leave that out, `git-push` tries to update
any branches in the remote repository that have the same name as a branch
in the local repository. So the last `push` can be done with either of:
index 4d56c85260b98de81d8db2e8281cb7d8efff4ea7..8f473d8e1121b4f46b07929080919a7f2bd7d744 100644 (file)
:100644 100644 bcd1234... 0123456... M junkfile
------------------------------------------------
-but the command invocation was "git-diff-files myfile", then the
+but the command invocation was "git diff-files myfile", then the
junkfile entry would be removed from the list because only "myfile"
is under consideration.
index 262a4f1626864c9dd4b180a2659336900412421c..6a0d098f7c71ec3d7aa7e066900e11f3c683c5d8 100644 (file)
post-merge
-----------
-This hook is invoked by `git-merge`, which happens when a `git pull`
+This hook is invoked by `git-merge`, which happens when a `git-pull`
is done on a local repository. The hook takes a single parameter, a status
flag specifying whether or not the merge being done was a squash merge.
This hook cannot affect the outcome of `git-merge` and is not executed,
-----------
This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
Just before starting to update refs on the remote repository, the
pre-receive hook is invoked. Its exit status determines the success
or failure of the update.
------
This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
is invoked. Its exit status determines the success or failure of
the ref update.
------------
This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
-----------
This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
index 2881c9cb92941a24d44d5a9f0d6a71cb06a01c23..812ae8336bf687da835dfc7cb0151b147b9b12f6 100644 (file)
An example:
--------------------------------------------------------------
- $ git-status
+ $ git status
[...]
# Untracked files:
[...]
*.html
# except foo.html which is maintained by hand
!foo.html
- $ git-status
+ $ git status
[...]
# Untracked files:
[...]
index 2afc5a3e885679b29fb72641e978252fb66bf983..e6b30cac45cbe2032c5722f0fb606d502d60b468 100644 (file)
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 keep
objects reachable from refs found in this directory and
its subdirectories.
branches::
A slightly deprecated way to store shorthands to be used
- to specify URL to `git fetch`, `git pull` and `git push`
+ 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.
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, they need to be made executable.
Read linkgit:githooks[5] for more details about
each hook.
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.
+ `git-fetch`, `git-pull` and `git-push` commands.
logs::
Records of changes made to refs are stored in this
index 2c5467057abbfc5af50e4450b869cfd03e4c9520..f2624aa22bb1943a5f04e436b7438c923c309a60 100644 (file)
The index file
--------------
-The primary tool we've been using to create commits is "git commit
+The primary tool we've been using to create commits is "git-commit
-a", which creates a commit including every change you've made to
your working tree. But what if you want to commit changes only to
certain files? Or only certain changes to certain files?
+hello world, again
------------------------------------------------
-So "git diff" is comparing against something other than the head.
+So "git-diff" is comparing against something other than the head.
The thing that it's comparing against is actually the index file,
which is stored in .git/index in a binary format, but whose contents
we can examine with ls-files:
hello world, again
------------------------------------------------
-So what our "git add" did was store a new blob and then put
+So what our "git-add" did was store a new blob and then put
a reference to it in the index file. If we modify the file again,
-we'll see that the new modifications are reflected in the "git diff"
+we'll see that the new modifications are reflected in the "git-diff"
output:
------------------------------------------------
+again?
------------------------------------------------
-With the right arguments, git diff can also show us the difference
+With the right arguments, git-diff can also show us the difference
between the working directory and the last commit, or between the
index and the last commit:
+hello world, again
------------------------------------------------
-At any time, we can create a new commit using "git commit" (without
+At any time, we can create a new commit using "git-commit" (without
the -a option), and verify that the state committed only includes the
changes stored in the index file, not the additional change that is
still only in our working tree:
+again?
------------------------------------------------
-So by default "git commit" uses the index to create the commit, not
+So by default "git-commit" uses the index to create the commit, not
the working tree; the -a option to commit tells it to first update
the index with all changes in the working tree.
-Finally, it's worth looking at the effect of "git add" on the index
+Finally, it's worth looking at the effect of "git-add" on the index
file:
------------------------------------------------
$ git add closing.txt
------------------------------------------------
-The effect of the "git add" was to add one entry to the index file:
+The effect of the "git-add" was to add one entry to the index file:
------------------------------------------------
$ git ls-files --stage
index 144bacd3debb2a9b87463a0b3dc7d38aa99f4df6..87e60379eb85b92dc10f033cb5230261e0f8a2e7 100644 (file)
This will again prompt you for a message describing the change, and then
record a new version of the project.
-Alternatively, instead of running `git add` beforehand, you can use
+Alternatively, instead of running `git-add` beforehand, you can use
------------------------------------------------
$ git commit -a
Many revision control systems provide an "add" command that tells the
system to start tracking changes to a new file. Git's "add" command
-does something simpler and more powerful: `git add` is used both for new
+does something simpler and more powerful: `git-add` is used both for new
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
the next commit.
------------------------------------------------
With this, Alice can perform the first operation alone using the
-"git fetch" command without merging them with her own branch,
+"git-fetch" command without merging them with her own branch,
using:
-------------------------------------
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with `git remote`, what was
+remote repository shorthand set up with `git-remote`, what was
fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-----------------
Git history is represented as a series of interrelated commits. We
-have already seen that the git log command can list those commits.
+have already seen that the git-log command can list those commits.
Note that first line of each git log entry also gives a name for the
commit:
merge-base: Clarify the comments on post processing.
-------------------------------------
-We can give this name to git show to see the details about this
+We can give this name to git-show to see the details about this
commit.
-------------------------------------
You can also give commits names of your own; after running
-------------------------------------
-$ git-tag v2.5 1b2e1d63ff
+$ git tag v2.5 1b2e1d63ff
-------------------------------------
you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
-commits, they will be lost. Also, don't use "git reset" on a
+commits, they will be lost. Also, don't use "git-reset" on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
If you need to undo changes that you have pushed, use linkgit:git-revert[1]
instead.
-The git grep command can search for strings in any version of your
+The git-grep command can search for strings in any version of your
project, so
-------------------------------------
searches for all occurrences of "hello" in v2.5.
-If you leave out the commit name, git grep will search any of the
+If you leave out the commit name, git-grep will search any of the
files it manages in your current directory. So
-------------------------------------
is a quick way to search just the files that are tracked by git.
Many git commands also take sets of commits, which can be specified
-in a number of ways. Here are some examples with git log:
+in a number of ways. Here are some examples with git-log:
-------------------------------------
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
# Makefile
-------------------------------------
-You can also give git log a "range" of commits where the first is not
+You can also give git-log a "range" of commits where the first is not
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
commit some time ago, then
will show the list of commits made on the stable branch but not
the experimental branch.
-The "git log" command has a weakness: it must present commits in a
+The "git-log" command has a weakness: it must present commits in a
list. When the history has lines of development that diverged and
-then merged back together, the order in which "git log" presents
+then merged back together, the order in which "git-log" presents
those commits is meaningless.
Most projects with multiple contributors (such as the linux kernel,
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use "git show" to see any such file:
+You can also use "git-show" to see any such file:
-------------------------------------
$ git show v2.5:Makefile
index 36ab37220457d4a992fcbe1fe32023ef75cce23c..ca13266b113c058af9eee3052a404521defee094 100644 (file)
did, and why.
Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA1 id", shown on the first line of the "git show" output. You can usually
+"SHA1 id", shown on the first line of the "git-show" output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
longer name can also be useful. Most importantly, it is a globally unique
name for this commit: so if you tell somebody else the object name (for
REVISIONS" section of linkgit:git-rev-parse[1].
[[Updating-a-repository-with-git-fetch]]
-Updating a repository with git fetch
+Updating a repository with git-fetch
------------------------------------
Eventually the developer cloned from will do additional work in her
-------------------------------------------------
New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave "git-remote add", in this case linux-nfs:
-------------------------------------------------
$ git branch -r
shows the difference between the working tree and the index file.
-Note that "git add" always adds just the current contents of a file
+Note that "git-add" always adds just the current contents of a file
to the index; further changes to the same file will be ignored unless
you run git-add on the file again.
A project will often generate files that you do 'not' want to track with git.
This typically includes files generated by a build process or temporary
backup files made by your editor. Of course, 'not' tracking files with git
-is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
+is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes
annoying to have these untracked files lying around; e.g. they make
"`git add .`" and "`git commit -a`" practically useless, and they keep
showing up in the output of "`git status`".
In the process of undoing a previous bad change, you may find it
useful to check out an older version of a particular file using
-linkgit:git-checkout[1]. We've used git checkout before to switch
+linkgit:git-checkout[1]. We've used git-checkout before to switch
branches, but it has quite different behavior if it is given a path
name: the command
===============================
[[getting-updates-with-git-pull]]
-Getting updates with git pull
+Getting updates with git-pull
-----------------------------
After you clone a repository and make a few changes of your own, you
Another way to submit changes to a project is to tell the maintainer
of that project to pull the changes from your repository using
linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
-Getting updates with git pull>>" we described this as a way to get
+Getting updates with git-pull>>" we described this as a way to get
updates from the "main" repository, but it works just as well in the
other direction.
them.
[[forcing-fetch]]
-Forcing git fetch to do non-fast-forward updates
+Forcing git-fetch to do non-fast-forward updates
------------------------------------------------
If git fetch fails because the new head of a branch is not a
$ git config remote.example.fetch +master:ref/remotes/example/master
-------------------------------------------------
-Don't do this unless you're sure you won't mind "git fetch" possibly
+Don't do this unless you're sure you won't mind "git-fetch" possibly
throwing away commits on mybranch.
Also note that all of the above configuration can be performed by
Assume the output looks like this:
------------------------------------------------
-$ git-fsck --full
+$ git fsck --full
broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
to blob 4b9458b3786228369c63936db65827de3cc06200
missing blob 4b9458b3786228369c63936db65827de3cc06200
NOTE: Do not use local URLs here if you plan to publish your superproject!
-See what files `git submodule` created:
+See what files `git-submodule` created:
-------------------------------------------------
$ ls -a
. .. .git .gitmodules a b c d
-------------------------------------------------
-The `git submodule add` command does a couple of things:
+The `git-submodule add` command does a couple of things:
- It clones the submodule under the current directory and by default checks out
the master branch.
$ git submodule init
-------------------------------------------------
-Now use `git submodule update` to clone the repositories and check out the
+Now use `git-submodule update` to clone the repositories and check out the
commits specified in the superproject:
-------------------------------------------------
. .. .git a.txt
-------------------------------------------------
-One major difference between `git submodule update` and `git submodule add` is
-that `git submodule update` checks out a specific commit, rather than the tip
+One major difference between `git-submodule update` and `git-submodule add` is
+that `git-submodule update` checks out a specific commit, rather than the tip
of a branch. It's like checking out a tag: the head is detached, so you're not
working on a branch.
index. Normal operation is just
-------------------------------------------------
-$ git-read-tree <sha1 of tree>
+$ git read-tree <sha1 of tree>
-------------------------------------------------
and your index file will now be equivalent to the tree that you saved
with
-------------------------------------------------
-$ git-checkout-index filename
+$ git checkout-index filename
-------------------------------------------------
or, if you want to check out all of the index, use `-a`.
state at the time of the commit, and a list of parents:
-------------------------------------------------
-$ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+$ git commit-tree <tree> -p <parent> [-p <parent2> ..]
-------------------------------------------------
and then giving the reason for the commit on stdin (either through
object:
-------------------------------------------------
-$ git-cat-file -t <objectname>
+$ git cat-file -t <objectname>
-------------------------------------------------
shows the type of the object, and once you have the type (which is
usually implicit in where you find the object), you can use
-------------------------------------------------
-$ git-cat-file blob|tree|commit|tag <objectname>
+$ git cat-file blob|tree|commit|tag <objectname>
-------------------------------------------------
to show its contents. NOTE! Trees have binary content, and as a result
you can do
-------------------------------------------------
-$ git-cat-file commit HEAD
+$ git cat-file commit HEAD
-------------------------------------------------
to see what the top commit was.
of two commits with
-------------------------------------------------
-$ git-merge-base <commit1> <commit2>
+$ git merge-base <commit1> <commit2>
-------------------------------------------------
which will return you the commit they are both based on. You should
do with (for example)
-------------------------------------------------
-$ git-cat-file commit <commitname> | head -1
+$ git cat-file commit <commitname> | head -1
-------------------------------------------------
since the tree object information is always the first line in a commit
To do the merge, do
-------------------------------------------------
-$ git-read-tree -m -u <origtree> <yourtree> <targettree>
+$ git read-tree -m -u <origtree> <yourtree> <targettree>
-------------------------------------------------
which will do all trivial merge operations for you directly in the
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
-You can examine such index state with `git-ls-files --unmerged`
+You can examine such index state with `git ls-files --unmerged`
command. An example:
------------------------------------------------
-$ git-read-tree -m $orig HEAD $target
-$ git-ls-files --unmerged
+$ git read-tree -m $orig HEAD $target
+$ git ls-files --unmerged
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
-Each line of the `git-ls-files --unmerged` output begins with
+Each line of the `git ls-files --unmerged` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
the blob objects from these three stages yourself, like this:
------------------------------------------------
-$ git-cat-file blob 263414f... >hello.c~1
-$ git-cat-file blob 06fa6a2... >hello.c~2
-$ git-cat-file blob cc44c73... >hello.c~3
+$ git cat-file blob 263414f... >hello.c~1
+$ git cat-file blob 06fa6a2... >hello.c~2
+$ git cat-file blob cc44c73... >hello.c~3
$ git merge-file hello.c~2 hello.c~1 hello.c~3
------------------------------------------------
-------------------------------------------------
$ mv -f hello.c~2 hello.c
-$ git-update-index hello.c
+$ git update-index hello.c
-------------------------------------------------
When a path is in unmerged state, running `git-update-index` for
stages to temporary files and calls a "merge" script on it:
-------------------------------------------------
-$ git-merge-index git-merge-one-file hello.c
+$ git merge-index git-merge-one-file hello.c
-------------------------------------------------
-and that is what higher level `git merge -s resolve` is implemented with.
+and that is what higher level `git-merge -s resolve` is implemented with.
[[hacking-git]]
Hacking git
If you are interested in more details of the revision walking process,
just have a look at the first implementation of `cmd_log()`; call
-`git-show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
+`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
no longer need to call `setup_pager()` directly).
Nowadays, `git log` is a builtin, which means that it is _contained_ in the
-----------------------------------
Sometimes, you do not know where to look for a feature. In many such cases,
-it helps to search through the output of `git log`, and then `git show` the
+it helps to search through the output of `git log`, and then `git-show` the
corresponding commit.
-Example: If you know that there was some test case for `git bundle`, but
+Example: If you know that there was some test case for `git-bundle`, but
do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
does not illustrate the point!):