git for CVS users

From: Junio C Hamano Date: Sun, 1 Jun 2008 08:26:34 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.6-rc0-52-g58124 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=054ea0856e4bbd375c55e9f5960693e0da914411;p=git.git Autogenerated HTML docs for v1.5.6-rc0-52-g58124 --- diff --git a/config.txt b/config.txt index c298dc21c..5331b450e 100644 --- a/config.txt +++ b/config.txt @@ -205,10 +205,13 @@ Can be overridden by the 'GIT_PROXY_COMMAND' environment variable handling). core.ignoreStat:: - The working copy files are assumed to stay unchanged until you - mark them otherwise manually - Git will not detect the file changes - by lstat() calls. This is useful on systems where those are very - slow, such as Microsoft Windows. See linkgit:git-update-index[1]. + If true, commands which modify both the working tree and the index + will mark the updated paths with the "assume unchanged" bit in the + index. These marked files are then assumed to stay unchanged in the + working copy, until you mark them otherwise manually - Git will not + detect the file changes by lstat() calls. This is useful on systems + where those are very slow, such as Microsoft Windows. + See linkgit:git-update-index[1]. False by default. core.preferSymlinkRefs:: diff --git a/core-tutorial.html b/core-tutorial.html index c18105825..c80262f31 100644 --- a/core-tutorial.html +++ b/core-tutorial.html @@ -1967,7 +1967,7 @@ to follow, not easier.

diff --git a/cvs-migration.html b/cvs-migration.html deleted file mode 100644 index 93ab28500..000000000 --- a/cvs-migration.html +++ /dev/null @@ -1,424 +0,0 @@ - - - - - - -git for CVS users - - - -

Git differs from CVS in that every working tree contains a repository with -a full copy of the project history, and no repository is inherently more -important than any other. However, you can emulate the CVS model by -designating a single shared repository which people can synchronize with; -this document explains how to do that.

Some basic familiarity with git is required. This -tutorial introduction to git and the -git glossary should be sufficient.

Developing against a shared repository

Suppose a shared repository is set up in /pub/repo.git on the host -foo.com. Then as an individual committer you can clone the shared -repository over ssh with:

$ git clone foo.com:/pub/repo.git/ my-project
-$ cd my-project

and hack away. The equivalent of cvs update is

$ git pull origin

which merges in any work that others might have done since the clone -operation. If there are uncommitted changes in your working tree, commit -them first before running git pull.

- - - -

Note

The pull command knows where to get updates from because of certain -configuration variables that were set by the first git clone -command; see git config -l and the git-config(1) man -page for details.

You can update the shared repository with your changes by first committing -your changes, and then using the git-push(1) command:

$ git push origin master

to "push" those commits to the shared repository. If someone else has -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 -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:

$ git push origin
-$ git push foo.com:/pub/project.git/

as long as the shared repository does not have any branches -other than master.

Setting Up a Shared Repository

We assume you have already created a git repository for your project, -possibly created from scratch or from a tarball (see the -tutorial), or imported from an already existing CVS -repository (see the next section).

Assume your existing repo is at /home/alice/myproject. Create a new "bare" -repository (a repository without a working tree) and fetch your project into -it:

$ mkdir /pub/my-repo.git
-$ cd /pub/my-repo.git
-$ git --bare init --shared
-$ git --bare fetch /home/alice/myproject master:master

Next, give every team member read/write access to this repository. One -easy way to do this is to give all the team members ssh access to the -machine where the repository is hosted. If you don't want to give them a -full shell on the machine, there is a restricted shell which only allows -users to do git pushes and pulls; see git-shell(1).

Put all the committers in the same group, and make the repository -writable by that group:

$ chgrp -R $group /pub/my-repo.git

Make sure committers have a umask of at most 027, so that the directories -they create are writable and searchable by other group members.

Importing a CVS archive

First, install version 2.1 or higher of cvsps from -http://www.cobite.com/cvsps/ and make -sure it is in your path. Then cd to a checked out CVS working directory -of the project you are interested in and run git-cvsimport(1):

$ git cvsimport -C <destination> <module>

This puts a git archive of the named CVS module in the directory -<destination>, which will be created if necessary.

The import checks out from CVS every revision of every file. Reportedly -cvsimport can average some twenty revisions per second, so for a -medium-sized project this should not take more than a couple of minutes. -Larger projects or remote repositories may take longer.

The main trunk is stored in the git branch named origin, and additional -CVS branches are stored in git branches with the same names. The most -recent version of the main trunk is also left checked out on the master -branch, so you can start adding your own changes right away.

The import is incremental, so if you call it again next month it will -fetch any CVS updates that have been made in the meantime. For this to -work, you must not modify the imported branches; instead, create new -branches for your own changes, and merge in the imported branches as -necessary.

Advanced Shared Repository Management

Git allows you to specify scripts called "hooks" to be run at certain -points. You can use these, for example, to send all commits to the shared -repository to a mailing list. See githooks(5)[Hooks used by git].

You can enforce finer grained permissions using update hooks. See -Controlling access to branches using -update hooks.

Providing CVS Access to a git Repository

It is also possible to provide true CVS access to a git repository, so -that developers can still use CVS; see git-cvsserver(1) for -details.

Alternative Development Models

CVS users are accustomed to giving a group of developers commit access to -a common repository. As we've seen, this is also possible with git. -However, the distributed nature of git allows other development models, -and you may want to first consider whether one of them might be a better -fit for your project.

For example, you can choose a single person to maintain the project's -primary public repository. Other developers then clone this repository -and each work in their own clone. When they have a series of changes that -they're happy with, they ask the maintainer to pull from the branch -containing the changes. The maintainer reviews their changes and pulls -them into the primary repository, which other developers pull from as -necessary to stay coordinated. The Linux kernel and other projects use -variants of this model.

With a small group, developers may just pull changes from each other's -repositories without the need for a central maintainer.

- - - diff --git a/diffcore.html b/diffcore.html index 11a9724d0..483b1942e 100644 --- a/diffcore.html +++ b/diffcore.html @@ -541,7 +541,7 @@ t diff --git a/everyday.html b/everyday.html index 147844db3..6e0e8abd2 100644 --- a/everyday.html +++ b/everyday.html @@ -1050,7 +1050,7 @@ upload to public HTTP server hosted by your ISP. diff --git a/git-add.html b/git-add.html index 3d177a78b..d1728720e 100644 --- a/git-add.html +++ b/git-add.html @@ -604,7 +604,7 @@ double-quote and control characters will still have problems.

diff --git a/git-am.html b/git-am.html index ba1302efe..c70f0b2c3 100644 --- a/git-am.html +++ b/git-am.html @@ -500,7 +500,7 @@ names.

diff --git a/git-annotate.html b/git-annotate.html index fdb1b2491..7b554d86b 100644 --- a/git-annotate.html +++ b/git-annotate.html @@ -454,7 +454,7 @@ commit.

diff --git a/git-apply.html b/git-apply.html index fb3f752ab..c0ae67ca4 100644 --- a/git-apply.html +++ b/git-apply.html @@ -604,7 +604,7 @@ subdirectory is checked and (if possible) updated.

diff --git a/git-applymbox.html b/git-applymbox.html deleted file mode 100644 index 15ef7a13f..000000000 --- a/git-applymbox.html +++ /dev/null @@ -1,408 +0,0 @@ - - - - - - -git-applymbox(1) - - - -

SYNOPSIS

git-applymbox [-u] [-k] [-q] [-m] ( -c .dotest/<num> | <mbox> ) [ <signoff> ]

DESCRIPTION

Splits mail messages in a mailbox into commit log message, -authorship information and patches, and applies them to the -current branch.

OPTIONS

--q -

- Apply patches interactively. The user will be given - opportunity to edit the log message and the patch before - attempting to apply it. -

--k -

- Usually the program cleans up the Subject: header line - to extract the title line for the commit log message, - among which (1) remove Re: or re:, (2) leading - 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. -

--m -

- Patches are applied with git-apply command, and unless - it cleanly applies without fuzz, the processing fails. - With this flag, if a tree that the patch applies cleanly - is found in a repository, the patch is applied to the - tree and then a 3-way merge between the resulting tree - and the current tree. -

--u -

- Pass -u flag to git-mailinfo (see git-mailinfo(1)). - The proposed commit log message taken from the e-mail - are re-coded into UTF-8 encoding (configuration variable - i18n.commitencoding can be used to specify project's - preferred encoding if it is not UTF-8). This used to be - optional but now it is the default. -

Note that the patch is always used as-is without charset -conversion, even with this flag.

--n -

- Pass -n flag to git-mailinfo (see - git-mailinfo(1)). -

--c .dotest/<num> -

- When the patch contained in an e-mail does not cleanly - apply, the command exits with an error message. The - patch and extracted message are found in .dotest/, and - you could re-run git applymbox with -c .dotest/<num> - flag to restart the process after inspecting and fixing - them. -

-<mbox> -

- The name of the file that contains the e-mail messages - with patches. This file should be in the UNIX mailbox - format. See SubmittingPatches document to learn about - the formatting convention for e-mail submission. -

-<signoff> -

- The name of the file that contains your "Signed-off-by" - line. See SubmittingPatches document to learn what - "Signed-off-by" line means. You can also just say - yes, true, me, or please to use an automatically - generated "Signed-off-by" line based on your committer - identity. -

Author

Written by Linus Torvalds <torvalds@osdl.org>

Documentation

Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-applypatch.html b/git-applypatch.html deleted file mode 100644 index f16f377a4..000000000 --- a/git-applypatch.html +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - -git-applypatch(1) - - - -

SYNOPSIS

git-applypatch <msg> <patch> <info> [<signoff>]

DESCRIPTION

This is usually not what an end user wants to run directly. See -git-am(1) instead.

Takes three files <msg>, <patch>, and <info> prepared from an -e-mail message by git-mailinfo, and creates a commit. It is -usually not necessary to use this command directly.

This command can run applypatch-msg, pre-applypatch, and -post-applypatch hooks. See hooks for more -information.

OPTIONS

-<msg> -: -
- Commit log message (sans the first line, which comes - from e-mail Subject stored in <info>). -
-
-<patch> -: -
- The patch to apply. -
-
-<info> -: -
- Author and subject information extracted from e-mail, - used on "author" line and as the first line of the - commit log message. -
-

Author

Written by Linus Torvalds <torvalds@osdl.org>

Documentation

Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-archimport.html b/git-archimport.html index 38715ef62..281d39766 100644 --- a/git-archimport.html +++ b/git-archimport.html @@ -422,7 +422,7 @@ patches that have been traded out-of-sequence between the branches.

diff --git a/git-archive.html b/git-archive.html index 3843276ac..a7ec75916 100644 --- a/git-archive.html +++ b/git-archive.html @@ -469,7 +469,7 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-d diff --git a/git-bisect.html b/git-bisect.html index 697f596c6..d1485498b 100644 --- a/git-bisect.html +++ b/git-bisect.html @@ -512,7 +512,7 @@ test processes and the scripts.

diff --git a/git-blame.html b/git-blame.html index 64b7fe0d3..a3ba6e941 100644 --- a/git-blame.html +++ b/git-blame.html @@ -686,7 +686,7 @@ commit commentary), a blame viewer won't ever care. diff --git a/git-branch.html b/git-branch.html index 17c047127..53f0526a1 100644 --- a/git-branch.html +++ b/git-branch.html @@ -613,7 +613,7 @@ but different purposes:

diff --git a/git-bundle.html b/git-bundle.html index 1a369c1ac..9fab1759a 100644 --- a/git-bundle.html +++ b/git-bundle.html @@ -484,7 +484,7 @@ network.

diff --git a/git-cat-file.html b/git-cat-file.html index 6b0614761..ff1ccc037 100644 --- a/git-cat-file.html +++ b/git-cat-file.html @@ -406,7 +406,7 @@ for each object specified on stdin that does not exist in the repository:

diff --git a/git-check-attr.html b/git-check-attr.html index 4fc0f1513..5fc817d9b 100644 --- a/git-check-attr.html +++ b/git-check-attr.html @@ -312,7 +312,7 @@ git-check-attr(1) Manual Page diff --git a/git-check-ref-format.html b/git-check-ref-format.html index 9c14aaafd..464441899 100644 --- a/git-check-ref-format.html +++ b/git-check-ref-format.html @@ -343,7 +343,7 @@ colon : is used as in srcref:dstref to mean "use srcref's diff --git a/git-checkout-index.html b/git-checkout-index.html index 3432d6bd7..e1ebd1aa4 100644 --- a/git-checkout-index.html +++ b/git-checkout-index.html @@ -511,7 +511,7 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.

diff --git a/git-checkout.html b/git-checkout.html index a594af5c8..01e323241 100644 --- a/git-checkout.html +++ b/git-checkout.html @@ -539,7 +539,7 @@ $ git add frotz diff --git a/git-cherry-pick.html b/git-cherry-pick.html index f9fbde56d..b87bf0ce2 100644 --- a/git-cherry-pick.html +++ b/git-cherry-pick.html @@ -383,7 +383,7 @@ effect to your working tree in a row.

diff --git a/git-cherry.html b/git-cherry.html index 0586a7bd7..33e086021 100644 --- a/git-cherry.html +++ b/git-cherry.html @@ -362,7 +362,7 @@ than pushing or pulling commits directly.

diff --git a/git-citool.html b/git-citool.html index 2aa572c3f..8c0192f94 100644 --- a/git-citool.html +++ b/git-citool.html @@ -297,7 +297,7 @@ See git-gui(1) for more details.

diff --git a/git-clean.html b/git-clean.html index aa14d2d8a..86e199c1e 100644 --- a/git-clean.html +++ b/git-clean.html @@ -353,7 +353,7 @@ affected are further limited to those that match them.

diff --git a/git-clone-pack.html b/git-clone-pack.html deleted file mode 100644 index bce5ade26..000000000 --- a/git-clone-pack.html +++ /dev/null @@ -1,356 +0,0 @@ - - - - - - -git-clone-pack(1) - - - -

SYNOPSIS

git-clone-pack [--exec=<git-upload-pack>] [<host>:]<directory> [<head>…]

DESCRIPTION

Clones a repository into the current repository by invoking -git-upload-pack, possibly on the remote host via ssh, in -the named repository, and stores the sent pack in the local -repository.

OPTIONS

---exec=<git-upload-pack> -

- Use this to specify the path to git-upload-pack on the - remote side, if it is not found on your $PATH. - Installations of sshd ignore the user's environment - setup scripts for login shells (e.g. .bash_profile) and - your privately installed git may not be found on the system - default $PATH. Another workaround suggested is to set - up your $PATH in ".bashrc", but this flag is for people - who do not want to pay the overhead for non-interactive - shells by having a lean .bashrc file (they set most of - the things up in .bash_profile). -

-<host> -

- A remote host that houses the repository. When this - part is specified, git-upload-pack is invoked via - ssh. -

-<directory> -

- The repository to sync from. -

-<head>… -

- The heads to update. This is relative to $GIT_DIR - (e.g. "HEAD", "refs/heads/master"). When unspecified, - all heads are updated to match the remote repository. -

Usually all the refs from existing repository are stored -under the same name in the new repository. Giving explicit -<head> arguments instead writes the object names and refs to -the standard output, just like get-fetch-pack does.

Author

Written by Linus Torvalds <torvalds@osdl.org>

Documentation

Documentation by Junio C Hamano.

GIT

Part of the git(7) suite

- - - diff --git a/git-clone.html b/git-clone.html index b39207b9c..7d33af6df 100644 --- a/git-clone.html +++ b/git-clone.html @@ -668,7 +668,7 @@ Create a repository on the kernel.org machine that borrows from Linus diff --git a/git-commit-tree.html b/git-commit-tree.html index 4eee6dc9c..8ebd33f3c 100644 --- a/git-commit-tree.html +++ b/git-commit-tree.html @@ -477,7 +477,7 @@ reversible operation.

diff --git a/git-commit.html b/git-commit.html index 19da70110..b227c59f3 100644 --- a/git-commit.html +++ b/git-commit.html @@ -746,7 +746,7 @@ Junio C Hamano <junkio@cox.net>

diff --git a/git-config.html b/git-config.html index 89a5c720c..a22b24283 100644 --- a/git-config.html +++ b/git-config.html @@ -930,10 +930,13 @@ core.ignoreStat

- The working copy files are assumed to stay unchanged until you - mark them otherwise manually - Git will not detect the file changes - by lstat() calls. This is useful on systems where those are very - slow, such as Microsoft Windows. See git-update-index(1). + If true, commands which modify both the working tree and the index + will mark the updated paths with the "assume unchanged" bit in the + index. These marked files are then assumed to stay unchanged in the + working copy, until you mark them otherwise manually - Git will not + detect the file changes by lstat() calls. This is useful on systems + where those are very slow, such as Microsoft Windows. + See git-update-index(1). False by default.

@@ -2589,7 +2592,7 @@ web.browser diff --git a/git-convert-objects.html b/git-convert-objects.html deleted file mode 100644 index a3483ae51..000000000 --- a/git-convert-objects.html +++ /dev/null @@ -1,299 +0,0 @@ - - - - - - -git-convert-objects(1) - - - -

SYNOPSIS

git-convert-objects

DESCRIPTION

Converts old-style git repository to the latest format

Author

Written by Linus Torvalds <torvalds@osdl.org>

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-count-objects.html b/git-count-objects.html index 4dab67d36..3375f9be0 100644 --- a/git-count-objects.html +++ b/git-count-objects.html @@ -309,7 +309,7 @@ them, to help you decide when it is a good time to repack.

diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html index 25fd0d051..920af796b 100644 --- a/git-cvsexportcommit.html +++ b/git-cvsexportcommit.html @@ -456,7 +456,7 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit diff --git a/git-cvsimport.html b/git-cvsimport.html index 11c1b8e49..7eff155a8 100644 --- a/git-cvsimport.html +++ b/git-cvsimport.html @@ -528,7 +528,7 @@ various participants of the git-list <git@vger.kernel.org>.

diff --git a/git-cvsserver.html b/git-cvsserver.html index 71cd46303..efd420436 100644 --- a/git-cvsserver.html +++ b/git-cvsserver.html @@ -726,7 +726,7 @@ Martin Langhoff <martin@catalyst.net.nz> diff --git a/git-daemon.html b/git-daemon.html index ad3e4bc8a..4f03a7c32 100644 --- a/git-daemon.html +++ b/git-daemon.html @@ -676,7 +676,7 @@ selectively enable/disable services per repository diff --git a/git-describe.html b/git-describe.html index b3b23973b..e163c4de0 100644 --- a/git-describe.html +++ b/git-describe.html @@ -462,7 +462,7 @@ updated by Shawn Pearce <spearce@spearce.org>.

diff --git a/git-diff-files.html b/git-diff-files.html index de0f0f969..907a823f7 100644 --- a/git-diff-files.html +++ b/git-diff-files.html @@ -1288,7 +1288,7 @@ the pathname, but if that is NUL, the record will show two paths.

diff --git a/git-diff-index.html b/git-diff-index.html index 1f62adbb0..10bd6ef40 100644 --- a/git-diff-index.html +++ b/git-diff-index.html @@ -1378,7 +1378,7 @@ always have the special all-zero sha1. diff --git a/git-diff-stages.html b/git-diff-stages.html deleted file mode 100644 index 0bbd9cf5b..000000000 --- a/git-diff-stages.html +++ /dev/null @@ -1,977 +0,0 @@ - - - - - - -git-diff-stages(1) - - - -

SYNOPSIS

git-diff-stages [<common diff options>] <stage1> <stage2> [<path>…]

DESCRIPTION

DEPRECATED and will be removed in 1.5.1.

Compares the content and mode of the blobs in two stages in an -unmerged index file.

OPTIONS

--p -: -
- Generate patch (see section on generating patches) -
-
--u -: -
- Synonym for "-p". -
-
---raw -: -
- Generate the raw format. -
-
---patch-with-raw -: -
- Synonym for "-p --raw". -
-
---stat[=width[,name-width]] -: -
- Generate a diffstat. You can override the default - output width for 80-column terminal by "--stat=width". - The width of the filename part can be controlled by - giving another width to it separated by a comma. -
-
---numstat -: -
- Similar to --stat, but shows number of added and - deleted lines in decimal notation and pathname without - abbreviation, to make it more machine friendly. For - binary files, outputs two - instead of saying - 0 0. -
-
---shortstat -: -
- Output only the last line of the --stat format containing total - number of modified files, as well as number of added and deleted - lines. -
-
---summary -: -
- Output a condensed summary of extended header information - such as creations, renames and mode changes. -
-
---patch-with-stat -: -
- Synonym for "-p --stat". -
-
--z -: -
- \0 line termination on output -
-
---name-only -: -
- Show only names of changed files. -
-
---name-status -: -
- Show only names and status of changed files. -
-
---color -: -
- Show colored diff. -
-
---no-color -: -
- Turn off colored diff, even when the configuration file - gives the default to color output. -
-
---color-words -: -
- Show colored word diff, i.e. color words which have changed. -
-
---no-renames -: -
- Turn off rename detection, even when the configuration - file gives the default to do so. -
-
---check -: -
- Warn if changes introduce trailing whitespace - or an indent that uses a space before a tab. -
-
---full-index -: -
- Instead of the first handful characters, show full - object name of pre- and post-image blob on the "index" - line when generating a patch format output. -
-
---binary -: -
- In addition to --full-index, output "binary diff" that - can be applied with "git apply". -
-
---abbrev[=<n>] -: -
- Instead of showing the full 40-byte hexadecimal object - name in diff-raw format output and diff-tree header - lines, show only handful hexdigits prefix. This is - independent of --full-index option above, which controls - the diff-patch output format. Non default number of - digits can be specified with --abbrev=<n>. -
-
--B -: -
- Break complete rewrite changes into pairs of delete and create. -
-
--M -: -
- Detect renames. -
-
--C -: -
- Detect copies as well as renames. -
-
---diff-filter=[ACDMRTUXB*] -: -
- Select only files that are Added (A), Copied (C), - Deleted (D), Modified (M), Renamed (R), have their - type (mode) changed (T), are Unmerged (U), are - Unknown (X), or have had their pairing Broken (B). - Any combination of the filter characters may be used. - When * (All-or-none) is added to the combination, all - paths are selected if there is any file that matches - other criteria in the comparison; if there is no file - that matches other criteria, nothing is selected. -
-
---find-copies-harder -: -
- For performance reasons, by default, -C option finds copies only - if the original file of the copy was modified in the same - changeset. This flag makes the command - inspect unmodified files as candidates for the source of - copy. This is a very expensive operation for large - projects, so use it with caution. -
-
--l<num> -: -
- -M and -C options require O(n^2) processing time where n - is the number of potential rename/copy targets. This - option prevents rename/copy detection from running if - the number of rename/copy targets exceeds the specified - number. -
-
--S<string> -: -
- Look for differences that contain the change in <string>. -
-
---pickaxe-all -: -
- When -S finds a change, show all the changes in that - changeset, not just the files that contain the change - in <string>. -
-
---pickaxe-regex -: -
- Make the <string> not a plain string but an extended POSIX - regex to match. -
-
--O<orderfile> -: -
- Output the patch in the order specified in the - <orderfile>, which has one shell glob pattern per line. -
-
--R -: -
- Swap two inputs; that is, show differences from index or - on-disk file to tree contents. -
-
---text -: -
- Treat all files as text. -
-
--a -: -
- Shorthand for "--text". -
-
---ignore-space-change -: -
- Ignore changes in amount of white space. This ignores white - space at line end, and consider all other sequences of one or - more white space characters to be equivalent. -
-
--b -: -
- Shorthand for "--ignore-space-change". -
-
---ignore-all-space -: -
- Ignore white space when comparing lines. This ignores - difference even if one line has white space where the other - line has none. -
-
--w -: -
- Shorthand for "--ignore-all-space". -
-

For more detailed explanation on these common options, see also -diffcore documentation.

-<stage1>,<stage2> -: -
- The stage number to be compared. -
-

Output format

The output format from "git-diff-index", "git-diff-tree" and -"git-diff-files" are very similar.

These commands all compare two sets of things; what is -compared differs:

-git-diff-index <tree-ish> -: -
- compares the <tree-ish> and the files on the filesystem. -
-
-git-diff-index --cached <tree-ish> -: -
- compares the <tree-ish> and the index. -
-
-git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…] -: -
- compares the trees named by the two arguments. -
-
-git-diff-files [<pattern>…] -: -
- compares the index and the files on the filesystem. -
-

An output line is formatted this way:

in-place edit  :100644 100644 bcd1234... 0123456... M file0
-copy-edit      :100644 100644 abcd123... 1234567... C68 file1 file2
-rename-edit    :100644 100644 abcd123... 1234567... R86 file1 file3
-create         :000000 100644 0000000... 1234567... A file4
-delete         :100644 000000 1234567... 0000000... D file5
-unmerged       :000000 000000 0000000... 0000000... U file6

That is, from the left to the right:

-
-a colon. -
-
-
-mode for "src"; 000000 if creation or unmerged. -
-
-
-a space. -
-
-
-mode for "dst"; 000000 if deletion or unmerged. -
-
-
-a space. -
-
-
-sha1 for "src"; 0{40} if creation or unmerged. -
-
-
-a space. -
-
-
-sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". -
-
-
-a space. -
-
-
-status, followed by optional "score" number. -
-
-
-a tab or a NUL when -z option is used. -
-
-
-path for "src" -
-
-
-a tab or a NUL when -z option is used; only exists for C or R. -
-
-
-path for "dst"; only exists for C or R. -
-
-
-an LF or a NUL when -z option is used, to terminate the record. -
-

<sha1> is shown as all 0's if a file is new on the filesystem -and it is out of sync with the index.

Example:

:100644 100644 5be4a4...... 000000...... M file.c

When -z option is not used, TAB, LF, and backslash characters -in pathnames are represented as \t, \n, and \\, -respectively.

Generating patches with -p

When "git-diff-index", "git-diff-tree", or "git-diff-files" are run -with a -p option, they do not produce the output described above; -instead they produce a patch file. You can customize the creation -of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS -environment variables.

What the -p option produces is slightly different from the traditional -diff format.

-
-It is preceded with a "git diff" header, that looks like - this: -
-
-
-
```
diff --git a/file1 b/file2
```
-
-
The a/ and b/ filenames are the same unless rename/copy is -involved. Especially, even for a creation or a deletion, -/dev/null is _not_ used in place of a/ or b/ filenames.
-
When rename/copy is involved, file1 and file2 show the -name of the source file of the rename/copy and the name of -the file that rename/copy produces, respectively.
-

-It is followed by one or more extended header lines: -

old mode <mode>
-new mode <mode>
-deleted file mode <mode>
-new file mode <mode>
-copy from <path>
-copy to <path>
-rename from <path>
-rename to <path>
-similarity index <number>
-dissimilarity index <number>
-index <hash>..<hash> <mode>

-
-TAB, LF, double quote and backslash characters in pathnames - are represented as \t, \n, \" and \\, respectively. - If there is need for such substitution then the whole - pathname is put in double quotes. -
-

combined diff format

git-diff-tree and git-diff-files can take -c or --cc option -to produce combined diff, which looks like this:

diff --combined describe.c
-index fabadb8,cc95eb0..4866510
---- a/describe.c
-+++ b/describe.c
-@@@ -98,20 -98,12 +98,20 @@@
-        return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
-  }
-
-- static void describe(char *arg)
- -static void describe(struct commit *cmit, int last_one)
-++static void describe(char *arg, int last_one)
-  {
- +      unsigned char sha1[20];
- +      struct commit *cmit;
-        struct commit_list *list;
-        static int initialized = 0;
-        struct commit_name *n;
-
- +      if (get_sha1(arg, sha1) < 0)
- +              usage(describe_usage);
- +      cmit = lookup_commit_reference(sha1);
- +      if (!cmit)
- +              usage(describe_usage);
- +
-        if (!initialized) {
-                initialized = 1;
-                for_each_ref(get_name);

-
-It is preceded with a "git diff" header, that looks like - this (when -c option is used): -
-
-
-
```
diff --combined file
```
-
-
or like this (when --cc option is used):
-
-
-
```
diff --c file
```
-
-
-
-It is followed by one or more extended header lines - (this example shows a merge with two parents): -
-
-
-
```
index <hash>,<hash>..<hash>
-mode <mode>,<mode>..<mode>
-new file mode <mode>
-deleted file mode <mode>,<mode>
```
-
-
The mode <mode>,<mode>..<mode> line appears only if at least one of -the <mode> is different from the rest. Extended headers with -information about detected contents movement (renames and -copying detection) are designed to work with diff of two -<tree-ish> and are not used by combined diff format.
-
-
-It is followed by two-line from-file/to-file header -
-
-
-
```
--- a/file
-+++ b/file
```
-
-
Similar to two-line header for traditional unified diff -format, /dev/null is used to signal created or deleted -files.
-
-
-Chunk header format is modified to prevent people from - accidentally feeding it to patch -p1. Combined diff format - was created for review of merge commit changes, and was not - meant for apply. The change is similar to the change in the - extended index header: -
-
-
-
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
-
-
There are (number of parents + 1) @ characters in the chunk -header for combined diff format.
-

Unlike the traditional unified diff format, which shows two -files A and B with a single column that has - (minus — -appears in A but removed in B), + (plus — missing in A but -added to B), or " " (space — unchanged) prefix, this format -compares two or more files file1, file2,… with one file X, and -shows how X differs from each of fileN. One column for each of -fileN is prepended to the output line to note how X's line is -different from it.

A - character in the column N means that the line appears in -fileN but it does not appear in the result. A + character -in the column N means that the line appears in the last file, -and fileN does not have that line (in other words, the line was -added, from the point of view of that parent).

In the above example output, the function signature was changed -from both files (hence two - removals from both file1 and -file2, plus ++ to mean one line that was added does not appear -in either file1 nor file2). Also two other lines are the same -from file1 but do not appear in file2 (hence prefixed with +).

When shown by git diff-tree -c, it compares the parents of a -merge commit with the merge result (i.e. file1..fileN are the -parents). When shown by git diff-files -c, it compares the -two unresolved merge parents with the working tree file -(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka -"their version").

Author

Written by Junio C Hamano <junkio@cox.net>

Documentation

Documentation by Junio C Hamano.

GIT

Part of the git(7) suite

- - - diff --git a/git-diff-tree.html b/git-diff-tree.html index 08baf7fde..ba2dd8fdd 100644 --- a/git-diff-tree.html +++ b/git-diff-tree.html @@ -1773,7 +1773,7 @@ the pathname, but if that is NUL, the record will show two paths.

diff --git a/git-diff.html b/git-diff.html index 584b8f7ec..009e73037 100644 --- a/git-diff.html +++ b/git-diff.html @@ -1493,7 +1493,7 @@ Output diff in reverse. diff --git a/git-fast-export.html b/git-fast-export.html index 6ab6271ab..11b8e4304 100644 --- a/git-fast-export.html +++ b/git-fast-export.html @@ -351,7 +351,7 @@ a tag referencing a tree instead of a commit.

diff --git a/git-fast-import.html b/git-fast-import.html index 36570ca62..20f5fe48c 100644 --- a/git-fast-import.html +++ b/git-fast-import.html @@ -1416,7 +1416,7 @@ memory footprint (less than 2.7 MiB per active branch).

diff --git a/git-fetch-pack.html b/git-fetch-pack.html index a48f07b37..227a932fe 100644 --- a/git-fetch-pack.html +++ b/git-fetch-pack.html @@ -431,7 +431,7 @@ have a common ancestor commit.

diff --git a/git-fetch.html b/git-fetch.html index a9c34389e..eaa393ca2 100644 --- a/git-fetch.html +++ b/git-fetch.html @@ -402,7 +402,9 @@ branches you are not interested in, you will not get them.

The "remote" repository that is the source of a fetch - or pull operation. See the section GIT URLS below. + or pull operation. This parameter can be either a URL + (see the section GIT URLS below) or the name + of a remote (see the section REMOTES below).

@@ -613,11 +615,51 @@ configuration section of the form:

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

REMOTES

In addition to the above, as a short-hand, the name of a -file in $GIT_DIR/remotes directory can be given; the -named file should be in the following format:

The name of one of the following can be used instead +of a URL as <repository> argument:

+
+a remote in the git configuration file: $GIT_DIR/config, +
+
+
+a file in the $GIT_DIR/remotes directory, or +
+
+
+a file in the $GIT_DIR/branches directory. +
+

All of these also allow you to omit the refspec from the command line +because they each contain a refspec which git will use by default.

Named remote in configuration file

You can choose to provide the name of a remote which you had previously +configured using git-remote(1), git-config(1) +or even by a manual edit to the $GIT_DIR/config file. The URL of +this remote will be used to access the repository. The refspec +of this remote will be used by default when you do +not provide a refspec on the command line. The entry in the +config file would appear like this:

        [remote "<name>"]
+                url = <url>
+                push = <refspec>
+                fetch = <refspec>

Named file in `$GIT_DIR/remotes`

You can choose to provide the name of a +file in $GIT_DIR/remotes. The URL +in this file will be used to access the repository. The refspec +in this file will be used as default when you do not +provide a refspec on the command line. This file should have the +following format:

        URL: one of the above URL format
@@ -625,41 +667,27 @@ named file should be in the following format:
         Pull: <refspec>

Then such a short-hand is specified in place of -<repository> without <refspec> parameters on the command -line, <refspec> specified on Push: lines or Pull: -lines are used for git-push and git-fetch/git-pull, -respectively. Multiple Push: and Pull: lines may +

Push: lines are used by git-push and +Pull: lines are used by git-pull and git-fetch. +Multiple Push: and Pull: lines may be specified for additional branch mappings.

Or, equivalently, in the $GIT_DIR/config (note the use -of fetch instead of Pull:):

Named file in `$GIT_DIR/branches`

You can choose to provide the name of a +file in $GIT_DIR/branches. +The URL in this file will be used to access the repository. +This file should have the following format:

        [remote "<remote>"]
-                url = <url>
-                push = <refspec>
-                fetch = <refspec>
-

The name of a file in $GIT_DIR/branches directory can be -specified as an older notation short-hand; the named -file should contain a single line, a URL in one of the -above formats, optionally followed by a hash # and the -name of remote head (URL fragment notation). -$GIT_DIR/branches/<remote> file that stores a <url> -without the fragment is equivalent to have this in the -corresponding file in the $GIT_DIR/remotes/ directory.

        URL: <url>
-        Pull: refs/heads/master:<remote>
-

        <url>#<head>

while having <url>#<head> is equivalent to

<url> is required; #<head> is optional. +When you do not provide a refspec on the command line, +git will use the following refspec, where <head> defaults to master, +and <repository> is the name of this file +you provided in the command line.

        URL: <url>
-        Pull: refs/heads/<head>:<remote>

        refs/heads/<head>:<repository>

SYNOPSIS

git-local-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] - commit-id path

DESCRIPTION

THIS COMMAND IS DEPRECATED.

Duplicates another git repository on a local system.

OPTIONS

--c -

- Get the commit objects. -

--t -

- Get trees associated with the commit objects. -

--a -

- Get all the objects. -

--v -

- Report what is downloaded. -

--s -

- Instead of regular file-to-file copying use symbolic links to the objects - in the remote repository. -

--l -

- Before attempting symlinks (if -s is specified) or file-to-file copying the - remote objects, try to hardlink the remote objects into the local - repository. -

--n -

- Never attempt to file-to-file copy remote objects. Only useful with - -s or -l command-line options. -

--w <filename> -

- Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on - the local end after the transfer is complete. -

---stdin -

- Instead of a commit id on the command line (which is not expected in this - case), git-local-fetch expects lines on stdin in the format -

<commit-id>['\t'<filename-as-in--w>]

---recover -

- Verify that everything reachable from target is fetched. Used after - an earlier fetch is interrupted. -

Author

Written by Junio C Hamano <junkio@cox.net>

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-log.html b/git-log.html index 3c4658d4d..b48e87724 100644 --- a/git-log.html +++ b/git-log.html @@ -1951,7 +1951,7 @@ reversible operation.

diff --git a/git-lost-found.html b/git-lost-found.html index 9b08249f4..09650af23 100644 --- a/git-lost-found.html +++ b/git-lost-found.html @@ -340,7 +340,7 @@ $ git rev-parse not-lost-anymore diff --git a/git-ls-files.html b/git-ls-files.html index 897e66494..6cbe9458c 100644 --- a/git-ls-files.html +++ b/git-ls-files.html @@ -626,7 +626,7 @@ pattern file appears in.

diff --git a/git-ls-remote.html b/git-ls-remote.html index 5a68bb281..4c0a4c4c1 100644 --- a/git-ls-remote.html +++ b/git-ls-remote.html @@ -361,7 +361,7 @@ c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 diff --git a/git-ls-tree.html b/git-ls-tree.html index a19f7c89f..4972222e3 100644 --- a/git-ls-tree.html +++ b/git-ls-tree.html @@ -416,7 +416,7 @@ another major rewrite by Linus Torvalds <torvalds@osdl.org>

diff --git a/git-mailinfo.html b/git-mailinfo.html index 90f7234aa..92e069316 100644 --- a/git-mailinfo.html +++ b/git-mailinfo.html @@ -357,7 +357,7 @@ Junio C Hamano <junkio@cox.net>

diff --git a/git-mailsplit.html b/git-mailsplit.html index 40cafa3ad..14315dcdd 100644 --- a/git-mailsplit.html +++ b/git-mailsplit.html @@ -362,7 +362,7 @@ and Junio C Hamano <junkio@cox.net>

diff --git a/git-merge-base.html b/git-merge-base.html index 6ba602d97..f5a668e28 100644 --- a/git-merge-base.html +++ b/git-merge-base.html @@ -312,7 +312,7 @@ relied on to decide in any particular way.

diff --git a/git-merge-file.html b/git-merge-file.html index 4626e7df3..ac9f27c35 100644 --- a/git-merge-file.html +++ b/git-merge-file.html @@ -377,7 +377,7 @@ with parts copied from the original documentation of RCS merge.

diff --git a/git-merge-index.html b/git-merge-index.html index f8ce82b02..763413bae 100644 --- a/git-merge-index.html +++ b/git-merge-index.html @@ -372,7 +372,7 @@ One-shot merge by Petr Baudis <pasky@ucw.cz>

diff --git a/git-merge-one-file.html b/git-merge-one-file.html index 2bda0b361..d22fa3c1d 100644 --- a/git-merge-one-file.html +++ b/git-merge-one-file.html @@ -294,7 +294,7 @@ Junio C Hamano <junkio@cox.net> and Petr Baudis <pasky@suse.cz>.

diff --git a/git-merge-tree.html b/git-merge-tree.html index 01a3aa0a8..209da2d6c 100644 --- a/git-merge-tree.html +++ b/git-merge-tree.html @@ -300,7 +300,7 @@ entries that match <branch1> tree.

diff --git a/git-merge.html b/git-merge.html index 02a154c00..ba283a553 100644 --- a/git-merge.html +++ b/git-merge.html @@ -749,7 +749,7 @@ Resolve the conflicts. git-diff would report only the diff --git a/git-mergetool.html b/git-mergetool.html index e4d4704a1..e78a596fc 100644 --- a/git-mergetool.html +++ b/git-mergetool.html @@ -340,7 +340,7 @@ success of the resolution after the custom tool has exited.

diff --git a/git-mktag.html b/git-mktag.html index e2d293471..31bb98b71 100644 --- a/git-mktag.html +++ b/git-mktag.html @@ -310,7 +310,7 @@ care about, but that can be verified with gpg.

diff --git a/git-mktree.html b/git-mktree.html index 202e23450..fa985788d 100644 --- a/git-mktree.html +++ b/git-mktree.html @@ -307,7 +307,7 @@ built is written to the standard output.

diff --git a/git-mv.html b/git-mv.html index 3c6993be0..74c706d74 100644 --- a/git-mv.html +++ b/git-mv.html @@ -337,7 +337,7 @@ Move functionality added by Josef Weidendorfer <Josef.Weidendorfer@gmx.de> diff --git a/git-name-rev.html b/git-name-rev.html index c9212413f..8b4945eb8 100644 --- a/git-name-rev.html +++ b/git-name-rev.html @@ -364,7 +364,7 @@ not the context.

diff --git a/git-p4import.html b/git-p4import.html deleted file mode 100644 index 23be6c4d3..000000000 --- a/git-p4import.html +++ /dev/null @@ -1,470 +0,0 @@ - - - - - - -git-p4import(1) - - - -

SYNOPSIS

git-p4import [-q|-v] [--notags] [--authors <file>] [-t <timezone>] - <//p4repo/path> <branch> -git-p4import --stitch <//p4repo/path> -git-p4import

DESCRIPTION

Import a Perforce repository into an existing git repository. When -a <//p4repo/path> and <branch> are specified a new branch with the -given name will be created and the initial import will begin.

Once the initial import is complete you can do an incremental import -of new commits from the Perforce repository. You do this by checking -out the appropriate git branch and then running git-p4import without -any options.

The standard p4 client is used to communicate with the Perforce -repository; it must be configured correctly in order for git-p4import -to operate (see below).

OPTIONS

--q -: -
- Do not display any progress information. -
-
--v -: -
- Give extra progress information. -
-
---authors -: -
- Specify an authors file containing a mapping of Perforce user - ids to full names and email addresses (see Notes below). -
-
---notags -: -
- Do not create a tag for each imported commit. -
-
---stitch -: -
- Import the contents of the given perforce branch into the - currently checked out git branch. -
-
---log -: -
- Store debugging information in the specified file. -
-
--t -: -
- Specify that the remote repository is in the specified timezone. - Timezone must be in the format "US/Pacific" or "Europe/London" - etc. You only need to specify this once, it will be saved in - the git config file for the repository. -
-
-<//p4repo/path> -: -
- The Perforce path that will be imported into the specified branch. -
-
-<branch> -: -
- The new branch that will be created to hold the Perforce imports. -
-

P4 Client

You must make the p4 client command available in your $PATH and -configure it to communicate with the target Perforce repository. -Typically this means you must set the "$P4PORT" and "$P4CLIENT" -environment variables.

You must also configure a p4 client "view" which maps the Perforce -branch into the top level of your git repository, for example:

Client: myhost
-
-Root:   /home/sean/import
-
-Options:   noallwrite clobber nocompress unlocked modtime rmdir
-
-View:
-        //public/jam/... //myhost/jam/...

With the above p4 client setup, you could import the "jam" -perforce branch into a branch named "jammy", like so:

$ mkdir -p /home/sean/import/jam
-$ cd /home/sean/import/jam
-$ git init
-$ git p4import //public/jam jammy

Multiple Branches

Note that by creating multiple "views" you can use git-p4import -to import additional branches into the same git repository. -However, the p4 client has a limitation in that it silently -ignores all but the last "view" that maps into the same local -directory. So the following will not work:

View:
-        //public/jam/... //myhost/jam/...
-        //public/other/... //myhost/jam/...
-        //public/guest/... //myhost/jam/...

If you want more than one Perforce branch to be imported into the -same directory you must employ a workaround. A simple option is -to adjust your p4 client before each import to only include a -single view.

Another option is to create multiple symlinks locally which all -point to the same directory in your git repository and then use -one per "view" instead of listing the actual directory.

Notes

You can interrupt the import (e.g. ctrl-c) at any time and restart it -without worry.

Author information is automatically determined by querying the -Perforce "users" table using the id associated with each change. -However, if you want to manually supply these mappings you can do -so with the "--authors" option. It accepts a file containing a list -of mappings with each line containing one mapping in the format:

    perforce_id = Full Name <email@address.com>

Author

Written by Sean Estabrooks <seanlkml@sympatico.ca>

GIT

Part of the git(7) suite

- - - diff --git a/git-pack-objects.html b/git-pack-objects.html index 93e810953..6480c308c 100644 --- a/git-pack-objects.html +++ b/git-pack-objects.html @@ -577,7 +577,7 @@ base-name diff --git a/git-pack-redundant.html b/git-pack-redundant.html index c188b176f..65821cb57 100644 --- a/git-pack-redundant.html +++ b/git-pack-redundant.html @@ -335,7 +335,7 @@ objects.

diff --git a/git-pack-refs.html b/git-pack-refs.html index 7b68535bb..d45fa23a4 100644 --- a/git-pack-refs.html +++ b/git-pack-refs.html @@ -336,7 +336,7 @@ hierarchy after packing them. This option tells it not to. diff --git a/git-parse-remote.html b/git-parse-remote.html index 9f9857434..5013c4846 100644 --- a/git-parse-remote.html +++ b/git-parse-remote.html @@ -326,7 +326,7 @@ get_remote_refs_for_push diff --git a/git-patch-id.html b/git-patch-id.html index 9200c231c..d93e52340 100644 --- a/git-patch-id.html +++ b/git-patch-id.html @@ -314,7 +314,7 @@ This can be used to make a mapping from patch ID to commit ID.

diff --git a/git-peek-remote.html b/git-peek-remote.html index ec101996f..9eb82044f 100644 --- a/git-peek-remote.html +++ b/git-peek-remote.html @@ -332,7 +332,7 @@ git-peek-remote(1) Manual Page diff --git a/git-pickaxe.html b/git-pickaxe.html deleted file mode 100644 index 877962243..000000000 --- a/git-pickaxe.html +++ /dev/null @@ -1,516 +0,0 @@ - - - - - - -git-pickaxe(1) - - - -

SYNOPSIS

git-pickaxe [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] - [-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>

DESCRIPTION

Annotates each line in the given file with information from the revision which -last modified the line. Optionally, start annotating from the given revision.

Also it can limit the range of lines annotated.

This report doesn't tell you anything about lines which have been deleted or -replaced; you need to use a tool such as git-diff(1) or the "pickaxe" -interface briefly mentioned in the following paragraph.

Apart from supporting file annotation, git also supports searching the -development history for when a code snippet occured in a change. This makes it -possible to track when a code snippet was added to a file, moved or copied -between files, and eventually deleted or replaced. It works by searching for -a text string in the diff. A small example:

$ git log --pretty=oneline -S'blame_usage'
-5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
-ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPTIONS

--c, --compatibility -: -
- Use the same output mode as git-annotate(1) (Default: off). -
-
--L n,m -: -
- Annotate only the specified line range (lines count from 1). -
-
--l, --long -: -
- Show long rev (Default: off). -
-
--t, --time -: -
- Show raw timestamp (Default: off). -
-
--S, --rev-file <revs-file> -: -
- Use revs from revs-file instead of calling git-rev-list(1). -
-
--f, --show-name -: -
- Show filename in the original commit. By default - filename is shown if there is any line that came from a - file with different name, due to rename detection. -
-
--n, --show-number -: -
- Show line number in the original commit (Default: off). -
-
--p, --porcelain -: -
- Show in a format designed for machine consumption. -
-
--M -: -
- Detect moving lines in the file as well. When a commit - moves a block of lines in a file (e.g. the original file - has A and then B, and the commit changes it to B and - then A), traditional blame algorithm typically blames - the lines that were moved up (i.e. B) to the parent and - assigns blame to the lines that were moved down (i.e. A) - to the child commit. With this option, both groups of - lines are blamed on the parent. -
-
--C -: -
- In addition to -M, detect lines copied from other - files that were modified in the same commit. This is - useful when you reorganize your program and move code - around across files. When this option is given twice, - the command looks for copies from all other files in the - parent for the commit that creates the file in addition. -
-
--h, --help -: -
- Show help message. -
-

THE PORCELAIN FORMAT

In this format, each line is output after a header; the -header at the minumum has the first line which has:

-
-40-byte SHA-1 of the commit the line is attributed to; -
-
-
-the line number of the line in the original file; -
-
-
-the line number of the line in the final file; -
-
-
-on a line that starts a group of line from a different - commit than the previous one, the number of lines in this - group. On subsequent lines this field is absent. -
-

This header line is followed by the following information -at least once for each commit:

-
-author name ("author"), email ("author-mail"), time - ("author-time"), and timezone ("author-tz"); similarly - for committer. -
-
-
-filename in the commit the line is attributed to. -
-
-
-the first line of the commit log message ("summary"). -
-

The contents of the actual line is output after the above -header, prefixed by a TAB. This is to allow adding more -header elements later.

SPECIFIYING RANGES

Unlike git-blame and git-annotate in older git, the extent -of annotation can be limited to both line ranges and revision -ranges. When you are interested in finding the origin for -ll. 40-60 for file foo, you can use -L option like this:

git pickaxe -L 40,60 foo

When you are not interested in changes older than the version -v2.6.18, or changes older than 3 weeks, you can use revision -range specifiers similar to git-rev-list:

git pickaxe v2.6.18.. -- foo
-git pickaxe --since=3.weeks -- foo

When revision range specifiers are used to limit the annotation, -lines that have not changed since the range boundary (either the -commit v2.6.18 or the most recent commit that is more than 3 -weeks old in the above example) are blamed for that range -boundary commit.

A particularly useful way is to see if an added file have lines -created by copy-and-paste from existing files. Sometimes this -indicates that the developer was being sloppy and did not -refactor the code properly. You can first find the commit that -introduced the file with:

git log --diff-filter=A --pretty=short -- foo

and then annotate the change between the commit and its -parents, using commit^! notation:

git pickaxe -C -C -f $commit^! -- foo

AUTHOR

Written by Junio C Hamano <junkio@cox.net>

GIT

Part of the git(7) suite

- - - diff --git a/git-prune-packed.html b/git-prune-packed.html index 0bbd9a607..cdddb8c10 100644 --- a/git-prune-packed.html +++ b/git-prune-packed.html @@ -325,7 +325,7 @@ disk storage, etc.

diff --git a/git-prune.html b/git-prune.html index a79f10289..1c2cebdda 100644 --- a/git-prune.html +++ b/git-prune.html @@ -373,7 +373,7 @@ git-fsck's --unreachable option.

diff --git a/git-pull.html b/git-pull.html index 1b46fa875..457e85f3f 100644 --- a/git-pull.html +++ b/git-pull.html @@ -543,7 +543,9 @@ unless you have read git-rebase(1) carefully.

@@ -754,11 +756,51 @@ configuration section of the form:

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

REMOTES

In addition to the above, as a short-hand, the name of a -file in $GIT_DIR/remotes directory can be given; the -named file should be in the following format:

The name of one of the following can be used instead +of a URL as <repository> argument:

+
+a remote in the git configuration file: $GIT_DIR/config, +
+
+
+a file in the $GIT_DIR/remotes directory, or +
+
+
+a file in the $GIT_DIR/branches directory. +
+

All of these also allow you to omit the refspec from the command line +because they each contain a refspec which git will use by default.

Named remote in configuration file

        [remote "<name>"]
+                url = <url>
+                push = <refspec>
+                fetch = <refspec>

Named file in `$GIT_DIR/remotes`

        URL: one of the above URL format
@@ -766,41 +808,27 @@ named file should be in the following format:
         Pull: <refspec>

Push: lines are used by git-push and +Pull: lines are used by git-pull and git-fetch. +Multiple Push: and Pull: lines may be specified for additional branch mappings.

Or, equivalently, in the $GIT_DIR/config (note the use -of fetch instead of Pull:):

Named file in `$GIT_DIR/branches`

You can choose to provide the name of a +file in $GIT_DIR/branches. +The URL in this file will be used to access the repository. +This file should have the following format:

        [remote "<remote>"]
-                url = <url>
-                push = <refspec>
-                fetch = <refspec>
-

        URL: <url>
-        Pull: refs/heads/master:<remote>
-

        <url>#<head>

while having <url>#<head> is equivalent to

        URL: <url>
-        Pull: refs/heads/<head>:<remote>

        refs/heads/<head>:<repository>

MERGE STRATEGIES

@@ -1037,7 +1065,7 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.

diff --git a/git-push.html b/git-push.html index 1f20f9f34..31f820ba5 100644 --- a/git-push.html +++ b/git-push.html @@ -545,11 +545,51 @@ configuration section of the form:

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

REMOTES

In addition to the above, as a short-hand, the name of a -file in $GIT_DIR/remotes directory can be given; the -named file should be in the following format:

The name of one of the following can be used instead +of a URL as <repository> argument:

+
+a remote in the git configuration file: $GIT_DIR/config, +
+
+
+a file in the $GIT_DIR/remotes directory, or +
+
+
+a file in the $GIT_DIR/branches directory. +
+

All of these also allow you to omit the refspec from the command line +because they each contain a refspec which git will use by default.

Named remote in configuration file

        [remote "<name>"]
+                url = <url>
+                push = <refspec>
+                fetch = <refspec>

Named file in `$GIT_DIR/remotes`

        URL: one of the above URL format
@@ -557,41 +597,27 @@ named file should be in the following format:
         Pull: <refspec>

Push: lines are used by git-push and +Pull: lines are used by git-pull and git-fetch. +Multiple Push: and Pull: lines may be specified for additional branch mappings.

Or, equivalently, in the $GIT_DIR/config (note the use -of fetch instead of Pull:):

Named file in `$GIT_DIR/branches`

You can choose to provide the name of a +file in $GIT_DIR/branches. +The URL in this file will be used to access the repository. +This file should have the following format:

        [remote "<remote>"]
-                url = <url>
-                push = <refspec>
-                fetch = <refspec>
-

        URL: <url>
-        Pull: refs/heads/master:<remote>
-

        <url>#<head>

while having <url>#<head> is equivalent to

        URL: <url>
-        Pull: refs/heads/<head>:<remote>

        refs/heads/<head>:<repository>

OUTPUT

@@ -733,7 +759,7 @@ by Linus Torvalds <torvalds@osdl.org>

diff --git a/git-quiltimport.html b/git-quiltimport.html index 1bddc1510..46e1cd580 100644 --- a/git-quiltimport.html +++ b/git-quiltimport.html @@ -339,7 +339,7 @@ variable.

diff --git a/git-read-tree.html b/git-read-tree.html index e0f719aa1..a95c8a63e 100644 --- a/git-read-tree.html +++ b/git-read-tree.html @@ -711,7 +711,7 @@ have finished your work-in-progress), attempt the merge again.

diff --git a/git-rebase.html b/git-rebase.html index 4dbb00d21..37facd978 100644 --- a/git-rebase.html +++ b/git-rebase.html @@ -843,7 +843,7 @@ Johannes E. Schindelin <johannes.schindelin@gmx.de>

diff --git a/git-receive-pack.html b/git-receive-pack.html index 5f645eb46..5cc51620f 100644 --- a/git-receive-pack.html +++ b/git-receive-pack.html @@ -430,7 +430,7 @@ exec git-update-server-info diff --git a/git-reflog.html b/git-reflog.html index 01a1ecb1b..eed8baf2b 100644 --- a/git-reflog.html +++ b/git-reflog.html @@ -397,7 +397,7 @@ them.

diff --git a/git-relink.html b/git-relink.html index 09e0d9b79..4a393d1fe 100644 --- a/git-relink.html +++ b/git-relink.html @@ -316,7 +316,7 @@ repository will be replaced with a hardlink to the master repository.

diff --git a/git-remote.html b/git-remote.html index edb5b71c0..24df82c5e 100644 --- a/git-remote.html +++ b/git-remote.html @@ -430,7 +430,7 @@ $ git merge origin diff --git a/git-repack.html b/git-repack.html index 78b6f4fab..dd84d371b 100644 --- a/git-repack.html +++ b/git-repack.html @@ -443,7 +443,7 @@ that way can try to use older git with it).

diff --git a/git-repo-config.html b/git-repo-config.html index 29255ede8..b47dc86f4 100644 --- a/git-repo-config.html +++ b/git-repo-config.html @@ -281,7 +281,7 @@ documentation of that command.

diff --git a/git-request-pull.html b/git-request-pull.html index 1ad2fe5df..25a09726a 100644 --- a/git-request-pull.html +++ b/git-request-pull.html @@ -322,7 +322,7 @@ the given URL in the generated summary.

diff --git a/git-rerere.html b/git-rerere.html index a380aa3c0..48056ee16 100644 --- a/git-rerere.html +++ b/git-rerere.html @@ -481,7 +481,7 @@ conflict.

diff --git a/git-reset.html b/git-reset.html index 3dbe86675..cdfb0e542 100644 --- a/git-reset.html +++ b/git-reset.html @@ -607,7 +607,7 @@ Adds the file to the index again. diff --git a/git-resolve.html b/git-resolve.html deleted file mode 100644 index 9ea8e6ec9..000000000 --- a/git-resolve.html +++ /dev/null @@ -1,306 +0,0 @@ - - - - - - -git-resolve(1) - - - -

SYNOPSIS

git-resolve <current> <merged> <message>

DESCRIPTION

DEPRECATED and will be removed in 1.5.1. Use git-merge instead.

Given two commits and a merge message, merge the <merged> commit -into <current> commit, with the commit log message <message>.

When <current> is a descendant of <merged>, or <current> is an -ancestor of <merged>, no new commit is created and the <message> -is ignored. The former is informally called "already up to -date", and the latter is often called "fast forward".

Author

Written by Linus Torvalds <torvalds@osdl.org> and -Dan Holmsand <holmsand@gmail.com>.

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-rev-list.html b/git-rev-list.html index 6f67fc417..2b009021c 100644 --- a/git-rev-list.html +++ b/git-rev-list.html @@ -1225,7 +1225,7 @@ and the git-list <git@vger.kernel.org>.

diff --git a/git-rev-parse.html b/git-rev-parse.html index b4f6a1cfe..01a73666a 100644 --- a/git-rev-parse.html +++ b/git-rev-parse.html @@ -901,7 +901,7 @@ Junio C Hamano <junkio@cox.net> and Pierre Habouzit <madcoder@debian.or diff --git a/git-revert.html b/git-revert.html index 545269bd1..15b472c7e 100644 --- a/git-revert.html +++ b/git-revert.html @@ -365,7 +365,7 @@ effect to your working tree in a row.

diff --git a/git-rm.html b/git-rm.html index ffe79fe61..fbc0d66c2 100644 --- a/git-rm.html +++ b/git-rm.html @@ -427,7 +427,7 @@ git-rm -f git-*.sh diff --git a/git-runstatus.html b/git-runstatus.html deleted file mode 100644 index 95c1e6a7d..000000000 --- a/git-runstatus.html +++ /dev/null @@ -1,362 +0,0 @@ - - - - - - -git-runstatus(1) - - - -

SYNOPSIS

git-runstatus [--color|--nocolor] [--amend] [--verbose] [--untracked]

DESCRIPTION

Examines paths in the working tree that has changes unrecorded -to the index file, and changes between the index file and the -current HEAD commit. The former paths are what you _could_ -commit by running git add (or git rm if you are deleting) before running git -commit, and the latter paths are what you _would_ commit by -running git commit.

If there is no path that is different between the index file and -the current HEAD commit, the command exits with non-zero status.

Note that this is _not_ the user level command you would want to -run from the command line. Use git-status instead.

OPTIONS

---color -: -
- Show colored status, highlighting modified file names. -
-
---nocolor -: -
- Turn off coloring. -
-
---amend -: -
- Show status based on HEAD^1, not HEAD, i.e. show what - git-commit --amend would do. -
-
---verbose -: -
- Show unified diff of all file changes. -
-
---untracked -: -
- Show files in untracked directories, too. Without this - option only its name and a trailing slash are displayed - for each untracked directory. -
-

OUTPUT

The output from this command is designed to be used as a commit -template comments, and all the output lines are prefixed with #.

Author

Originally written by Linus Torvalds <torvalds@osdl.org> as part -of git-commit, and later rewritten in C by Jeff King.

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-send-email.html b/git-send-email.html index 5e266a295..0f0697220 100644 --- a/git-send-email.html +++ b/git-send-email.html @@ -685,7 +685,7 @@ send_lots_of_email.pl by Greg Kroah-Hartman.

diff --git a/git-send-pack.html b/git-send-pack.html index 42d073107..4347e83fe 100644 --- a/git-send-pack.html +++ b/git-send-pack.html @@ -453,7 +453,7 @@ to disable the fast-forward check only on that ref.

diff --git a/git-sh-setup.html b/git-sh-setup.html index 2a1517c78..4e00a9f82 100644 --- a/git-sh-setup.html +++ b/git-sh-setup.html @@ -383,7 +383,7 @@ get_author_ident_from_commit diff --git a/git-shell.html b/git-shell.html index 4450c934b..544b2bb89 100644 --- a/git-shell.html +++ b/git-shell.html @@ -298,7 +298,7 @@ are permitted to be called, with a single required argument.

diff --git a/git-shortlog.html b/git-shortlog.html index 6123311a6..fed86125a 100644 --- a/git-shortlog.html +++ b/git-shortlog.html @@ -359,7 +359,7 @@ Eve Jones <eve@laptop.(none)> diff --git a/git-show-branch.html b/git-show-branch.html index f65f89f24..3d9a009c6 100644 --- a/git-show-branch.html +++ b/git-show-branch.html @@ -521,7 +521,7 @@ topologically related with each other.

diff --git a/git-show-index.html b/git-show-index.html index ff0c11584..7793f5112 100644 --- a/git-show-index.html +++ b/git-show-index.html @@ -296,7 +296,7 @@ offset and SHA1 of each object.

diff --git a/git-show-ref.html b/git-show-ref.html index 900a49371..f6bb4b901 100644 --- a/git-show-ref.html +++ b/git-show-ref.html @@ -460,7 +460,7 @@ Man page by Jonas Fonseca <fonseca@diku.dk>.

diff --git a/git-show.html b/git-show.html index 6024c1c6c..6f2ccbb58 100644 --- a/git-show.html +++ b/git-show.html @@ -768,7 +768,7 @@ Johannes Schindelin <Johannes.Schindelin@gmx.de>.

diff --git a/git-ssh-fetch.html b/git-ssh-fetch.html deleted file mode 100644 index 97004a027..000000000 --- a/git-ssh-fetch.html +++ /dev/null @@ -1,357 +0,0 @@ - - - - - - -git-ssh-fetch(1) - - - -

SYNOPSIS

git-ssh-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url

DESCRIPTION

THIS COMMAND IS DEPRECATED.

Pulls from a remote repository over ssh connection, invoking -git-ssh-upload on the other end. It functions identically to -git-ssh-upload, aside from which end you run it on.

OPTIONS

-commit-id -: -
- Either the hash or the filename under [URL]/refs/ to - pull. -
-
--c -: -
- Get the commit objects. -
-
--t -: -
- Get trees associated with the commit objects. -
-
--a -: -
- Get all the objects. -
-
--v -: -
- Report what is downloaded. -
-
--w -: -
- Writes the commit-id into the filename under $GIT_DIR/refs/ on - the local end after the transfer is complete. -
-

Author

Written by Daniel Barkalow <barkalow@iabervon.org>

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git-ssh-upload.html b/git-ssh-upload.html deleted file mode 100644 index bbdac32a9..000000000 --- a/git-ssh-upload.html +++ /dev/null @@ -1,356 +0,0 @@ - - - - - - -git-ssh-upload(1) - - - -

SYNOPSIS

git-ssh-upload [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url

DESCRIPTION

THIS COMMAND IS DEPRECATED.

Pushes from a remote repository over ssh connection, invoking -git-ssh-fetch on the other end. It functions identically to -git-ssh-fetch, aside from which end you run it on.

OPTIONS

-commit-id -: -
- Id of commit to push. -
-
--c -: -
- Get the commit objects. -
-
--t -: -
- Get tree associated with the requested commit object. -
-
--a -: -
- Get all the objects. -
-
--v -: -
- Report what is uploaded. -
-
--w -: -
- Writes the commit-id into the filename under [URL]/refs/ on - the remote end after the transfer is complete. -
-

Author

Written by Daniel Barkalow <barkalow@iabervon.org>

Documentation

Documentation by Daniel Barkalow

GIT

Part of the git(7) suite

- - - diff --git a/git-stash.html b/git-stash.html index bd6adae9f..a58fedc90 100644 --- a/git-stash.html +++ b/git-stash.html @@ -482,7 +482,7 @@ $ git stash apply diff --git a/git-status.html b/git-status.html index 23eca2555..107c3b4a4 100644 --- a/git-status.html +++ b/git-status.html @@ -332,7 +332,7 @@ Junio C Hamano <junkio@cox.net>.

diff --git a/git-stripspace.html b/git-stripspace.html index a177b738c..fde204abb 100644 --- a/git-stripspace.html +++ b/git-stripspace.html @@ -313,7 +313,7 @@ git-stripspace(1) Manual Page diff --git a/git-submodule.html b/git-submodule.html index 7cb2e3d64..b9cd275d0 100644 --- a/git-submodule.html +++ b/git-submodule.html @@ -419,7 +419,7 @@ for details.

diff --git a/git-svn.html b/git-svn.html index 71edb35ec..16fec1961 100644 --- a/git-svn.html +++ b/git-svn.html @@ -1171,7 +1171,7 @@ should be manually entered with a text-editor or using diff --git a/git-svnimport.html b/git-svnimport.html deleted file mode 100644 index 14f2b941a..000000000 --- a/git-svnimport.html +++ /dev/null @@ -1,549 +0,0 @@ - - - - - - -git-svnimport(1) - - - -

SYNOPSIS

git-svnimport [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ] - [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev] - [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ] - [ -s start_chg ] [ -m ] [ -r ] [ -M regex ] - [ -I <ignorefile_name> ] [ -A <author_file> ] - [ -R <repack_each_revs>] [ -P <path_from_trunk> ] - <SVN_repository_URL> [ <path> ]

DESCRIPTION

Imports a SVN repository into git. It will either create a new -repository, or incrementally import into an existing one.

SVN access is done by the SVN::Perl module.

git-svnimport assumes that SVN repositories are organized into one -"trunk" directory where the main development happens, "branches/FOO" -directories for branches, and "/tags/FOO" directories for tags. -Other subdirectories are ignored.

git-svnimport creates a file ".git/svn2git", which is required for -incremental SVN imports.

OPTIONS

--C <target-dir> -

- The GIT repository to import to. If the directory doesn't - exist, it will be created. Default is the current directory. -

--s <start_rev> -

- Start importing at this SVN change number. The default is 1. -

When importing incrementally, you might need to edit the .git/svn2git file.

--i -

- Import-only: don't perform a checkout after importing. This option - ensures the working directory and index remain untouched and will - not create them if they do not exist. -

--T <trunk_subdir> -

- Name the SVN trunk. Default "trunk". -

--t <tag_subdir> -

- Name the SVN subdirectory for tags. Default "tags". -

--b <branch_subdir> -

- Name the SVN subdirectory for branches. Default "branches". -

--o <branch-for-HEAD> -

- The trunk branch from SVN is imported to the origin branch within - the git repository. Use this option if you want to import into a - different branch. -

--r -

- Prepend rX: to commit messages, where X is the imported - subversion revision. -

--u -

- Replace underscores in tag names with periods. -

--I <ignorefile_name> -

- Import the svn:ignore directory property to files with this - name in each directory. (The Subversion and GIT ignore - syntaxes are similar enough that using the Subversion patterns - directly with "-I .gitignore" will almost always just work.) -

--A <author_file> -

- Read a file with lines on the form -

        username = User's Full Name <email@addr.es>
-

and use "User's Full Name <email@addr.es>" as the GIT -author and committer for Subversion commits made by -"username". If encountering a commit made by a user not in the -list, abort.

For convenience, this data is saved to $GIT_DIR/svn-authors -each time the -A option is provided, and read from that same -file each time git-svnimport is run with an existing GIT -repository without -A.

--m -

- Attempt to detect merges based on the commit message. This option - will enable default regexes that try to capture the name source - branch name from the commit message. -

--M <regex> -

- Attempt to detect merges based on the commit message with a custom - regex. It can be used with -m to also see the default regexes. - You must escape forward slashes. -

--l <max_rev> -

- Specify a maximum revision number to pull. -

Formerly, this option controlled how many revisions to pull, -due to SVN memory leaks. (These have been worked around.)

--R <repack_each_revs> -

- Specify how often git repository should be repacked. -

The default value is 1000. git-svnimport will do import in chunks of 1000 -revisions, after each chunk git repository will be repacked. To disable -this behavior specify some big value here which is mote than number of -revisions to import.

--P <path_from_trunk> -

- Partial import of the SVN tree. -

By default, the whole tree on the SVN trunk (/trunk) is imported. --P my/proj will import starting only from /trunk/my/proj. -This option is useful when you want to import one project from a -svn repo which hosts multiple projects under the same trunk.

--v -

- Verbosity: let svnimport report what it is doing. -

--d -

- Use direct HTTP requests if possible. The "<path>" argument is used - only for retrieving the SVN logs; the path to the contents is - included in the SVN log. -

--D -

- Use direct HTTP requests if possible. The "<path>" argument is used - for retrieving the logs, as well as for the contents. -

There's no safe way to automatically find out which of these options to -use, so you need to try both. Usually, the one that's wrong will die -with a 40x error pretty quickly.

-<SVN_repository_URL> -

- The URL of the SVN module you want to import. For local - repositories, use "file:///absolute/path". -

If you're using the "-d" or "-D" option, this is the URL of the SVN -repository itself; it usually ends in "/svn".

-<path> -

- The path to the module you want to check out. -

--h -

- Print a short usage message and exit. -

OUTPUT

If -v is specified, the script reports what it is doing.

Otherwise, success is indicated the Unix way, i.e. by simply exiting with -a zero exit status.

Author

Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from -various participants of the git-list <git@vger.kernel.org>.

Based on a cvs2git script by the same author.

Documentation

Documentation by Matthias Urlichs <smurf@smurf.noris.de>.

GIT

Part of the git(7) suite

- - - diff --git a/git-symbolic-ref.html b/git-symbolic-ref.html index d9d1ebb33..a3499daa8 100644 --- a/git-symbolic-ref.html +++ b/git-symbolic-ref.html @@ -336,7 +336,7 @@ name is not a symbolic ref, or 128 if another error occurs.

diff --git a/git-tag.html b/git-tag.html index 77ff1c5a8..b7223bd95 100644 --- a/git-tag.html +++ b/git-tag.html @@ -552,7 +552,7 @@ Junio C Hamano <junkio@cox.net> and Chris Wright <chrisw@osdl.org>.< diff --git a/git-tar-tree.html b/git-tar-tree.html index f84c748c0..15924a739 100644 --- a/git-tar-tree.html +++ b/git-tar-tree.html @@ -399,7 +399,7 @@ git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar diff --git a/git-tools.html b/git-tools.html index 025caecf1..16f19a8d9 100644 --- a/git-tools.html +++ b/git-tools.html @@ -438,7 +438,7 @@ comprehensive list.

diff --git a/git-unpack-file.html b/git-unpack-file.html index 801d67438..3e8904375 100644 --- a/git-unpack-file.html +++ b/git-unpack-file.html @@ -307,7 +307,7 @@ returns the name of the temporary file in the following format: diff --git a/git-unpack-objects.html b/git-unpack-objects.html index a4f691ac3..6149ccd6c 100644 --- a/git-unpack-objects.html +++ b/git-unpack-objects.html @@ -341,7 +341,7 @@ new packs and replace existing ones.

diff --git a/git-update-index.html b/git-update-index.html index 069a55711..3d1407d64 100644 --- a/git-update-index.html +++ b/git-update-index.html @@ -727,7 +727,7 @@ from symbolic link to regular file.

diff --git a/git-update-ref.html b/git-update-ref.html index 24fec5640..5da3730fd 100644 --- a/git-update-ref.html +++ b/git-update-ref.html @@ -360,7 +360,7 @@ or does not have committer information available.

diff --git a/git-update-server-info.html b/git-update-server-info.html index a0fb9b0c4..b34fe1640 100644 --- a/git-update-server-info.html +++ b/git-update-server-info.html @@ -332,7 +332,7 @@ info/refs file unless --force flag is given.

diff --git a/git-upload-archive.html b/git-upload-archive.html index dec0371dd..16a3133af 100644 --- a/git-upload-archive.html +++ b/git-upload-archive.html @@ -309,7 +309,7 @@ is meant to be used to get an archive from a remote repository.

diff --git a/git-upload-pack.html b/git-upload-pack.html index 57909731a..4ae5b8d0c 100644 --- a/git-upload-pack.html +++ b/git-upload-pack.html @@ -326,7 +326,7 @@ repository. For push operations, see git-send-pack.

diff --git a/git-upload-tar.html b/git-upload-tar.html deleted file mode 100644 index fc23b80aa..000000000 --- a/git-upload-tar.html +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - -git-upload-tar(1) - - - -

SYNOPSIS

git-upload-tar <directory>

DESCRIPTION

Invoked by git-tar-tree --remote and sends a generated tar archive -to the other end over the git protocol.

This command is usually not invoked directly by the end user. -The UI for the protocol is on the git-tar-tree side, and the -program pair is meant to be used to get a tar archive from a -remote repository.

OPTIONS

-<directory> -: -
- The repository to get a tar archive from. -
-

Author

Written by Junio C Hamano <junio@kernel.org>

Documentation

Documentation by Junio C Hamano.

GIT

Part of the git(7) suite

- - - diff --git a/git-var.html b/git-var.html index 32384e32f..9e96191cd 100644 --- a/git-var.html +++ b/git-var.html @@ -372,7 +372,7 @@ Your sysadmin must hate you! diff --git a/git-verify-pack.html b/git-verify-pack.html index 2be9d3da0..bc2446e4c 100644 --- a/git-verify-pack.html +++ b/git-verify-pack.html @@ -338,7 +338,7 @@ corresponding pack file.

diff --git a/git-verify-tag.html b/git-verify-tag.html index 9df190b8b..a84e71402 100644 --- a/git-verify-tag.html +++ b/git-verify-tag.html @@ -305,7 +305,7 @@ git-verify-tag(1) Manual Page diff --git a/git-web--browse.html b/git-web--browse.html index 8ed493c43..37a0ae829 100644 --- a/git-web--browse.html +++ b/git-web--browse.html @@ -419,7 +419,7 @@ git-list <git@vger.kernel.org>.

diff --git a/git-whatchanged.html b/git-whatchanged.html index 25484b148..8da0dab6b 100644 --- a/git-whatchanged.html +++ b/git-whatchanged.html @@ -707,7 +707,7 @@ Junio C Hamano <junkio@cox.net>

diff --git a/git-write-tree.html b/git-write-tree.html index 6a5f5769f..67c582032 100644 --- a/git-write-tree.html +++ b/git-write-tree.html @@ -323,7 +323,7 @@ now, you need to have done a git-update-index phase before you did the diff --git a/git-zip-tree.html b/git-zip-tree.html deleted file mode 100644 index a50cdebda..000000000 --- a/git-zip-tree.html +++ /dev/null @@ -1,369 +0,0 @@ - - - - - - -git-zip-tree(1) - - - -

SYNOPSIS

git-zip-tree [-0|…|-9] <tree-ish> [ <base> ]

DESCRIPTION

Creates a ZIP archive containing the tree structure for the named tree. -When <base> is specified it is added as a leading path to the files in the -generated ZIP archive.

git-zip-tree behaves differently when given a tree ID versus when given -a commit ID or tag ID. In the first case the current time is used as -modification time of each file in the archive. In the latter case the -commit time as recorded in the referenced commit object is used instead. -Additionally the commit ID is stored as an archive comment.

Currently git-zip-tree can handle only files and directories, symbolic -links are not supported.

OPTIONS

--0 -: -
- Store the files instead of deflating them. -
-
--9 -: -
- Highest and slowest compression level. You can specify any - number from 1 to 9 to adjust compression speed and ratio. -
-
-<tree-ish> -: -
- The tree or commit to produce ZIP archive for. If it is - the object name of a commit object. -
-
-<base> -: -
- Leading path to the files in the resulting ZIP archive. -
-

EXAMPLES

-git zip-tree v1.4.0 git-1.4.0 >git-1.4.0.zip -: -
- Create a ZIP file for v1.4.0 release. -
-
-git zip-tree HEAD:Documentation/ git-docs >docs.zip -: -
- Put everything in the current head's Documentation/ directory - into docs.zip, with the prefix git-docs/. -
-

Author

Written by Rene Scharfe.

Documentation

Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT

Part of the git(7) suite

- - - diff --git a/git.html b/git.html index 2123ae481..3814b727f 100644 --- a/git.html +++ b/git.html @@ -1952,7 +1952,7 @@ contributors on the git-list <git@vger.kernel.org>.

diff --git a/gitattributes.html b/gitattributes.html index b0e5c841d..e90814e77 100644 --- a/gitattributes.html +++ b/gitattributes.html @@ -823,7 +823,7 @@ commit hash.

diff --git a/gitcli.html b/gitcli.html index cd49a6909..a3993d682 100644 --- a/gitcli.html +++ b/gitcli.html @@ -388,7 +388,7 @@ $ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT diff --git a/gitcvs-migration.html b/gitcvs-migration.html index 68f5a1bf5..0de825b91 100644 --- a/gitcvs-migration.html +++ b/gitcvs-migration.html @@ -439,7 +439,7 @@ repositories without the need for a central maintainer.

diff --git a/githooks.html b/githooks.html index 2c03526ef..70473ce18 100644 --- a/githooks.html +++ b/githooks.html @@ -525,7 +525,7 @@ to abort.

diff --git a/gitignore.html b/gitignore.html index e026e4fcb..73bbb8680 100644 --- a/gitignore.html +++ b/gitignore.html @@ -433,7 +433,7 @@ Frank Lichtenheld, and the git-list <git@vger.kernel.org>.

diff --git a/gitk.html b/gitk.html index 519e06f0e..807e17242 100644 --- a/gitk.html +++ b/gitk.html @@ -440,7 +440,7 @@ such as display options, font, and colors.

diff --git a/gitmodules.html b/gitmodules.html index 9dae35366..593802cca 100644 --- a/gitmodules.html +++ b/gitmodules.html @@ -337,7 +337,7 @@ submodules an url is specified which can be used for cloning the submodules.

diff --git a/gittutorial-2.html b/gittutorial-2.html index 1f29a67e2..d04dbe0e6 100644 --- a/gittutorial-2.html +++ b/gittutorial-2.html @@ -670,7 +670,7 @@ example, creating a new commit.

diff --git a/gittutorial.html b/gittutorial.html index e531d4704..0f704b657 100644 --- a/gittutorial.html +++ b/gittutorial.html @@ -809,7 +809,7 @@ digressions that may be interesting at this point are:

diff --git a/glossary.html b/glossary.html index e403aedea..fbdc63365 100644 --- a/glossary.html +++ b/glossary.html @@ -1082,7 +1082,7 @@ This commit is referred to as a "merge commit", or sometimes just a diff --git a/hooks.html b/hooks.html deleted file mode 100644 index 37665b7d3..000000000 --- a/hooks.html +++ /dev/null @@ -1,516 +0,0 @@ - - - - - - -Hooks used by git - - - -

Hooks are little scripts you can place in $GIT_DIR/hooks -directory to trigger action at certain points. When -git-init is run, a handful example hooks are copied in the -hooks directory of the new repository, but by default they are -all disabled. To enable a hook, make it executable with chmod +x.

This document describes the currently defined hooks.

applypatch-msg

This hook is invoked by git-am script. It takes a single -parameter, the name of the file that holds the proposed commit -log message. Exiting with non-zero status causes -git-am to abort before applying the patch.

The hook is allowed to edit the message file in place, and can -be used to normalize the message into some project standard -format (if the project has one). It can also be used to refuse -the commit after inspecting the message file.

The default applypatch-msg hook, when enabled, runs the -commit-msg hook, if the latter is enabled.

pre-applypatch

This hook is invoked by git-am. It takes no parameter, and is -invoked after the patch is applied, but before a commit is made.

If it exits with non-zero status, then the working tree will not be -committed after applying the patch.

It can be used to inspect the current working tree and refuse to -make a commit if it does not pass certain test.

The default pre-applypatch hook, when enabled, runs the -pre-commit hook, if the latter is enabled.

post-applypatch

This hook is invoked by git-am. It takes no parameter, -and is invoked after the patch is applied and a commit is made.

This hook is meant primarily for notification, and cannot affect -the outcome of git-am.

pre-commit

This hook is invoked by git-commit, and can be bypassed -with --no-verify option. It takes no parameter, and is -invoked before obtaining the proposed commit log message and -making a commit. Exiting with non-zero status from this script -causes the git-commit to abort.

The default pre-commit hook, when enabled, catches introduction -of lines with trailing whitespaces and aborts the commit when -such a line is found.

All the git-commit hooks are invoked with the environment -variable GIT_EDITOR=: if the command will not bring up an editor -to modify the commit message.

prepare-commit-msg

This hook is invoked by git-commit right after preparing the -default log message, and before the editor is started.

It takes one to three parameters. The first is the name of the file -that the commit log message. The second is the source of the commit -message, and can be: message (if a \-m or \-F option was -given); template (if a \-t option was given or the -configuration option commit.template is set); merge (if the -commit is a merge or a .git/MERGE_MSG file exists); squash -(if a .git/SQUASH_MSG file exists); or commit, followed by -a commit SHA1 (if a \-c, \-C or --amend option was given).

If the exit status is non-zero, git-commit will abort.

The purpose of the hook is to edit the message file in place, and -it is not suppressed by the --no-verify option. A non-zero exit -means a failure of the hook and aborts the commit. It should not -be used as replacement for pre-commit hook.

The sample prepare-commit-msg hook that comes with git comments -out the Conflicts: part of a merge's commit message.

commit-msg

This hook is invoked by git-commit, and can be bypassed -with --no-verify option. It takes a single parameter, the -name of the file that holds the proposed commit log message. -Exiting with non-zero status causes the git-commit to -abort.

The default commit-msg hook, when enabled, detects duplicate -"Signed-off-by" lines, and aborts the commit if one is found.

post-commit

This hook is invoked by git-commit. It takes no -parameter, and is invoked after a commit is made.

This hook is meant primarily for notification, and cannot affect -the outcome of git-commit.

post-checkout

This hook is invoked when a git-checkout is run after having updated the -worktree. The hook is given three parameters: the ref of the previous HEAD, -the ref of the new HEAD (which may or may not have changed), and a flag -indicating whether the checkout was a branch checkout (changing branches, -flag=1) or a file checkout (retrieving a file from the index, flag=0). -This hook cannot affect the outcome of git-checkout.

This hook can be used to perform repository validity checks, auto-display -differences from the previous HEAD if different, or set working dir metadata -properties.

post-merge

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, -if the merge failed due to conflicts.

This hook can be used in conjunction with a corresponding pre-commit hook to -save and restore any form of metadata associated with the working tree -(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl -for an example of how to do this.

pre-receive

This hook is invoked by git-receive-pack on the remote 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 executes once for the receive operation. It takes no -arguments, but for each ref to be updated it receives on standard -input a line of the format:

<old-value> SP <new-value> SP <ref-name> LF

where <old-value> is the old object name stored in the ref, -<new-value> is the new object name to be stored in the ref and -<ref-name> is the full name of the ref. -When creating a new ref, <old-value> is 40 0.

If the hook exits with non-zero status, none of the refs will be -updated. If the hook exits with zero, updating of individual refs can -still be prevented by the update hook.

Both standard output and standard error output are forwarded to -git-send-pack on the other end, so you can simply echo messages -for the user.

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. -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.

The hook executes once for each ref to be updated, and takes -three parameters:

-
-the name of the ref being updated, -
-
-
-the old object name stored in the ref, -
-
-
-and the new objectname to be stored in the ref. -
-

A zero exit from the update hook allows the ref to be updated. -Exiting with a non-zero status prevents git-receive-pack -from updating that ref.

This hook can be used to prevent forced update on certain refs by -making sure that the object name is a commit object that is a -descendant of the commit object named by the old object name. -That is, to enforce a "fast forward only" policy.

It could also be used to log the old..new status. However, it -does not know the entire set of branches, so it would end up -firing one e-mail per ref when used naively, though. The -post-receive hook is more suited to that.

Another use suggested on the mailing list is to use this hook to -implement access control which is finer grained than the one -based on filesystem group.

Both standard output and standard error output are forwarded to -git-send-pack on the other end, so you can simply echo messages -for the user.

The default update hook, when enabled—and with -hooks.allowunannotated config option turned on—prevents -unannotated tags to be pushed.

post-receive

This hook is invoked by git-receive-pack on the remote 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 executes once for the receive operation. It takes no -arguments, but gets the same information as the -pre-receive -hook does on its standard input.

This hook does not affect the outcome of git-receive-pack, as it -is called after the real work is done.

This supersedes the post-update hook in that it gets -both old and new values of all the refs in addition to their -names.

Both standard output and standard error output are forwarded to -git-send-pack on the other end, so you can simply echo messages -for the user.

The default post-receive hook is empty, but there is -a sample script post-receive-email provided in the contrib/hooks -directory in git distribution, which implements sending commit -emails.

post-update

It takes a variable number of parameters, each of which is the -name of ref that was actually updated.

This hook is meant primarily for notification, and cannot affect -the outcome of git-receive-pack.

The post-update hook can tell what are the heads that were pushed, -but it does not know what their original and updated values are, -so it is a poor place to do log old..new. The -post-receive hook does get both original and -updated values of the refs. You might consider it instead if you need -them.

When enabled, the default post-update hook runs -git-update-server-info to keep the information used by dumb -transports (e.g., HTTP) up-to-date. If you are publishing -a git repository that is accessible via HTTP, you should -probably enable this hook.

Both standard output and standard error output are forwarded to -git-send-pack on the other end, so you can simply echo messages -for the user.

pre-auto-gc

This hook is invoked by git-gc —auto. It takes no parameter, and -exiting with non-zero status from this script causes the git-gc —auto -to abort.

- - - diff --git a/howto-index.html b/howto-index.html index 90ef0ac32..9ec59ef2d 100644 --- a/howto-index.html +++ b/howto-index.html @@ -368,7 +368,7 @@ strategy.

diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index 8242dcbcf..2921c4b3a 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -434,7 +434,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index b568a81c4..db5cf1e4a 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -365,7 +365,7 @@ Please note that if the other project merges from you, then it will diff --git a/pull-fetch-param.txt b/pull-fetch-param.txt index b6eb7fc61..cbee36994 100644 --- a/pull-fetch-param.txt +++ b/pull-fetch-param.txt @@ -1,6 +1,8 @@ :: The "remote" repository that is the source of a fetch - or pull operation. See the section <> below. + or pull operation. This parameter can be either a URL + (see the section <> below) or the name + of a remote (see the section <> below). :: The canonical format of a parameter is diff --git a/repository-layout.html b/repository-layout.html index 2ddbbe3c3..57f213982 100644 --- a/repository-layout.html +++ b/repository-layout.html @@ -585,7 +585,7 @@ shallow diff --git a/technical/api-allocation-growing.html b/technical/api-allocation-growing.html index 3c8b4b111..c40911430 100644 --- a/technical/api-allocation-growing.html +++ b/technical/api-allocation-growing.html @@ -306,7 +306,7 @@ ary[nr++] = value you like; diff --git a/technical/api-builtin.html b/technical/api-builtin.html index 8e14f7c94..4e445f440 100644 --- a/technical/api-builtin.html +++ b/technical/api-builtin.html @@ -359,7 +359,7 @@ command.

diff --git a/technical/api-decorate.html b/technical/api-decorate.html index 2343d6a8c..f6891b9a2 100644 --- a/technical/api-decorate.html +++ b/technical/api-decorate.html @@ -269,7 +269,7 @@ div.exampleblock-content { diff --git a/technical/api-diff.html b/technical/api-diff.html index d5cdf8ca6..c6c31978f 100644 --- a/technical/api-diff.html +++ b/technical/api-diff.html @@ -582,7 +582,7 @@ RECURSIVE, TREE_IN_RECURSIVE diff --git a/technical/api-directory-listing.html b/technical/api-directory-listing.html index 4f6c1be82..5c7a8e4aa 100644 --- a/technical/api-directory-listing.html +++ b/technical/api-directory-listing.html @@ -393,7 +393,7 @@ Use dir.entries[]. diff --git a/technical/api-gitattributes.html b/technical/api-gitattributes.html index 0bd036307..813094640 100644 --- a/technical/api-gitattributes.html +++ b/technical/api-gitattributes.html @@ -417,7 +417,7 @@ Act on .value member of the result, left in check[]: diff --git a/technical/api-grep.html b/technical/api-grep.html index 0e465a607..79928efe7 100644 --- a/technical/api-grep.html +++ b/technical/api-grep.html @@ -276,7 +276,7 @@ grep_buffer() diff --git a/technical/api-hash.html b/technical/api-hash.html index 8a352c327..9c81c9c10 100644 --- a/technical/api-hash.html +++ b/technical/api-hash.html @@ -269,7 +269,7 @@ div.exampleblock-content { diff --git a/technical/api-history-graph.html b/technical/api-history-graph.html index 8489a3d7d..8c322927b 100644 --- a/technical/api-history-graph.html +++ b/technical/api-history-graph.html @@ -501,7 +501,7 @@ M-. \ \ diff --git a/technical/api-in-core-index.html b/technical/api-in-core-index.html index ab55da712..af37ae59c 100644 --- a/technical/api-in-core-index.html +++ b/technical/api-in-core-index.html @@ -337,7 +337,7 @@ cache_tree_update() diff --git a/technical/api-index.html b/technical/api-index.html index 6ae6947b4..51f765e60 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -382,7 +382,7 @@ documents them.

diff --git a/technical/api-lockfile.html b/technical/api-lockfile.html index e41f6e089..1ea2c0508 100644 --- a/technical/api-lockfile.html +++ b/technical/api-lockfile.html @@ -361,7 +361,7 @@ that unrelated file descriptor.

diff --git a/technical/api-object-access.html b/technical/api-object-access.html index ba39fa886..f3dfdf74a 100644 --- a/technical/api-object-access.html +++ b/technical/api-object-access.html @@ -311,7 +311,7 @@ Use of object flags diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index 75c363c17..24d1ef373 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -269,7 +269,7 @@ div.exampleblock-content { diff --git a/technical/api-path-list.html b/technical/api-path-list.html index 4434fbd99..acac1e683 100644 --- a/technical/api-path-list.html +++ b/technical/api-path-list.html @@ -281,7 +281,7 @@ the calling sequence. diff --git a/technical/api-quote.html b/technical/api-quote.html index 6ea2650da..935e3c236 100644 --- a/technical/api-quote.html +++ b/technical/api-quote.html @@ -286,7 +286,7 @@ quoting for foreign languages diff --git a/technical/api-remote.html b/technical/api-remote.html index a796310be..b5905f0ff 100644 --- a/technical/api-remote.html +++ b/technical/api-remote.html @@ -436,7 +436,7 @@ process of interacting with remotes.

diff --git a/technical/api-revision-walking.html b/technical/api-revision-walking.html index b824c3e70..43d726043 100644 --- a/technical/api-revision-walking.html +++ b/technical/api-revision-walking.html @@ -263,6 +263,91 @@ div.exampleblock-content {

The revision walking API offers functions to build a list of revisions +and then iterate over that list.

Calling sequence

The walking API has a given calling sequence: first you need to +initialize a rev_info structure, then add revisions to control what kind +of revision list do you want to get, finally you can iterate over the +revision list.

Functions

+init_revisions +

+ Initialize a rev_info structure with default values. The second + parameter may be NULL or can be prefix path, and then the .prefix + variable will be set to it. This is typically the first function you + want to call when you want to deal with a revision list. After calling + this function, you are free to customize options, like set + .ignore_merges to 0 if you don't want to ignore merges, and so on. See + revision.h for a complete list of available options. +

+add_pending_object +

+ This function can be used if you want to add commit objects as revision + information. You can use the UNINTERESTING object flag to indicate if + you want to include or exclude the given commit (and commits reachable + from the given commit) from the revision list. +

+ + + +

Note

If you have the commits as a string list then you probably want to +use setup_revisions(), instead of parsing each string and using this +function.

+setup_revisions +

+ Parse revision information, filling in the rev_info structure, and + removing the used arguments from the argument list. Returns the number + of arguments left that weren't recognized, which are also moved to the + head of the argument list. The last parameter is used in case no + parameter given by the first two arguments. +

+prepare_revision_walk +

+ Prepares the rev_info structure for a walk. You should check if it + returns any error (non-zero return code) and if it does not, you can + start using get_revision() to do the iteration. +

+get_revision +

+ Takes a pointer to a rev_info structure and iterates over it, + returning a struct commit * each time you call it. The end of the + revision list is indicated by returning a NULL pointer. +

Data structures

Talk about <revision.h>, things like:

@@ -272,16 +357,15 @@ two diff_options, one for path limiting, another for output;
-calling sequence: init_revisions(), setup_revsions(), get_revision(); +remaining functions;

(Linus, JC, Dscho)

- diff --git a/technical/api-revision-walking.txt b/technical/api-revision-walking.txt index 01a24551a..996da0503 100644 --- a/technical/api-revision-walking.txt +++ b/technical/api-revision-walking.txt @@ -1,9 +1,67 @@ revision walking API ==================== +The revision walking API offers functions to build a list of revisions +and then iterate over that list. + +Calling sequence +---------------- + +The walking API has a given calling sequence: first you need to +initialize a rev_info structure, then add revisions to control what kind +of revision list do you want to get, finally you can iterate over the +revision list. + +Functions +--------- + +`init_revisions`:: + + Initialize a rev_info structure with default values. The second + parameter may be NULL or can be prefix path, and then the `.prefix` + variable will be set to it. This is typically the first function you + want to call when you want to deal with a revision list. After calling + this function, you are free to customize options, like set + `.ignore_merges` to 0 if you don't want to ignore merges, and so on. See + `revision.h` for a complete list of available options. + +`add_pending_object`:: + + This function can be used if you want to add commit objects as revision + information. You can use the `UNINTERESTING` object flag to indicate if + you want to include or exclude the given commit (and commits reachable + from the given commit) from the revision list. ++ +NOTE: If you have the commits as a string list then you probably want to +use setup_revisions(), instead of parsing each string and using this +function. + +`setup_revisions`:: + + Parse revision information, filling in the `rev_info` structure, and + removing the used arguments from the argument list. Returns the number + of arguments left that weren't recognized, which are also moved to the + head of the argument list. The last parameter is used in case no + parameter given by the first two arguments. + +`prepare_revision_walk`:: + + Prepares the rev_info structure for a walk. You should check if it + returns any error (non-zero return code) and if it does not, you can + start using get_revision() to do the iteration. + +`get_revision`:: + + Takes a pointer to a `rev_info` structure and iterates over it, + returning a `struct commit *` each time you call it. The end of the + revision list is indicated by returning a NULL pointer. + +Data structures +--------------- + Talk about , things like: * two diff_options, one for path limiting, another for output; -* calling sequence: init_revisions(), setup_revsions(), get_revision(); +* remaining functions; (Linus, JC, Dscho) diff --git a/technical/api-run-command.html b/technical/api-run-command.html index 2c0c21679..df7bae467 100644 --- a/technical/api-run-command.html +++ b/technical/api-run-command.html @@ -564,7 +564,7 @@ It must not change the program's state that the caller of the diff --git a/technical/api-setup.html b/technical/api-setup.html index 37f08718c..ba00c3839 100644 --- a/technical/api-setup.html +++ b/technical/api-setup.html @@ -301,7 +301,7 @@ get_pathspec() diff --git a/technical/api-strbuf.html b/technical/api-strbuf.html index a66298a57..e10981f72 100644 --- a/technical/api-strbuf.html +++ b/technical/api-strbuf.html @@ -269,7 +269,7 @@ div.exampleblock-content { diff --git a/technical/api-tree-walking.html b/technical/api-tree-walking.html index 4cc721047..d6ada56ab 100644 --- a/technical/api-tree-walking.html +++ b/technical/api-tree-walking.html @@ -296,7 +296,7 @@ get_tree_entry diff --git a/technical/api-xdiff-interface.html b/technical/api-xdiff-interface.html index dda82e5a4..b8d1a3d05 100644 --- a/technical/api-xdiff-interface.html +++ b/technical/api-xdiff-interface.html @@ -270,7 +270,7 @@ xdiff_emit_consume_fn.

diff --git a/tutorial-2.html b/tutorial-2.html deleted file mode 100644 index 9e92ce6fe..000000000 --- a/tutorial-2.html +++ /dev/null @@ -1,654 +0,0 @@ - - - - - - -A tutorial introduction to git: part two - - - -

You should work through A tutorial introduction to -git before reading this tutorial.

The goal of this tutorial is to introduce two fundamental pieces of -git's architecture—the object database and the index file—and to -provide the reader with everything necessary to understand the rest -of the git documentation.

The git object database

Let's start a new project and create a small amount of history:

$ mkdir test-project
-$ cd test-project
-$ git init
-Initialized empty Git repository in .git/
-$ echo 'hello world' > file.txt
-$ git add .
-$ git commit -a -m "initial commit"
-Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
- create mode 100644 file.txt
-$ echo 'hello world!' >file.txt
-$ git commit -a -m "add emphasis"
-Created commit c4d59f390b9cfd4318117afde11d601c1085f241

What are the 40 digits of hex that git responded to the commit with?

We saw in part one of the tutorial that commits have names like this. -It turns out that every object in the git history is stored under -such a 40-digit hex name. That name is the SHA1 hash of the object's -contents; among other things, this ensures that git will never store -the same data twice (since identical data is given an identical SHA1 -name), and that the contents of a git object will never change (since -that would change the object's name as well).

It is expected that the content of the commit object you created while -following the example above generates a different SHA1 hash than -the one shown above because the commit object records the time when -it was created and the name of the person performing the commit.

We can ask git about this particular object with the cat-file -command. Don't copy the 40 hex digits from this example but use those -from your own version. Note that you can shorten it to only a few -characters to save yourself typing all 40 hex digits:

$ git-cat-file -t 54196cc2
-commit
-$ git-cat-file commit 54196cc2
-tree 92b8b694ffb1675e5975148e1121810081dbdffe
-author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
-committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
-
-initial commit

A tree can refer to one or more "blob" objects, each corresponding to -a file. In addition, a tree can also refer to other tree objects, -thus creating a directory hierarchy. You can examine the contents of -any tree using ls-tree (remember that a long enough initial portion -of the SHA1 will also work):

$ git ls-tree 92b8b694
-100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    file.txt

Thus we see that this tree has one file in it. The SHA1 hash is a -reference to that file's data:

$ git cat-file -t 3b18e512
-blob

A "blob" is just file data, which we can also examine with cat-file:

$ git cat-file blob 3b18e512
-hello world

Note that this is the old file data; so the object that git named in -its response to the initial tree was a tree with a snapshot of the -directory state that was recorded by the first commit.

All of these objects are stored under their SHA1 names inside the git -directory:

$ find .git/objects/
-.git/objects/
-.git/objects/pack
-.git/objects/info
-.git/objects/3b
-.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
-.git/objects/92
-.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
-.git/objects/54
-.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
-.git/objects/a0
-.git/objects/a0/423896973644771497bdc03eb99d5281615b51
-.git/objects/d0
-.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
-.git/objects/c4
-.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241

and the contents of these files is just the compressed data plus a -header identifying their length and their type. The type is either a -blob, a tree, a commit, or a tag.

The simplest commit to find is the HEAD commit, which we can find -from .git/HEAD:

$ cat .git/HEAD
-ref: refs/heads/master

As you can see, this tells us which branch we're currently on, and it -tells us this by naming a file under the .git directory, which itself -contains a SHA1 name referring to a commit object, which we can -examine with cat-file:

$ cat .git/refs/heads/master
-c4d59f390b9cfd4318117afde11d601c1085f241
-$ git cat-file -t c4d59f39
-commit
-$ git cat-file commit c4d59f39
-tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
-parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
-author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
-committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
-
-add emphasis

The "tree" object here refers to the new state of the tree:

$ git ls-tree d0492b36
-100644 blob a0423896973644771497bdc03eb99d5281615b51    file.txt
-$ git cat-file blob a0423896
-hello world!

and the "parent" object refers to the previous commit:

$ git-cat-file commit 54196cc2
-tree 92b8b694ffb1675e5975148e1121810081dbdffe
-author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
-committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
-
-initial commit

The tree object is the tree we examined first, and this commit is -unusual in that it lacks any parent.

Most commits have only one parent, but it is also common for a commit -to have multiple parents. In that case the commit represents a -merge, with the parent references pointing to the heads of the merged -branches.

Besides blobs, trees, and commits, the only remaining type of object -is a "tag", which we won't discuss here; refer to git-tag(1) -for details.

So now we know how git uses the object database to represent a -project's history:

-
-"commit" objects refer to "tree" objects representing the - snapshot of a directory tree at a particular point in the - history, and refer to "parent" commits to show how they're - connected into the project history. -
-
-
-"tree" objects represent the state of a single directory, - associating directory names to "blob" objects containing file - data and "tree" objects containing subdirectory information. -
-
-
-"blob" objects contain file data without any other structure. -
-
-
-References to commit objects at the head of each branch are - stored in files under .git/refs/heads/. -
-
-
-The name of the current branch is stored in .git/HEAD. -
-

Note, by the way, that lots of commands take a tree as an argument. -But as we can see above, a tree can be referred to in many different -ways—by the SHA1 name for that tree, by the name of a commit that -refers to the tree, by the name of a branch whose head refers to that -tree, etc.—and most such commands can accept any of these names.

In command synopses, the word "tree-ish" is sometimes used to -designate such an argument.

The index file

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?

If we look at the way commits are created under the cover, we'll see -that there are more flexible ways creating commits.

Continuing with our test-project, let's modify file.txt again:

$ echo "hello world, again" >>file.txt

but this time instead of immediately making the commit, let's take an -intermediate step, and ask for diffs along the way to keep track of -what's happening:

$ git diff
---- a/file.txt
-+++ b/file.txt
-@@ -1 +1,2 @@
- hello world!
-+hello world, again
-$ git add file.txt
-$ git diff

The last diff is empty, but no new commits have been made, and the -head still doesn't contain the new line:

$ git-diff HEAD
-diff --git a/file.txt b/file.txt
-index a042389..513feba 100644
---- a/file.txt
-+++ b/file.txt
-@@ -1 +1,2 @@
- hello world!
-+hello world, again

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:

$ git ls-files --stage
-100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt
-$ git cat-file -t 513feba2
-blob
-$ git cat-file blob 513feba2
-hello world!
-hello world, again

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" -output:

$ echo 'again?' >>file.txt
-$ git diff
-index 513feba..ba3da7b 100644
---- a/file.txt
-+++ b/file.txt
-@@ -1,2 +1,3 @@
- hello world!
- hello world, again
-+again?

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:

$ git diff HEAD
-diff --git a/file.txt b/file.txt
-index a042389..ba3da7b 100644
---- a/file.txt
-+++ b/file.txt
-@@ -1 +1,3 @@
- hello world!
-+hello world, again
-+again?
-$ git diff --cached
-diff --git a/file.txt b/file.txt
-index a042389..513feba 100644
---- a/file.txt
-+++ b/file.txt
-@@ -1 +1,2 @@
- hello world!
-+hello world, again

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:

$ git commit -m "repeat"
-$ git diff HEAD
-diff --git a/file.txt b/file.txt
-index 513feba..ba3da7b 100644
---- a/file.txt
-+++ b/file.txt
-@@ -1,2 +1,3 @@
- hello world!
- hello world, again
-+again?

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 -file:

$ echo "goodbye, world" >closing.txt
-$ git add closing.txt

The effect of the "git add" was to add one entry to the index file:

$ git ls-files --stage
-100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0       closing.txt
-100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt

And, as you can see with cat-file, this new entry refers to the -current contents of the file:

$ git cat-file blob 8b9743b2
-goodbye, world

The "status" command is a useful way to get a quick summary of the -situation:

$ git status
-# On branch master
-# Changes to be committed:
-#   (use "git reset HEAD <file>..." to unstage)
-#
-#       new file: closing.txt
-#
-# Changed but not updated:
-#   (use "git add <file>..." to update what will be committed)
-#
-#       modified: file.txt
-#

Since the current state of closing.txt is cached in the index file, -it is listed as "Changes to be committed". Since file.txt has -changes in the working directory that aren't reflected in the index, -it is marked "changed but not updated". At this point, running "git -commit" would create a commit that added closing.txt (with its new -contents), but that didn't modify file.txt.

Also, note that a bare "git diff" shows the changes to file.txt, but -not the addition of closing.txt, because the version of closing.txt -in the index file is identical to the one in the working directory.

In addition to being the staging area for new commits, the index file -is also populated from the object database when checking out a -branch, and is used to hold the trees involved in a merge operation. -See the core tutorial and the relevant man -pages for details.

What next?

At this point you should know everything necessary to read the man -pages for any of the git commands; one good place to start would be -with the commands mentioned in Everyday git. You -should be able to find any unknown jargon in the -Glossary.

The Git User's Manual provides a more -comprehensive introduction to git.

The CVS migration document explains how to -import a CVS repository into git, and shows how to use git in a -CVS-like way.

For some interesting examples of git use, see the -howtos.

For git developers, the Core tutorial goes -into detail on the lower-level git mechanisms involved in, for -example, creating a new commit.

- - - diff --git a/tutorial.html b/tutorial.html deleted file mode 100644 index 538a7a5f6..000000000 --- a/tutorial.html +++ /dev/null @@ -1,793 +0,0 @@ - - - - - - -A tutorial introduction to git (for version 1.5.1 or newer) - - - -

This tutorial explains how to import a new project into git, make -changes to it, and share changes with other developers.

If you are instead primarily interested in using git to fetch a project, -for example, to test the latest version, you may prefer to start with -the first two chapters of The Git User's Manual.

First, note that you can get documentation for a command such as "git -diff" with:

$ man git-diff

It is a good idea to introduce yourself to git with your name and -public email address before doing any operation. The easiest -way to do so is:

$ git config --global user.name "Your Name Comes Here"
-$ git config --global user.email you@yourdomain.example.com

Importing a new project

Assume you have a tarball project.tar.gz with your initial work. You -can place it under git revision control as follows.

$ tar xzf project.tar.gz
-$ cd project
-$ git init

Git will reply

Initialized empty Git repository in .git/

You've now initialized the working directory—you may notice a new -directory created, named ".git".

Next, tell git to take a snapshot of the contents of all files under the -current directory (note the .), with git-add(1):

$ git add .

This snapshot is now stored in a temporary staging area which git calls -the "index". You can permanently store the contents of the index in the -repository with git-commit(1):

$ git commit

This will prompt you for a commit message. You've now stored the first -version of your project in git.

Making changes

Modify some files, then add their updated contents to the index:

$ git add file1 file2 file3

You are now ready to commit. You can see what is about to be committed -using git-diff(1) with the —cached option:

$ git diff --cached

(Without —cached, git-diff(1) will show you any changes that -you've made but not yet added to the index.) You can also get a brief -summary of the situation with git-status(1):

$ git status
-# On branch master
-# Changes to be committed:
-#   (use "git reset HEAD <file>..." to unstage)
-#
-#       modified:   file1
-#       modified:   file2
-#       modified:   file3
-#

If you need to make any further adjustments, do so now, and then add any -newly modified content to the index. Finally, commit your changes with:

$ git commit

This will again prompt your 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

$ git commit -a

which will automatically notice any modified (but not new) files, add -them to the index, and commit, all in one step.

A note on commit messages: Though not required, it's a good idea to -begin the commit message with a single short (less than 50 character) -line summarizing the change, followed by a blank line and then a more -thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the -commit in the body.

Git tracks content not files

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 -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.

Viewing project history

At any point you can view the history of your changes using

$ git log

If you also want to see complete diffs at each step, use

$ git log -p

Often the overview of the change is useful to get a feel of -each step

$ git log --stat --summary

Managing branches

A single git repository can maintain multiple branches of -development. To create a new branch named "experimental", use

$ git branch experimental

If you now run

$ git branch

you'll get a list of all existing branches:

  experimental
-* master

The "experimental" branch is the one you just created, and the -"master" branch is a default branch that was created for you -automatically. The asterisk marks the branch you are currently on; -type

$ git checkout experimental

to switch to the experimental branch. Now edit a file, commit the -change, and switch back to the master branch:

(edit file)
-$ git commit -a
-$ git checkout master

Check that the change you made is no longer visible, since it was -made on the experimental branch and you're back on the master branch.

You can make a different change on the master branch:

(edit file)
-$ git commit -a

at this point the two branches have diverged, with different changes -made in each. To merge the changes made in experimental into master, run

$ git merge experimental

If the changes don't conflict, you're done. If there are conflicts, -markers will be left in the problematic files showing the conflict;

$ git diff

will show this. Once you've edited the files to resolve the -conflicts,

$ git commit -a

will commit the result of the merge. Finally,

$ gitk

will show a nice graphical representation of the resulting history.

At this point you could delete the experimental branch with

$ git branch -d experimental

This command ensures that the changes in the experimental branch are -already in the current branch.

If you develop on a branch crazy-idea, then regret it, you can always -delete the branch with

$ git branch -D crazy-idea

Branches are cheap and easy, so this is a good way to try something -out.

Using git for collaboration

Suppose that Alice has started a new project with a git repository in -/home/alice/project, and that Bob, who has a home directory on the -same machine, wants to contribute.

Bob begins with:

$ git clone /home/alice/project myrepo

This creates a new directory "myrepo" containing a clone of Alice's -repository. The clone is on an equal footing with the original -project, possessing its own copy of the original project's history.

Bob then makes some changes and commits them:

(edit files)
-$ git commit -a
-(repeat as necessary)

When he's ready, he tells Alice to pull changes from the repository -at /home/bob/myrepo. She does this with:

$ cd /home/alice/project
-$ git pull /home/bob/myrepo master

This merges the changes from Bob's "master" branch into Alice's -current branch. If Alice has made her own changes in the meantime, -then she may need to manually fix any conflicts. (Note that the -"master" argument in the above command is actually unnecessary, as it -is the default.)

The "pull" command thus performs two operations: it fetches changes -from a remote branch, then merges them into the current branch.

When you are working in a small closely knit group, it is not -unusual to interact with the same repository over and over -again. By defining remote repository shorthand, you can make -it easier:

$ git remote add bob /home/bob/myrepo

With this, Alice can perform the first operation alone using the -"git fetch" command without merging them with her own branch, -using:

$ git fetch bob

Unlike the longhand form, when Alice fetches from Bob using a -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 log -p master..bob/master

shows a list of all the changes that Bob made since he branched from -Alice's master branch.

After examining those changes, Alice -could merge the changes into her master branch:

$ git merge bob/master

This merge can also be done by pulling from her own remote -tracking branch, like this:

$ git pull . remotes/bob/master

Note that git pull always merges into the current branch, -regardless of what else is given on the command line.

Later, Bob can update his repo with Alice's latest changes using

$ git pull

Note that he doesn't need to give the path to Alice's repository; -when Bob cloned Alice's repository, git stored the location of her -repository in the repository configuration, and that location is -used for pulls:

$ git config --get remote.origin.url
-/home/alice/project

(The complete configuration created by git-clone is visible using -"git config -l", and the git-config(1) man page -explains the meaning of each option.)

Git also keeps a pristine copy of Alice's master branch under the -name "origin/master":

$ git branch -r
-  origin/master

If Bob later decides to work from a different host, he can still -perform clones and pulls using the ssh protocol:

$ git clone alice.org:/home/alice/project myrepo

Alternatively, git has a native protocol, or can use rsync or http; -see git-pull(1) for details.

Git can also be used in a CVS-like mode, with a central repository -that various users push changes to; see git-push(1) and -git for CVS users.

Exploring history

Git history is represented as a series of interrelated commits. We -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:

$ git log
-commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-Author: Junio C Hamano <junkio@cox.net>
-Date:   Tue May 16 17:18:22 2006 -0700
-
-    merge-base: Clarify the comments on post processing.

We can give this name to git show to see the details about this -commit.

$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

But there are other ways to refer to commits. You can use any initial -part of the name that is long enough to uniquely identify the commit:

$ git show c82a22c39c   # the first few characters of the name are
-                        # usually enough
-$ git show HEAD         # the tip of the current branch
-$ git show experimental # the tip of the "experimental" branch

Every commit usually has one "parent" commit -which points to the previous state of the project:

$ git show HEAD^  # to see the parent of HEAD
-$ git show HEAD^^ # to see the grandparent of HEAD
-$ git show HEAD~4 # to see the great-great grandparent of HEAD

Note that merge commits may have more than one parent:

$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
-$ git show HEAD^2 # show the second parent of HEAD

You can also give commits names of your own; after running

$ git-tag v2.5 1b2e1d63ff

you can refer to 1b2e1d63ff by the name "v2.5". If you intend to -share this name with other people (for example, to identify a release -version), you should create a "tag" object, and perhaps sign it; see -git-tag(1) for details.

Any git command that needs to know a commit can take any of these -names. For example:

$ git diff v2.5 HEAD     # compare the current HEAD to v2.5
-$ git branch stable v2.5 # start a new branch named "stable" based
-                         # at v2.5
-$ git reset --hard HEAD^ # reset your current branch and working
-                         # directory to its state at HEAD^

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 -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 git-revert(1) -instead.

The git grep command can search for strings in any version of your -project, so

$ git grep "hello" v2.5

searches for all occurrences of "hello" in v2.5.

If you leave out the commit name, git grep will search any of the -files it manages in your current directory. So

$ git grep "hello"

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:

$ git log v2.5..v2.6            # commits between v2.5 and v2.6
-$ git log v2.5..                # commits since v2.5
-$ git log --since="2 weeks ago" # commits from the last 2 weeks
-$ git log v2.5.. Makefile       # commits since v2.5 which modify
-                                # Makefile

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

$ git log stable..experimental

will list commits made in the experimental branch but not in the -stable branch, while

$ git log experimental..stable

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 -list. When the history has lines of development that diverged and -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, -or git itself) have frequent merges, and gitk does a better job of -visualizing their history. For example,

$ gitk --since="2 weeks ago" drivers/

allows you to browse any commits from the last 2 weeks of commits -that modified files under the "drivers" directory. (Note: you can -adjust gitk's fonts by holding down the control key while pressing -"-" or "+".)

Finally, most commands that take filenames will optionally allow you -to precede any filename by a commit, to specify a particular version -of the file:

$ git diff v2.5:Makefile HEAD:Makefile.in

You can also use "git show" to see any such file:

$ git show v2.5:Makefile

Next Steps

This tutorial should be enough to perform basic distributed revision -control for your projects. However, to fully understand the depth -and power of git you need to understand two simple ideas on which it -is based:

-
-The object database is the rather elegant system used to - store the history of your project—files, directories, and - commits. -
-
-
-The index file is a cache of the state of a directory tree, - used to create commits, check out working directories, and - hold the various trees involved in a merge. -
-

Part two of this tutorial explains the object -database, the index file, and a few other odds and ends that you'll -need to make the most of git.

If you don't want to continue with that right away, a few other -digressions that may be interesting at this point are:

-
-git-format-patch(1), git-am(1): These convert - series of git commits into emailed patches, and vice versa, - useful for projects such as the linux kernel which rely heavily - on emailed patches. -
-
-
-git-bisect(1): When there is a regression in your - project, one way to track down the bug is by searching through - the history to find the exact commit that's to blame. Git bisect - can help you perform a binary search for that commit. It is - smart enough to perform a close-to-optimal search even in the - case of complex non-linear history with lots of merged branches. -
-
-
-Everyday GIT with 20 Commands Or So -
-
-
-git for CVS users. -
-

- - - diff --git a/urls-remotes.txt b/urls-remotes.txt index 5dd1f836c..99753006e 100644 --- a/urls-remotes.txt +++ b/urls-remotes.txt @@ -1,55 +1,82 @@ include::urls.txt[] -REMOTES -------- +REMOTES[[REMOTES]] +------------------ -In addition to the above, as a short-hand, the name of a -file in `$GIT_DIR/remotes` directory can be given; the -named file should be in the following format: +The name of one of the following can be used instead +of a URL as `` argument: ------------- - URL: one of the above URL format - Push: - Pull: +* a remote in the git configuration file: `$GIT_DIR/config`, +* a file in the `$GIT_DIR/remotes` directory, or +* a file in the `$GIT_DIR/branches` directory. ------------- +All of these also allow you to omit the refspec from the command line +because they each contain a refspec which git will use by default. -Then such a short-hand is specified in place of - without parameters on the command -line, specified on `Push:` lines or `Pull:` -lines are used for `git-push` and `git-fetch`/`git-pull`, -respectively. Multiple `Push:` and `Pull:` lines may -be specified for additional branch mappings. +Named remote in configuration file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Or, equivalently, in the `$GIT_DIR/config` (note the use -of `fetch` instead of `Pull:`): +You can choose to provide the name of a remote which you had previously +configured using linkgit:git-remote[1], linkgit:git-config[1] +or even by a manual edit to the `$GIT_DIR/config` file. The URL of +this remote will be used to access the repository. The refspec +of this remote will be used by default when you do +not provide a refspec on the command line. The entry in the +config file would appear like this: ------------ - [remote ""] + [remote ""] url = push = fetch = - ------------ -The name of a file in `$GIT_DIR/branches` directory can be -specified as an older notation short-hand; the named -file should contain a single line, a URL in one of the -above formats, optionally followed by a hash `#` and the -name of remote head (URL fragment notation). -`$GIT_DIR/branches/` file that stores a -without the fragment is equivalent to have this in the -corresponding file in the `$GIT_DIR/remotes/` directory. + +Named file in `$GIT_DIR/remotes` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can choose to provide the name of a +file in `$GIT_DIR/remotes`. The URL +in this file will be used to access the repository. The refspec +in this file will be used as default when you do not +provide a refspec on the command line. This file should have the +following format: + +------------ + URL: one of the above URL format + Push: + Pull: ------------ - URL: - Pull: refs/heads/master: +`Push:` lines are used by `git-push` and +`Pull:` lines are used by `git-pull` and `git-fetch`. +Multiple `Push:` and `Pull:` lines may +be specified for additional branch mappings. + +Named file in `$GIT_DIR/branches` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can choose to provide the name of a +file in `$GIT_DIR/branches`. +The URL in this file will be used to access the repository. +This file should have the following format: + + +------------ + # ------------ -while having `#` is equivalent to +`` is required; `#` is optional. +When you do not provide a refspec on the command line, +git will use the following refspec, where `` defaults to `master`, +and `` is the name of this file +you provided in the command line. ------------ - URL: - Pull: refs/heads/: + refs/heads/: ------------ + + + +

git for CVS users

Developing against a shared repository

Setting Up a Shared Repository

Importing a CVS archive

Advanced Shared Repository Management

Providing CVS Access to a git Repository

Alternative Development Models

-git-applymbox(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

SEE ALSO

Author

Documentation

GIT

-git-applypatch(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Author

Documentation

GIT

-git-clone-pack(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Author

Documentation

GIT

-git-convert-objects(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

Author

Documentation

GIT

-git-diff-stages(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Output format

Generating patches with -p

combined diff format

Author

Documentation

GIT

REMOTES

REMOTES

Named remote in configuration file

Named file in $GIT_DIR/remotes

Named file in $GIT_DIR/branches

SEE ALSO

-git-local-fetch(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Author

Documentation

GIT

-git-p4import(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

P4 Client

Multiple Branches

Tags

Notes

Author

GIT

-git-pickaxe(1) Manual Page -

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`