diff options
Diffstat (limited to 'Documentation')
124 files changed, 7335 insertions, 1302 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore index c87c61af00..6a51331b2f 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -4,4 +4,4 @@ *.7 howto-index.txt doc.dep -README +cmds-*.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index 93c7024b48..9e7f2a7880 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -17,7 +17,7 @@ ARTICLES += hooks ARTICLES += everyday ARTICLES += git-tools # with their own formatting rules. -SP_ARTICLES = glossary howto/revert-branch-rebase +SP_ARTICLES = glossary howto/revert-branch-rebase user-manual DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) @@ -31,6 +31,8 @@ man1dir=$(mandir)/man1 man7dir=$(mandir)/man7 # DESTDIR= +ASCIIDOC=asciidoc +ASCIIDOC_EXTRA = INSTALL?=install DOC_REF = origin/man @@ -71,30 +73,44 @@ doc.dep : $(wildcard *.txt) build-docdep.perl -include doc.dep -git.7: README +cmds_txt = cmds-ancillaryinterrogators.txt \ + cmds-ancillarymanipulators.txt \ + cmds-mainporcelain.txt \ + cmds-plumbinginterrogators.txt \ + cmds-plumbingmanipulators.txt \ + cmds-synchingrepositories.txt \ + cmds-synchelpers.txt \ + cmds-purehelpers.txt \ + cmds-foreignscminterface.txt -README: ../README - cp $< $@ +$(cmds_txt): cmd-list.perl $(MAN1_TXT) + perl ./cmd-list.perl +git.7 git.html: git.txt core-intro.txt clean: - rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README + rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep + rm -f $(cmds_txt) %.html : %.txt - asciidoc -b xhtml11 -d manpage -f asciidoc.conf $< + $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf $(ASCIIDOC_EXTRA) $< %.1 %.7 : %.xml xmlto -m callouts.xsl man $< %.xml : %.txt - asciidoc -b docbook -d manpage -f asciidoc.conf $< + $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf $< -git.html: git.txt README +user-manual.xml: user-manual.txt user-manual.conf + $(ASCIIDOC) -b docbook -d book $< + +user-manual.html: user-manual.xml + xmlto html-nochunks $< glossary.html : glossary.txt sort_glossary.pl cat $< | \ perl sort_glossary.pl | \ - asciidoc -b xhtml11 - > glossary.html + $(ASCIIDOC) -b xhtml11 - > glossary.html howto-index.txt: howto-index.sh $(wildcard howto/*.txt) rm -f $@+ $@ @@ -102,13 +118,13 @@ howto-index.txt: howto-index.sh $(wildcard howto/*.txt) mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - asciidoc -b xhtml11 $*.txt + $(ASCIIDOC) -b xhtml11 $*.txt WEBDOC_DEST = /pub/software/scm/git/docs $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt rm -f $@+ $@ - sed -e '1,/^$$/d' $< | asciidoc -b xhtml11 - >$@+ + sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+ mv $@+ $@ install-webdoc : html diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt new file mode 100644 index 0000000000..84e7eaf3c8 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.txt @@ -0,0 +1,468 @@ +GIT v1.5.0 Release Notes +======================== + +Old news +-------- + +This section is for people who are upgrading from ancient +versions of git. Although all of the changes in this section +happened before the current v1.4.4 release, they are summarized +here in the v1.5.0 release notes for people who skipped earlier +versions. + +As of git v1.5.0 there are some optional features that changes +the repository to allow data to be stored and transferred more +efficiently. These features are not enabled by default, as they +will make the repository unusable with older versions of git. +Specifically, the available options are: + + - There is a configuration variable core.legacyheaders that + changes the format of loose objects so that they are more + efficient to pack and to send out of the repository over git + native protocol, since v1.4.2. However, loose objects + written in the new format cannot be read by git older than + that version; people fetching from your repository using + older clients over dumb transports (e.g. http) using older + versions of git will also be affected. + + - Since v1.4.3, configuration repack.usedeltabaseoffset allows + packfile to be created in more space efficient format, which + cannot be read by git older than that version. + +The above two are not enabled by default and you explicitly have +to ask for them, because these two features make repositories +unreadable by older versions of git, and in v1.5.0 we still do +not enable them by default for the same reason. We will change +this default probably 1 year after 1.4.2's release, when it is +reasonable to expect everybody to have new enough version of +git. + + - 'git pack-refs' appeared in v1.4.4; this command allows tags + to be accessed much more efficiently than the traditional + 'one-file-per-tag' format. Older git-native clients can + still fetch from a repository that packed and pruned refs + (the server side needs to run the up-to-date version of git), + but older dumb transports cannot. Packing of refs is done by + an explicit user action, either by use of "git pack-refs + --prune" command or by use of "git gc" command. + + - 'git -p' to paginate anything -- many commands do pagination + by default on a tty. Introduced between v1.4.1 and v1.4.2; + this may surprise old timers. + + - 'git archive' superseded 'git tar-tree' in v1.4.3; + + - 'git cvsserver' was new invention in v1.3.0; + + - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were + seriously enhanced during v1.4.0 timeperiod. + + - 'gitweb' became part of git.git during v1.4.0 timeperiod and + seriously modified since then. + + - reflog is an v1.4.0 invention. This allows you to name a + revision that a branch used to be at (e.g. "git diff + master@{yesterday} master" allows you to see changes since + yesterday's tip of the branch). + + +Updates in v1.5.0 since v1.4.4 series +------------------------------------- + +* Index manipulation + + - git-add is to add contents to the index (aka "staging area" + for the next commit), whether the file the contents happen to + be is an existing one or a newly created one. + + - git-add without any argument does not add everything + anymore. Use 'git-add .' instead. Also you can add + otherwise ignored files with an -f option. + + - git-add tries to be more friendly to users by offering an + interactive mode ("git-add -i"). + + - git-commit <path> used to refuse to commit if <path> was + different between HEAD and the index (i.e. update-index was + used on it earlier). This check was removed. + + - git-rm is much saner and safer. It is used to remove paths + from both the index file and the working tree, and makes sure + you are not losing any local modification before doing so. + + - git-reset <tree> <paths>... can be used to revert index + entries for selected paths. + + - git-update-index is much less visible. Many suggestions to + use the command in git output and documentation have now been + replaced by simpler commands such as "git add" or "git rm". + + +* Repository layout and objects transfer + + - The data for origin repository is stored in the configuration + file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly + created clones. The latter is still supported and there is + no need to convert your existing repository if you are + already comfortable with your workflow with the layout. + + - git-clone always uses what is known as "separate remote" + layout for a newly created repository with a working tree. + + A repository with the separate remote layout starts with only + one default branch, 'master', to be used for your own + development. Unlike the traditional layout that copied all + the upstream branches into your branch namespace (while + renaming their 'master' to your 'origin'), the new layout + puts upstream branches into local "remote-tracking branches" + with their own namespace. These can be referenced with names + such as "origin/$upstream_branch_name" and are stored in + .git/refs/remotes rather than .git/refs/heads where normal + branches are stored. + + This layout keeps your own branch namespace less cluttered, + avoids name collision with your upstream, makes it possible + to automatically track new branches created at the remote + after you clone from it, and makes it easier to interact with + more than one remote repository (you can use "git remote" to + add other repositories to track). There might be some + surprises: + + * 'git branch' does not show the remote tracking branches. + It only lists your own branches. Use '-r' option to view + the tracking branches. + + * If you are forking off of a branch obtained from the + upstream, you would have done something like 'git branch + my-next next', because traditional layout dropped the + tracking branch 'next' into your own branch namespace. + With the separate remote layout, you say 'git branch next + origin/next', which allows you to use the matching name + 'next' for your own branch. It also allows you to track a + remote other than 'origin' (i.e. where you initially cloned + from) and fork off of a branch from there the same way + (e.g. "git branch mingw j6t/master"). + + Repositories initialized with the traditional layout continue + to work. + + - New branches that appear on the origin side after a clone is + made are also tracked automatically. This is done with an + wildcard refspec "refs/heads/*:refs/remotes/origin/*", which + older git does not understand, so if you clone with 1.5.0, + you would need to downgrade remote.*.fetch in the + configuration file to specify each branch you are interested + in individually if you plan to fetch into the repository with + older versions of git (but why would you?). + + - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*" + can be given to "git-push" command to update the tracking + branches that is used to track the repository you are pushing + from on the remote side. + + - git-branch and git-show-branch know remote tracking branches + (use the command line switch "-r" to list only tracked branches). + + - git-push can now be used to delete a remote branch or a tag. + This requires the updated git on the remote side (use "git + push <remote> :refs/heads/<branch>" to delete "branch"). + + - git-push more aggressively keeps the transferred objects + packed. Earlier we recommended to monitor amount of loose + objects and repack regularly, but you should repack when you + accumulated too many small packs this way as well. Updated + git-count-objects helps you with this. + + - git-fetch also more aggressively keeps the transferred objects + packed. This behavior of git-push and git-fetch can be + tweaked with a single configuration transfer.unpacklimit (but + usually there should not be any need for a user to tweak it). + + - A new command, git-remote, can help you manage your remote + tracking branch definitions. + + - You may need to specify explicit paths for upload-pack and/or + receive-pack due to your ssh daemon configuration on the + other end. This can now be done via remote.*.uploadpack and + remote.*.receivepack configuration. + + +* Bare repositories + + - Certain commands change their behavior in a bare repository + (i.e. a repository without associated working tree). We use + a fairly conservative heuristic (if $GIT_DIR is ".git", or + ends with "/.git", the repository is not bare) to decide if a + repository is bare, but "core.bare" configuration variable + can be used to override the heuristic when it misidentifies + your repository. + + - git-fetch used to complain updating the current branch but + this is now allowed for a bare repository. So is the use of + 'git-branch -f' to update the current branch. + + - Porcelain-ish commands that require a working tree refuses to + work in a bare repository. + + +* Reflog + + - Reflog records the history from the view point of the local + repository. In other words, regardless of the real history, + the reflog shows the history as seen by one particular + repository (this enables you to ask "what was the current + revision in _this_ repository, yesterday at 1pm?"). This + facility is enabled by default for repositories with working + trees, and can be accessed with the "branch@{time}" and + "branch@{Nth}" notation. + + - "git show-branch" learned showing the reflog data with the + new -g option. "git log" has -s option to view reflog + entries in a more verbose manner. + + - git-branch knows how to rename branches and moves existing + reflog data from the old branch to the new one. + + - In addition to the reflog support in v1.4.4 series, HEAD + reference maintains its own log. "HEAD@{5.minutes.ago}" + means the commit you were at 5 minutes ago, which takes + branch switching into account. If you want to know where the + tip of your current branch was at 5 minutes ago, you need to + explicitly say its name (e.g. "master@{5.minutes.ago}") or + omit the refname altogether i.e. "@{5.minutes.ago}". + + - The commits referred to by reflog entries are now protected + against pruning. The new command "git reflog expire" can be + used to truncate older reflog entries and entries that refer + to commits that have been pruned away previously with older + versions of git. + + Existing repositories that have been using reflog may get + complaints from fsck-objects and may not be able to run + git-repack, if you had run git-prune from older git; please + run "git reflog expire --stale-fix --all" first to remove + reflog entries that refer to commits that are no longer in + the repository when that happens. + + +* Crufts removal + + - We used to say "old commits are retrievable using reflog and + 'master@{yesterday}' syntax as long as you haven't run + git-prune". We no longer have to say the latter half of the + above sentence, as git-prune does not remove things reachable + from reflog entries. + + - 'git-prune' by default does not remove _everything_ + unreachable, as there is a one-day grace period built-in. + + - There is a toplevel garbage collector script, 'git-gc', that + runs periodic cleanup functions, including 'git-repack -a -d', + 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere + gc'. + + - The output from fsck ("fsck-objects" is called just "fsck" + now, but the old name continues to work) was needlessly + alarming in that it warned missing objects that are reachable + only from dangling objects. This has been corrected and the + output is much more useful. + + +* Detached HEAD + + - You can use 'git-checkout' to check out an arbitrary revision + or a tag as well, instead of named branches. This will + dissociate your HEAD from the branch you are currently on. + + A typical use of this feature is to "look around". E.g. + + $ git checkout v2.6.16 + ... compile, test, etc. + $ git checkout v2.6.17 + ... compile, test, etc. + + - After detaching your HEAD, you can go back to an existing + branch with usual "git checkout $branch". Also you can + start a new branch using "git checkout -b $newbranch" to + start a new branch at that commit. + + - You can even pull from other repositories, make merges and + commits while your HEAD is detached. Also you can use "git + reset" to jump to arbitrary commit, while still keeping your + HEAD detached. + + Going back to attached state (i.e. on a particular branch) by + "git checkout $branch" can lose the current stat you arrived + in these ways, and "git checkout" refuses when the detached + HEAD is not pointed by any existing ref (an existing branch, + a remote tracking branch or a tag). This safety can be + overridden with "git checkout -f $branch". + + +* Packed refs + + - Repositories with hundreds of tags have been paying large + overhead, both in storage and in runtime, due to the + traditional one-ref-per-file format. A new command, + git-pack-refs, can be used to "pack" them in more efficient + representation (you can let git-gc do this for you). + + - Clones and fetches over dumb transports are now aware of + packed refs and can download from repositories that use + them. + + +* Configuration + + - configuration related to color setting are consolidated under + color.* namespace (older diff.color.*, status.color.* are + still supported). + + - 'git-repo-config' command is accessible as 'git-config' now. + + +* Updated features + + - git-describe uses better criteria to pick a base ref. It + used to pick the one with the newest timestamp, but now it + picks the one that is topologically the closest (that is, + among ancestors of commit C, the ref T that has the shortest + output from "git-rev-list T..C" is chosen). + + - git-describe gives the number of commits since the base ref + between the refname and the hash suffix. E.g. the commit one + before v2.6.20-rc6 in the kernel repository is: + + v2.6.20-rc5-306-ga21b069 + + which tells you that its object name begins with a21b069, + v2.6.20-rc5 is an ancestor of it (meaning, the commit + contains everything -rc5 has), and there are 306 commits + since v2.6.20-rc5. + + - git-describe with --abbrev=0 can be used to show only the + name of the base ref. + + - git-blame learned a new option, --incremental, that tells it + to output the blames as they are assigned. A sample script + to use it is also included as contrib/blameview. + + - git-blame starts annotating from the working tree by default. + + +* Less external dependency + + - We no longer require the "merge" program from the RCS suite. + All 3-way file-level merges are now done internally. + + - The original implementation of git-merge-recursive which was + in Python has been removed; we have a C implementation of it + now. + + - git-shortlog is no longer a Perl script. It no longer + requires output piped from git-log; it can accept revision + parameters directly on the command line. + + +* I18n + + - We have always encouraged the commit message to be encoded in + UTF-8, but the users are allowed to use legacy encoding as + appropriate for their projects. This will continue to be the + case. However, a non UTF-8 commit encoding _must_ be + explicitly set with i18n.commitencoding in the repository + where a commit is made; otherwise git-commit-tree will + complain if the log message does not look like a valid UTF-8 + string. + + - The value of i18n.commitencoding in the originating + repository is recorded in the commit object on the "encoding" + header, if it is not UTF-8. git-log and friends notice this, + and reencodes the message to the log output encoding when + displaying, if they are different. The log output encoding + is determined by "git log --encoding=<encoding>", + i18n.logoutputencoding configuration, or i18n.commitencoding + configuration, in the decreasing order of preference, and + defaults to UTF-8. + + - Tools for e-mailed patch application now default to -u + behavior; i.e. it always re-codes from the e-mailed encoding + to the encoding specified with i18n.commitencoding. This + unfortunately forces projects that have happily been using a + legacy encoding without setting i18n.commitencoding to set + the configuration, but taken with other improvement, please + excuse us for this very minor one-time inconvenience. + + +* e-mailed patches + + - See the above I18n section. + + - git-format-patch now enables --binary without being asked. + git-am does _not_ default to it, as sending binary patch via + e-mail is unusual and is harder to review than textual + patches and it is prudent to require the person who is + applying the patch to explicitly ask for it. + + - The default suffix for git-format-patch output is now ".patch", + not ".txt". This can be changed with --suffix=.txt option, + or setting the config variable "format.suffix" to ".txt". + + +* Foreign SCM interfaces + + - git-svn now requires the Perl SVN:: libraries, the + command-line backend was too slow and limited. + + - the 'commit' subcommand of git-svn has been renamed to + 'set-tree', and 'dcommit' is the recommended replacement for + day-to-day work. + + - git fast-import backend. + + +* User support + + - Quite a lot of documentation updates. + + - Bash completion scripts have been updated heavily. + + - Better error messages for often used Porcelainish commands. + + - Git GUI. This is a simple Tk based graphical interface for + common Git operations. + + +* Sliding mmap + + - We used to assume that we can mmap the whole packfile while + in use, but with a large project this consumes huge virtual + memory space and truly huge ones would not fit in the + userland address space on 32-bit platforms. We now mmap huge + packfile in pieces to avoid this problem. + + +* Shallow clones + + - There is a partial support for 'shallow' repositories that + keeps only recent history. A 'shallow clone' is created by + specifying how deep that truncated history should be + (e.g. "git clone --depth=5 git://some.where/repo.git"). + + Currently a shallow repository has number of limitations: + + - Cloning and fetching _from_ a shallow clone are not + supported (nor tested -- so they might work by accident but + they are not expected to). + + - Pushing from nor into a shallow clone are not expected to + work. + + - Merging inside a shallow repository would work as long as a + merge base is found in the recent history, but otherwise it + will be like merging unrelated histories and may result in + huge conflicts. + + but this would be more than adequate for people who want to + look at near the tip of a big project with a deep history and + send patches in e-mail format. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 646b6e7331..285781d9db 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -23,7 +23,8 @@ probably need to split up your commit to finer grained pieces. Oh, another thing. I am picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped -in templates/hooks--pre-commit. +in templates/hooks--pre-commit. To help ensure this does not happen, +run git diff --check on your changes before you commit. (2) Generate your patch using git tools out of your commits. @@ -72,7 +73,9 @@ other than the commit message itself. Place such "cover letter" material between the three dash lines and the diffstat. Do not attach the patch as a MIME attachment, compressed or not. -Do not let your e-mail client send quoted-printable. Many +Do not let your e-mail client send quoted-printable. Do not let +your e-mail client send format=flowed which would destroy +whitespaces in your patches. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes a bit more time to @@ -312,3 +315,35 @@ settings but I haven't tried, yet. mail.identity.default.compose_html => false mail.identity.id?.compose_html => false + +Gnus +---- + +'|' in the *Summary* buffer can be used to pipe the current +message to an external program, and this is a handy way to drive +"git am". However, if the message is MIME encoded, what is +piped into the program is the representation you see in your +*Article* buffer after unwrapping MIME. This is often not what +you would want for two reasons. It tends to screw up non ASCII +characters (most notably in people's names), and also +whitespaces (fatal in patches). Running 'C-u g' to display the +message in raw form before using '|' to run the pipe can work +this problem around. + + +KMail +----- + +This should help you to submit patches inline using KMail. + +1) Prepare the patch as a text file. + +2) Click on New Mail. + +3) Go under "Options" in the Composer window and be sure that +"Word wrap" is not set. + +4) Use Message -> Insert file... and insert the patch. + +5) Back in the compose window: add whatever other text you wish to the +message, complete the addressing and subject fields, and press send. diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl new file mode 100755 index 0000000000..d4fd72db4c --- /dev/null +++ b/Documentation/cmd-list.perl @@ -0,0 +1,185 @@ +# + +sub format_one { + my ($out, $name) = @_; + my ($state, $description); + open I, '<', "$name.txt" or die "No such file $name.txt"; + while (<I>) { + if (/^NAME$/) { + $state = 1; + next; + } + if ($state == 1 && /^----$/) { + $state = 2; + next; + } + next if ($state != 2); + chomp; + $description = $_; + last; + } + close I; + if (!defined $description) { + die "No description found in $name.txt"; + } + if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) { + print $out "gitlink:$name\[1\]::\n"; + print $out "\t$text.\n\n"; + } + else { + die "Description does not match $name: $description"; + } +} + +my %cmds = (); +while (<DATA>) { + next if /^#/; + + chomp; + my ($name, $cat) = /^(\S+)\s+(.*)$/; + push @{$cmds{$cat}}, $name; +} + +for my $cat (qw(ancillaryinterrogators + ancillarymanipulators + mainporcelain + plumbinginterrogators + plumbingmanipulators + synchingrepositories + foreignscminterface + purehelpers + synchelpers)) { + my $out = "cmds-$cat.txt"; + open O, '>', "$out+" or die "Cannot open output file $out+"; + for (@{$cmds{$cat}}) { + format_one(\*O, $_); + } + close O; + rename "$out+", "$out"; +} + +__DATA__ +git-add mainporcelain +git-am mainporcelain +git-annotate ancillaryinterrogators +git-applymbox ancillaryinterrogators +git-applypatch purehelpers +git-apply plumbingmanipulators +git-archimport foreignscminterface +git-archive mainporcelain +git-bisect mainporcelain +git-blame ancillaryinterrogators +git-branch mainporcelain +git-cat-file plumbinginterrogators +git-checkout-index plumbingmanipulators +git-checkout mainporcelain +git-check-ref-format purehelpers +git-cherry ancillaryinterrogators +git-cherry-pick mainporcelain +git-clean mainporcelain +git-clone mainporcelain +git-commit mainporcelain +git-commit-tree plumbingmanipulators +git-convert-objects ancillarymanipulators +git-count-objects ancillaryinterrogators +git-cvsexportcommit foreignscminterface +git-cvsimport foreignscminterface +git-cvsserver foreignscminterface +git-daemon synchingrepositories +git-describe mainporcelain +git-diff-files plumbinginterrogators +git-diff-index plumbinginterrogators +git-diff mainporcelain +git-diff-tree plumbinginterrogators +git-fast-import ancillarymanipulators +git-fetch mainporcelain +git-fetch-pack synchingrepositories +git-fmt-merge-msg purehelpers +git-for-each-ref plumbinginterrogators +git-format-patch mainporcelain +git-fsck ancillaryinterrogators +git-gc mainporcelain +git-get-tar-commit-id ancillaryinterrogators +git-grep mainporcelain +git-hash-object plumbingmanipulators +git-http-fetch synchelpers +git-http-push synchelpers +git-imap-send foreignscminterface +git-index-pack plumbingmanipulators +git-init mainporcelain +git-instaweb ancillaryinterrogators +gitk mainporcelain +git-local-fetch synchingrepositories +git-log mainporcelain +git-lost-found ancillarymanipulators +git-ls-files plumbinginterrogators +git-ls-remote plumbinginterrogators +git-ls-tree plumbinginterrogators +git-mailinfo purehelpers +git-mailsplit purehelpers +git-merge-base plumbinginterrogators +git-merge-file plumbingmanipulators +git-merge-index plumbingmanipulators +git-merge mainporcelain +git-merge-one-file purehelpers +git-merge-tree ancillaryinterrogators +git-mktag plumbingmanipulators +git-mktree plumbingmanipulators +git-mv mainporcelain +git-name-rev plumbinginterrogators +git-pack-objects plumbingmanipulators +git-pack-redundant plumbinginterrogators +git-pack-refs ancillarymanipulators +git-parse-remote synchelpers +git-patch-id purehelpers +git-peek-remote purehelpers +git-prune ancillarymanipulators +git-prune-packed plumbingmanipulators +git-pull mainporcelain +git-push mainporcelain +git-quiltimport foreignscminterface +git-read-tree plumbingmanipulators +git-rebase mainporcelain +git-receive-pack synchelpers +git-reflog ancillarymanipulators +git-relink ancillarymanipulators +git-repack ancillarymanipulators +git-config ancillarymanipulators +git-request-pull foreignscminterface +git-rerere ancillaryinterrogators +git-reset mainporcelain +git-revert mainporcelain +git-rev-list plumbinginterrogators +git-rev-parse ancillaryinterrogators +git-rm mainporcelain +git-runstatus ancillaryinterrogators +git-send-email foreignscminterface +git-send-pack synchingrepositories +git-shell synchelpers +git-shortlog mainporcelain +git-show mainporcelain +git-show-branch ancillaryinterrogators +git-show-index plumbinginterrogators +git-show-ref plumbinginterrogators +git-sh-setup purehelpers +git-ssh-fetch synchingrepositories +git-ssh-upload synchingrepositories +git-status mainporcelain +git-stripspace purehelpers +git-svn foreignscminterface +git-svnimport foreignscminterface +git-symbolic-ref plumbingmanipulators +git-tag mainporcelain +git-tar-tree plumbinginterrogators +git-unpack-file plumbinginterrogators +git-unpack-objects plumbingmanipulators +git-update-index plumbingmanipulators +git-update-ref plumbingmanipulators +git-update-server-info synchingrepositories +git-upload-archive synchelpers +git-upload-pack synchelpers +git-var plumbinginterrogators +git-verify-pack plumbinginterrogators +git-verify-tag ancillaryinterrogators +git-whatchanged ancillaryinterrogators +git-write-tree plumbingmanipulators diff --git a/Documentation/config.txt b/Documentation/config.txt index b4aae0d0ae..38655350f2 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2,21 +2,84 @@ CONFIGURATION FILE ------------------ The git configuration file contains a number of variables that affect -the git command's behavior. They can be used by both the git plumbing +the git command's behavior. `.git/config` file for each repository +is used to store the information for that repository, and +`$HOME/.gitconfig` is used to store per user information to give +fallback values for `.git/config` file. + +They can be used by both the git plumbing and the porcelains. The variables are divided into sections, where in the fully qualified variable name the variable itself is the last dot-separated segment and the section name is everything before the last dot. The variable names are case-insensitive and only alphanumeric characters are allowed. Some variables may appear multiple times. +Syntax +~~~~~~ + The syntax is fairly flexible and permissive; whitespaces are mostly -ignored. The '#' and ';' characters begin comments to the end of line, -blank lines are ignored, lines containing strings enclosed in square -brackets start sections and all the other lines are recognized -as setting variables, in the form 'name = value'. If there is no equal -sign on the line, the entire line is taken as 'name' and the variable -is recognized as boolean "true". String values may be entirely or partially -enclosed in double quotes; some variables may require special value format. +ignored. The '#' and ';' characters begin comments to the end of line, +blank lines are ignored. + +The file consists of sections and variables. A section begins with +the name of the section in square brackets and continues until the next +section begins. Section names are not case sensitive. Only alphanumeric +characters, '`-`' and '`.`' are allowed in section names. Each variable +must belong to some section, which means that there must be section +header before first setting of a variable. + +Sections can be further divided into subsections. To begin a subsection +put its name in double quotes, separated by space from the section name, +in the section header, like in example below: + +-------- + [section "subsection"] + +-------- + +Subsection names can contain any characters except newline (doublequote +'`"`' and backslash have to be escaped as '`\"`' and '`\\`', +respectively) and are case sensitive. Section header cannot span multiple +lines. Variables may belong directly to a section or to a given subsection. +You can have `[section]` if you have `[section "subsection"]`, but you +don't need to. + +There is also (case insensitive) alternative `[section.subsection]` syntax. +In this syntax subsection names follow the same restrictions as for section +name. + +All the other lines are recognized as setting variables, in the form +'name = value'. If there is no equal sign on the line, the entire line +is taken as 'name' and the variable is recognized as boolean "true". +The variable names are case-insensitive and only alphanumeric +characters and '`-`' are allowed. There can be more than one value +for a given variable; we say then that variable is multivalued. + +Leading and trailing whitespace in a variable value is discarded. +Internal whitespace within a variable value is retained verbatim. + +The values following the equals sign in variable assign are all either +a string, an integer, or a boolean. Boolean values may be given as yes/no, +0/1 or true/false. Case is not significant in boolean values, when +converting value to the canonical form using '--bool' type specifier; +`git-config` will ensure that the output is "true" or "false". + +String values may be entirely or partially enclosed in double quotes. +You need to enclose variable value in double quotes if you want to +preserve leading or trailing whitespace, or if variable value contains +beginning of comment characters (if it contains '#' or ';'). +Double quote '`"`' and backslash '`\`' characters in variable value must +be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'. + +The following escape sequences (beside '`\"`' and '`\\`') are recognized: +'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB) +and '`\b`' for backspace (BS). No other char escape sequence, nor octal +char sequences are valid. + +Variable value ending in a '`\`' is continued on the next line in the +customary UNIX fashion. + +Some variables may require special value format. Example ~~~~~~~ @@ -35,6 +98,10 @@ Example remote = origin merge = refs/heads/devel + # Proxy settings + [core] + gitProxy="ssh" for "ssh://kernel.org/" + gitProxy=default-proxy ; for the rest Variables ~~~~~~~~~ @@ -100,7 +167,7 @@ core.sharedRepository:: group-writable). When 'all' (or 'world' or 'everybody'), the repository will be readable by all users, additionally to being group-shareable. When 'umask' (or 'false'), git will use permissions - reported by umask(2). See gitlink:git-init-db[1]. False by default. + reported by umask(2). See gitlink:git-init[1]. False by default. core.warnAmbiguousRefs:: If true, git will warn you if the ref name you passed it is ambiguous @@ -155,6 +222,12 @@ alias.*:: spaces, the usual shell quoting and escaping is supported. quote pair and a backslash can be used to quote them. + If the alias expansion is prefixed with an exclamation point, + it will be treated as a shell command. For example, defining + "alias.new = !gitk --all --not ORIG_HEAD", the invocation + "git new" is equivalent to running the shell command + "gitk --all --not ORIG_HEAD". + apply.whitespace:: Tells `git-apply` how to handle whitespaces, in the same way as the '--whitespace' option. See gitlink:git-apply[1]. @@ -183,10 +256,15 @@ color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch), `remote` (a tracking branch in refs/remotes/), `plain` (other - refs), or `reset` (the normal terminal color). The value for - these configuration variables can be one of: `normal`, `bold`, - `dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`, - `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`. + refs). ++ +The value for these configuration variables is a list of colors (at most +two) and attributes (at most one), separated by spaces. The colors +accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`, +`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`, +`blink` and `reverse`. The first color given is the foreground; the +second is the background. The position of the attribute, if any, +doesn't matter. color.diff:: When true (or `always`), always use colors in patch. @@ -194,12 +272,13 @@ color.diff:: colors only when the output is to the terminal. color.diff.<slot>:: - Use customized color for diff colorization. `<slot>` - specifies which part of the patch to use the specified - color, and is one of `plain` (context text), `meta` - (metainformation), `frag` (hunk header), `old` (removed - lines), or `new` (added lines). The values of these - variables may be specified as in color.branch.<slot>. + Use customized color for diff colorization. `<slot>` specifies + which part of the patch to use the specified color, and is one + of `plain` (context text), `meta` (metainformation), `frag` + (hunk header), `old` (removed lines), `new` (added lines), + `commit` (commit headers), or `whitespace` (highlighting dubious + whitespace). The values of these variables may be specified as + in color.branch.<slot>. color.pager:: A boolean to enable/disable colored output when the pager is in @@ -228,10 +307,31 @@ diff.renames:: will enable basic rename detection. If set to "copies" or "copy", it will detect copies, as well. +fetch.unpackLimit:: + If the number of objects fetched over the git native + transfer is below this + limit, then the objects will be unpacked into loose object + files. However if the number of received objects equals or + exceeds this limit then the received pack will be stored as + a pack, after adding any missing delta bases. Storing the + pack from a push can make the push operation complete faster, + especially on slow filesystems. + format.headers:: Additional email headers to include in a patch to be submitted by mail. See gitlink:git-format-patch[1]. +gc.packrefs:: + `git gc` does not run `git pack-refs` in a bare repository by + default so that older dumb-transport clients can still fetch + from the repository. Setting this to `true` lets `git + gc` to run `git pack-refs`. Setting this to `false` tells + `git gc` never to run `git pack-refs`. The default setting is + `notbare`. Enable it only when you know you do not have to + support such clients. The default setting will change to `true` + at some stage, and setting this to `false` will continue to + prevent `git pack-refs` from being run from `git gc`. + gc.reflogexpire:: `git reflog expire` removes reflog entries older than this time; defaults to 90 days. @@ -321,6 +421,13 @@ merge.summary:: Whether to include summaries of merged commits in newly created merge commit messages. False by default. +merge.verbosity:: + Controls the amount of output shown by the recursive merge + strategy. Level 0 outputs nothing except a final error + message if conflicts were detected. Level 1 outputs only + conflicts, 2 outputs conflicts and file changes. Level 5 and + above outputs debugging information. The default is level 2. + pack.window:: The size of the window used by gitlink:git-pack-objects[1] when no window size is given on the command line. Defaults to 10. @@ -344,6 +451,14 @@ remote.<name>.push:: The default set of "refspec" for gitlink:git-push[1]. See gitlink:git-push[1]. +remote.<name>.receivepack:: + The default program to execute on the remote side when pushing. See + option \--exec of gitlink:git-push[1]. + +remote.<name>.uploadpack:: + The default program to execute on the remote side when fetching. See + option \--exec of gitlink:git-fetch-pack[1]. + repack.usedeltabaseoffset:: Allow gitlink:git-repack[1] to create packs that uses delta-base offset. Defaults to false. @@ -377,6 +492,13 @@ user.name:: Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME' environment variables. See gitlink:git-commit-tree[1]. +user.signingkey:: + If gitlink:git-tag[1] is not selecting the key you want it to + automatically when creating a signed tag, you can override the + default selection with this variable. This option is passed + unchanged to gpg's --local-user parameter, so you may specify a key + using any method that gpg supports. + whatchanged.difftree:: The default gitlink:git-diff-tree[1] arguments to be used for gitlink:git-whatchanged[1]. @@ -400,3 +522,8 @@ receive.denyNonFastForwards:: even if that push is forced. This configuration variable is set when initializing a shared repository. +transfer.unpackLimit:: + When `fetch.unpackLimit` or `receive.unpackLimit` are + not set, the value of this variable is used instead. + + diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt new file mode 100644 index 0000000000..24b060b91e --- /dev/null +++ b/Documentation/core-intro.txt @@ -0,0 +1,591 @@ +//////////////////////////////////////////////////////////////// + + GIT - the stupid content tracker + +//////////////////////////////////////////////////////////////// + +"git" can mean anything, depending on your mood. + + - random three-letter combination that is pronounceable, and not + actually used by any common UNIX command. The fact that it is a + mispronunciation of "get" may or may not be relevant. + - stupid. contemptible and despicable. simple. Take your pick from the + dictionary of slang. + - "global information tracker": you're in a good mood, and it actually + works for you. Angels sing, and a light suddenly fills the room. + - "goddamn idiotic truckload of sh*t": when it breaks + +This is a (not so) stupid but extremely fast directory content manager. +It doesn't do a whole lot at its core, but what it 'does' do is track +directory contents efficiently. + +There are two object abstractions: the "object database", and the +"current directory cache" aka "index". + +The Object Database +~~~~~~~~~~~~~~~~~~~ +The object database is literally just a content-addressable collection +of objects. All objects are named by their content, which is +approximated by the SHA1 hash of the object itself. Objects may refer +to other objects (by referencing their SHA1 hash), and so you can +build up a hierarchy of objects. + +All objects have a statically determined "type" aka "tag", which is +determined at object creation time, and which identifies the format of +the object (i.e. how it is used, and how it can refer to other +objects). There are currently four different object types: "blob", +"tree", "commit" and "tag". + +A "blob" object cannot refer to any other object, and is, like the type +implies, a pure storage object containing some user data. It is used to +actually store the file data, i.e. a blob object is associated with some +particular version of some file. + +A "tree" object is an object that ties one or more "blob" objects into a +directory structure. In addition, a tree object can refer to other tree +objects, thus creating a directory hierarchy. + +A "commit" object ties such directory hierarchies together into +a DAG of revisions - each "commit" is associated with exactly one tree +(the directory hierarchy at the time of the commit). In addition, a +"commit" refers to one or more "parent" commit objects that describe the +history of how we arrived at that directory hierarchy. + +As a special case, a commit object with no parents is called the "root" +object, and is the point of an initial project commit. Each project +must have at least one root, and while you can tie several different +root objects together into one project by creating a commit object which +has two or more separate roots as its ultimate parents, that's probably +just going to confuse people. So aim for the notion of "one root object +per project", even if git itself does not enforce that. + +A "tag" object symbolically identifies and can be used to sign other +objects. It contains the identifier and type of another object, a +symbolic name (of course!) and, optionally, a signature. + +Regardless of object type, all objects share the following +characteristics: they are all deflated with zlib, and have a header +that not only specifies their type, but also provides size information +about the data in the object. It's worth noting that the SHA1 hash +that is used to name the object is the hash of the original data +plus this header, so `sha1sum` 'file' does not match the object name +for 'file'. +(Historical note: in the dawn of the age of git the hash +was the sha1 of the 'compressed' object.) + +As a result, the general consistency of an object can always be tested +independently of the contents or the type of the object: all objects can +be validated by verifying that (a) their hashes match the content of the +file and (b) the object successfully inflates to a stream of bytes that +forms a sequence of <ascii type without space> + <space> + <ascii decimal +size> + <byte\0> + <binary object data>. + +The structured objects can further have their structure and +connectivity to other objects verified. This is generally done with +the `git-fsck` program, which generates a full dependency graph +of all objects, and verifies their internal consistency (in addition +to just verifying their superficial consistency through the hash). + +The object types in some more detail: + +Blob Object +~~~~~~~~~~~ +A "blob" object is nothing but a binary blob of data, and doesn't +refer to anything else. There is no signature or any other +verification of the data, so while the object is consistent (it 'is' +indexed by its sha1 hash, so the data itself is certainly correct), it +has absolutely no other attributes. No name associations, no +permissions. It is purely a blob of data (i.e. normally "file +contents"). + +In particular, since the blob is entirely defined by its data, if two +files in a directory tree (or in multiple different versions of the +repository) have the same contents, they will share the same blob +object. The object is totally independent of its location in the +directory tree, and renaming a file does not change the object that +file is associated with in any way. + +A blob is typically created when gitlink:git-update-index[1] +is run, and its data can be accessed by gitlink:git-cat-file[1]. + +Tree Object +~~~~~~~~~~~ +The next hierarchical object type is the "tree" object. A tree object +is a list of mode/name/blob data, sorted by name. Alternatively, the +mode data may specify a directory mode, in which case instead of +naming a blob, that name is associated with another TREE object. + +Like the "blob" object, a tree object is uniquely determined by the +set contents, and so two separate but identical trees will always +share the exact same object. This is true at all levels, i.e. it's +true for a "leaf" tree (which does not refer to any other trees, only +blobs) as well as for a whole subdirectory. + +For that reason a "tree" object is just a pure data abstraction: it +has no history, no signatures, no verification of validity, except +that since the contents are again protected by the hash itself, we can +trust that the tree is immutable and its contents never change. + +So you can trust the contents of a tree to be valid, the same way you +can trust the contents of a blob, but you don't know where those +contents 'came' from. + +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, +and your diff will look right. In other words, you can effectively +(and efficiently) tell the difference between any two random trees by +O(n) where "n" is the size of the difference, rather than the size of +the tree. + +Side note 2 on trees: since the name of a "blob" depends entirely and +exclusively on its contents (i.e. there are no names or permissions +involved), you can see trivial renames or permission changes by +noticing that the blob stayed the same. However, renames with data +changes need a smarter "diff" implementation. + +A tree is created with gitlink:git-write-tree[1] and +its data can be accessed by gitlink:git-ls-tree[1]. +Two trees can be compared with gitlink:git-diff-tree[1]. + +Commit Object +~~~~~~~~~~~~~ +The "commit" object is an object that introduces the notion of +history into the picture. In contrast to the other objects, it +doesn't just describe the physical state of a tree, it describes how +we got there, and why. + +A "commit" is defined by the tree-object that it results in, the +parent commits (zero, one or more) that led up to that point, and a +comment on what happened. Again, a commit is not trusted per se: +the contents are well-defined and "safe" due to the cryptographically +strong signatures at all levels, but there is no reason to believe +that the tree is "good" or that the merge information makes sense. +The parents do not have to actually have any relationship with the +result, for example. + +Note on commits: unlike real SCM's, commits do not contain +rename information or file mode change information. All of that is +implicit in the trees involved (the result tree, and the result trees +of the parents), and describing that makes no sense in this idiotic +file manager. + +A commit is created with gitlink:git-commit-tree[1] and +its data can be accessed by gitlink:git-cat-file[1]. + +Trust +~~~~~ +An aside on the notion of "trust". Trust is really outside the scope +of "git", but it's worth noting a few things. First off, since +everything is hashed with SHA1, you 'can' trust that an object is +intact and has not been messed with by external sources. So the name +of an object uniquely identifies a known state - just not a state that +you may want to trust. + +Furthermore, since the SHA1 signature of a commit refers to the +SHA1 signatures of the tree it is associated with and the signatures +of the parent, a single named commit specifies uniquely a whole set +of history, with full contents. You can't later fake any step of the +way once you have the name of a commit. + +So to introduce some real trust in the system, the only thing you need +to do is to digitally sign just 'one' special note, which includes the +name of a top-level commit. Your digital signature shows others +that you trust that commit, and the immutability of the history of +commits tells others that they can trust the whole history. + +In other words, you can easily validate a whole archive by just +sending out a single email that tells the people the name (SHA1 hash) +of the top commit, and digitally sign that email using something +like GPG/PGP. + +To assist in this, git also provides the tag object... + +Tag Object +~~~~~~~~~~ +Git provides the "tag" object to simplify creating, managing and +exchanging symbolic and signed tokens. The "tag" object at its +simplest simply symbolically identifies another object by containing +the sha1, type and symbolic name. + +However it can optionally contain additional signature information +(which git doesn't care about as long as there's less than 8k of +it). This can then be verified externally to git. + +Note that despite the tag features, "git" itself only handles content +integrity; the trust framework (and signature provision and +verification) has to come from outside. + +A tag is created with gitlink:git-mktag[1], +its data can be accessed by gitlink:git-cat-file[1], +and the signature can be verified by +gitlink:git-verify-tag[1]. + + +The "index" aka "Current Directory Cache" +----------------------------------------- +The index is a simple binary file, which contains an efficient +representation of a virtual directory content at some random time. It +does so by a simple array that associates a set of names, dates, +permissions and content (aka "blob") objects together. The cache is +always kept ordered by name, and names are unique (with a few very +specific rules) at any point in time, but the cache has no long-term +meaning, and can be partially updated at any time. + +In particular, the index certainly does not need to be consistent with +the current directory contents (in fact, most operations will depend on +different ways to make the index 'not' be consistent with the directory +hierarchy), but it has three very important attributes: + +'(a) it can re-generate the full state it caches (not just the +directory structure: it contains pointers to the "blob" objects so +that it can regenerate the data too)' + +As a special case, there is a clear and unambiguous one-way mapping +from a current directory cache to a "tree object", which can be +efficiently created from just the current directory cache without +actually looking at any other data. So a directory cache at any one +time uniquely specifies one and only one "tree" object (but has +additional data to make it easy to match up that tree object with what +has happened in the directory) + +'(b) it has efficient methods for finding inconsistencies between that +cached state ("tree object waiting to be instantiated") and the +current state.' + +'(c) it can additionally efficiently represent information about merge +conflicts between different tree objects, allowing each pathname to be +associated with sufficient information about the trees involved that +you can create a three-way merge between them.' + +Those are the three ONLY things that the directory cache does. It's a +cache, and the normal operation is to re-generate it completely from a +known tree object, or update/compare it with a live tree that is being +developed. If you blow the directory cache away entirely, you generally +haven't lost any information as long as you have the name of the tree +that it described. + +At the same time, the index is at the same time also the +staging area for creating new trees, and creating a new tree always +involves a controlled modification of the index file. In particular, +the index file can have the representation of an intermediate tree that +has not yet been instantiated. So the index can be thought of as a +write-back cache, which can contain dirty information that has not yet +been written back to the backing store. + + + +The Workflow +------------ +Generally, all "git" operations work on the index file. Some operations +work *purely* on the index file (showing the current state of the +index), but most operations move data to and from the index file. Either +from the database or from the working directory. Thus there are four +main combinations: + +1) working directory -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update the index with information from the working directory with +the gitlink:git-update-index[1] command. You +generally update the index information by just specifying the filename +you want to update, like so: + + git-update-index filename + +but to avoid common mistakes with filename globbing etc, the command +will not normally add totally new entries or remove old entries, +i.e. it will normally just update existing cache entries. + +To tell git that yes, you really do realize that certain files no +longer exist, or that new files should be added, you +should use the `--remove` and `--add` flags respectively. + +NOTE! A `--remove` flag does 'not' mean that subsequent filenames will +necessarily be removed: if the files still exist in your directory +structure, the index will be updated with their new status, not +removed. The only thing `--remove` means is that update-cache will be +considering a removed file to be a valid thing, and if the file really +does not exist any more, it will update the index accordingly. + +As a special case, you can also do `git-update-index --refresh`, which +will refresh the "stat" information of each index to match the current +stat information. It will 'not' update the object status itself, and +it will only update the fields that are used to quickly test whether +an object still matches its old backing store object. + +2) index -> object database +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You write your current index file to a "tree" object with the program + + git-write-tree + +that doesn't come with any options - it will just write out the +current index into the set of tree objects that describe that state, +and it will return the name of the resulting top-level tree. You can +use that tree to re-generate the index at any time by going in the +other direction: + +3) object database -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You read a "tree" file from the object database, and use that to +populate (and overwrite - don't do this if your index contains any +unsaved state that you might want to restore later!) your current +index. Normal operation is just + + git-read-tree <sha1 of tree> + +and your index file will now be equivalent to the tree that you saved +earlier. However, that is only your 'index' file: your working +directory contents have not been modified. + +4) index -> working directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update your working directory from the index by "checking out" +files. This is not a very common operation, since normally you'd just +keep your files updated, and rather than write to your working +directory, you'd tell the index files about the changes in your +working directory (i.e. `git-update-index`). + +However, if you decide to jump to a new version, or check out somebody +else's version, or just restore a previous tree, you'd populate your +index file with read-tree, and then you need to check out the result +with + + git-checkout-index filename + +or, if you want to check out all of the index, use `-a`. + +NOTE! git-checkout-index normally refuses to overwrite old files, so +if you have an old version of the tree already checked out, you will +need to use the "-f" flag ('before' the "-a" flag or the filename) to +'force' the checkout. + + +Finally, there are a few odds and ends which are not purely moving +from one representation to the other: + +5) Tying it all together +~~~~~~~~~~~~~~~~~~~~~~~~ +To commit a tree you have instantiated with "git-write-tree", you'd +create a "commit" object that refers to that tree and the history +behind it - most notably the "parent" commits that preceded it in +history. + +Normally a "commit" has one parent: the previous state of the tree +before a certain change was made. However, sometimes it can have two +or more parent commits, in which case we call it a "merge", due to the +fact that such a commit brings together ("merges") two or more +previous states represented by other commits. + +In other words, while a "tree" represents a particular directory state +of a working directory, a "commit" represents that state in "time", +and explains how we got there. + +You create a commit object by giving it the tree that describes the +state at the time of the commit, and a list of parents: + + git-commit-tree <tree> -p <parent> [-p <parent2> ..] + +and then giving the reason for the commit on stdin (either through +redirection from a pipe or file, or by just typing it at the tty). + +git-commit-tree will return the name of the object that represents +that commit, and you should save it away for later use. Normally, +you'd commit a new `HEAD` state, and while git doesn't care where you +save the note about that state, in practice we tend to just write the +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + + +6) Examining the data +~~~~~~~~~~~~~~~~~~~~~ + +You can examine the data represented in the object database and the +index with various helper tools. For every object, you can use +gitlink:git-cat-file[1] to examine details about the +object: + + git-cat-file -t <objectname> + +shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use + + git-cat-file blob|tree|commit|tag <objectname> + +to show its contents. NOTE! Trees have binary content, and as a result +there is a special helper for showing that content, called +`git-ls-tree`, which turns the binary content into a more easily +readable form. + +It's especially instructive to look at "commit" objects, since those +tend to be small and fairly self-explanatory. In particular, if you +follow the convention of having the top commit name in `.git/HEAD`, +you can do + + git-cat-file commit HEAD + +to see what the top commit was. + +7) Merging multiple trees +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Git helps you do a three-way merge, which you can expand to n-way by +repeating the merge procedure arbitrary times until you finally +"commit" the state. The normal situation is that you'd only do one +three-way merge (two parents), and commit it, but if you like to, you +can do multiple parents in one go. + +To do a three-way merge, you need the two sets of "commit" objects +that you want to merge, use those to find the closest common parent (a +third "commit" object), and then use those commit objects to find the +state of the directory ("tree" object) at these points. + +To get the "base" for the merge, you first look up the common parent +of two commits with + + git-merge-base <commit1> <commit2> + +which will return you the commit they are both based on. You should +now look up the "tree" objects of those commits, which you can easily +do with (for example) + + git-cat-file commit <commitname> | head -1 + +since the tree object information is always the first line in a commit +object. + +Once you know the three trees you are going to merge (the one +"original" tree, aka the common case, and the two "result" trees, aka +the branches you want to merge), you do a "merge" read into the +index. This will complain if it has to throw away your old index contents, so you should +make sure that you've committed those - in fact you would normally +always do a merge against your last commit (which should thus match +what you have in your current index anyway). + +To do the merge, do + + git-read-tree -m -u <origtree> <yourtree> <targettree> + +which will do all trivial merge operations for you directly in the +index file, and you can just write the result out with +`git-write-tree`. + +Historical note. We did not have `-u` facility when this +section was first written, so we used to warn that +the merge is done in the index file, not in your +working tree, and your working tree will not match your +index after this step. +This is no longer true. The above command, thanks to `-u` +option, updates your working tree with the merge results for +paths that have been trivially merged. + + +8) Merging multiple trees, continued +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sadly, many merges aren't trivial. If there are files that have +been added.moved or removed, or if both branches have modified the +same file, you will be left with an index tree that contains "merge +entries" in it. Such an index tree can 'NOT' be written out to a tree +object, and you will have to resolve any such merge clashes using +other tools before you can write out the result. + +You can examine such index state with `git-ls-files --unmerged` +command. An example: + +------------------------------------------------ +$ git-read-tree -m $orig HEAD $target +$ git-ls-files --unmerged +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c +------------------------------------------------ + +Each line of the `git-ls-files --unmerged` output begins with +the blob mode bits, blob SHA1, 'stage number', and the +filename. The 'stage number' is git's way to say which tree it +came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` +tree, and stage3 `$target` tree. + +Earlier we said that trivial merges are done inside +`git-read-tree -m`. For example, if the file did not change +from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` and `$orig` to `$target` the same way, +obviously the final outcome is what is in `HEAD`. What the +above example shows is that file `hello.c` was changed from +`$orig` to `HEAD` and `$orig` to `$target` in a different way. +You could resolve this by running your favorite 3-way merge +program, e.g. `diff3` or `merge`, on the blob objects from +these three stages yourself, like this: + +------------------------------------------------ +$ git-cat-file blob 263414f... >hello.c~1 +$ git-cat-file blob 06fa6a2... >hello.c~2 +$ git-cat-file blob cc44c73... >hello.c~3 +$ merge hello.c~2 hello.c~1 hello.c~3 +------------------------------------------------ + +This would leave the merge result in `hello.c~2` file, along +with conflict markers if there are conflicts. After verifying +the merge result makes sense, you can tell git what the final +merge result for this file is by: + + mv -f hello.c~2 hello.c + git-update-index hello.c + +When a path is in unmerged state, running `git-update-index` for +that path tells git to mark the path resolved. + +The above is the description of a git merge at the lowest level, +to help you understand what conceptually happens under the hood. +In practice, nobody, not even git itself, uses three `git-cat-file` +for this. There is `git-merge-index` program that extracts the +stages to temporary files and calls a "merge" script on it: + + git-merge-index git-merge-one-file hello.c + +and that is what higher level `git merge -s resolve` is implemented +with. diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt index 5ea611748c..97cdb90cb4 100644 --- a/Documentation/core-tutorial.txt +++ b/Documentation/core-tutorial.txt @@ -46,12 +46,12 @@ to import into git. For our first example, we're going to start a totally new repository from scratch, with no pre-existing files, and we'll call it `git-tutorial`. To start up, create a subdirectory for it, change into that -subdirectory, and initialize the git infrastructure with `git-init-db`: +subdirectory, and initialize the git infrastructure with `git-init`: ------------------------------------------------ $ mkdir git-tutorial $ cd git-tutorial -$ git-init-db +$ git-init ------------------------------------------------ to which git will reply @@ -624,7 +624,7 @@ name for the state at that point. Copying repositories -------------------- -git repositories are normally totally self-sufficient and relocatable +git repositories are normally totally self-sufficient and relocatable. Unlike CVS, for example, there is no separate notion of "repository" and "working tree". A git repository normally *is* the working tree, with the local git information hidden in the `.git` @@ -906,18 +906,13 @@ of it as it can automatically (which in this case is just merge the `example` file, which had no differences in the `mybranch` branch), and say: ---------------- - Trying really trivial in-index merge... - fatal: Merge requires file-level merging - Nope. - ... Auto-merging hello CONFLICT (content): Merge conflict in hello Automatic merge failed; fix up by hand ---------------- -which is way too verbose, but it basically tells you that it failed the -really trivial merge ("Simple merge") and did an "Automatic merge" -instead, but that too failed due to conflicts in `hello`. +It tells you that it did an "Automatic merge", which +failed due to conflicts in `hello`. Not to worry. It left the (trivial) conflict in `hello` in the same form you should already be well used to if you've ever used CVS, so let's just @@ -982,7 +977,7 @@ see more complex cases. Now, let's pretend you are the one who did all the work in `mybranch`, and the fruit of your hard work has finally been merged to the `master` branch. Let's go back to `mybranch`, and run -resolve to get the "upstream changes" back to your branch. +`git merge` to get the "upstream changes" back to your branch. ------------ $ git checkout mybranch @@ -1001,7 +996,7 @@ Fast forward ---------------- Because your branch did not contain anything more than what are -already merged into the `master` branch, the resolve operation did +already merged into the `master` branch, the merge operation did not actually do a merge. Instead, it just updated the top of the tree of your branch to that of the `master` branch. This is often called 'fast forward' merge. @@ -1104,11 +1099,11 @@ programs, which are 'commit walkers'; they outlived their usefulness when git Native and SSH transports were introduced, and not used by `git pull` or `git push` scripts. -Once you fetch from the remote repository, you `resolve` that +Once you fetch from the remote repository, you `merge` that with your current branch. However -- it's such a common thing to `fetch` and then -immediately `resolve`, that it's called `git pull`, and you can +immediately `merge`, that it's called `git pull`, and you can simply do ---------------- @@ -1123,52 +1118,32 @@ You could do without using any branches at all, by keeping as many local repositories as you would like to have branches, and merging between them with `git pull`, just like you merge between branches. The advantage of this approach is -that it lets you keep set of files for each `branch` checked +that it lets you keep a set of files for each `branch` checked out and you may find it easier to switch back and forth if you juggle multiple lines of development simultaneously. Of course, you will pay the price of more disk usage to hold multiple working trees, but disk space is cheap these days. -[NOTE] -You could even pull from your own repository by -giving '.' as <remote-repository> parameter to `git pull`. This -is useful when you want to merge a local branch (or more, if you -are making an Octopus) into the current branch. - It is likely that you will be pulling from the same remote repository from time to time. As a short hand, you can store -the remote repository URL in a file under .git/remotes/ -directory, like this: - ------------------------------------------------- -$ mkdir -p .git/remotes/ -$ cat >.git/remotes/linus <<\EOF -URL: http://www.kernel.org/pub/scm/git/git.git/ -EOF ------------------------------------------------- - -and use the filename to `git pull` instead of the full URL. -The URL specified in such file can even be a prefix -of a full URL, like this: +the remote repository URL in the local repository's config file +like this: ------------------------------------------------ -$ cat >.git/remotes/jgarzik <<\EOF -URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/ -EOF +$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ ------------------------------------------------ +and use the "linus" keyword with `git pull` instead of the full URL. Examples. . `git pull linus` . `git pull linus tag v0.99.1` -. `git pull jgarzik/netdev-2.6.git/ e100` the above are equivalent to: . `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD` . `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1` -. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100` How does the merge work? @@ -1325,7 +1300,7 @@ differences since stage 2 (i.e. your version). Publishing your work -------------------- -So we can use somebody else's work from a remote repository; but +So, we can use somebody else's work from a remote repository, but how can *you* prepare a repository to let other people pull from it? @@ -1371,11 +1346,11 @@ $ mkdir my-git.git ------------ Then, make that directory into a git repository by running -`git init-db`, but this time, since its name is not the usual +`git init`, but this time, since its name is not the usual `.git`, we do things slightly differently: ------------ -$ GIT_DIR=my-git.git git-init-db +$ GIT_DIR=my-git.git git-init ------------ Make sure this directory is available for others you want your @@ -1494,8 +1469,8 @@ Working with Others Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There -is a nice illustration (page 17, "Merges to Mainline") in Randy -Dunlap's presentation (`http://tinyurl.com/a2jdg`). +is a nice illustration (page 17, "Merges to Mainline") in +link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in git that enforces the "chain of @@ -1511,7 +1486,7 @@ A recommended workflow for a "project lead" goes like this: + If other people are pulling from your repository over dumb transport protocols (HTTP), you need to keep this repository -'dumb transport friendly'. After `git init-db`, +'dumb transport friendly'. After `git init`, `$GIT_DIR/hooks/post-update` copied from the standard templates would contain a call to `git-update-server-info` but the `post-update` hook itself is disabled by default -- enable it @@ -1546,7 +1521,8 @@ on that project and has an own "public repository" goes like this: 1. Prepare your work repository, by `git clone` the public repository of the "project lead". The URL used for the - initial cloning is stored in `.git/remotes/origin`. + initial cloning is stored in the remote.origin.url + configuration variable. 2. Prepare a public repository accessible to others, just like the "project lead" person does. @@ -1586,14 +1562,15 @@ like this: 1. Prepare your work repository, by `git clone` the public repository of the "project lead" (or a "subsystem maintainer", if you work on a subsystem). The URL used for - the initial cloning is stored in `.git/remotes/origin`. + the initial cloning is stored in the remote.origin.url + configuration variable. 2. Do your work in your repository on 'master' branch. 3. Run `git fetch origin` from the public repository of your upstream every once in a while. This does only the first half of `git pull` but does not merge. The head of the - public repository is stored in `.git/refs/heads/origin`. + public repository is stored in `.git/refs/remotes/origin/master`. 4. Use `git cherry origin` to see which ones of your patches were accepted, and/or use `git rebase origin` to port your @@ -1681,11 +1658,11 @@ $ git reset --hard master~2 You can make sure 'git show-branch' matches the state before those two 'git merge' you just did. Then, instead of running -two 'git merge' commands in a row, you would pull these two +two 'git merge' commands in a row, you would merge these two branch heads (this is known as 'making an Octopus'): ------------ -$ git pull . commit-fix diff-fix +$ git merge commit-fix diff-fix $ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. @@ -1701,7 +1678,7 @@ $ git show-branch Note that you should not do Octopus because you can. An octopus is a valid thing to do and often makes it easier to view the -commit history if you are pulling more than two independent +commit history if you are merging more than two independent changes at the same time. However, if you have merge conflicts with any of the branches you are merging in and need to hand resolve, that is an indication that the development happened in diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt index 8e09beaa79..764cc560b4 100644 --- a/Documentation/cvs-migration.txt +++ b/Documentation/cvs-migration.txt @@ -36,7 +36,7 @@ them first before running git pull. ================================ 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 repo-config -l` and the gitlink:git-repo-config[1] man +command; see `git config -l` and the gitlink:git-config[1] man page for details. ================================ @@ -80,7 +80,7 @@ it: ------------------------------------------------ $ mkdir /pub/my-repo.git $ cd /pub/my-repo.git -$ git --bare init-db --shared +$ git --bare init --shared $ git --bare fetch /home/alice/myproject master:master ------------------------------------------------ diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt index 883c1bb0a6..378e72f38f 100644 --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -159,7 +159,7 @@ or like this (when '--cc' option is used): deleted file mode <mode>,<mode> + The `mode <mode>,<mode>..<mode>` line appears only if at least one of -the <mode> is diferent from the rest. Extended headers with +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. diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index da1cc60e97..019a39f2bf 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -58,6 +58,10 @@ 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" diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt index cb4e562004..34cd306bb1 100644 --- a/Documentation/diffcore.txt +++ b/Documentation/diffcore.txt @@ -6,8 +6,8 @@ June 2005 Introduction ------------ -The diff commands git-diff-index, git-diff-files, git-diff-tree, and -git-diff-stages can be told to manipulate differences they find in +The diff commands git-diff-index, git-diff-files, and git-diff-tree +can be told to manipulate differences they find in unconventional ways before showing diff(1) output. The manipulation is collectively called "diffcore transformation". This short note describes what they are and how to use them to produce diff outputs @@ -30,9 +30,6 @@ files: - git-diff-tree compares contents of two "tree" objects; - - git-diff-stages compares contents of blobs at two stages in an - unmerged index file. - In all of these cases, the commands themselves compare corresponding paths in the two sets of files. The result of comparison is passed from these commands to what is internally diff --git a/Documentation/docbook-xsl.css b/Documentation/docbook-xsl.css new file mode 100644 index 0000000000..8821e305dd --- /dev/null +++ b/Documentation/docbook-xsl.css @@ -0,0 +1,286 @@ +/*
+ CSS stylesheet for XHTML produced by DocBook XSL stylesheets.
+ Tested with XSL stylesheets 1.61.2, 1.67.2
+*/
+
+span.strong {
+ font-weight: bold;
+}
+
+body blockquote {
+ margin-top: .75em;
+ line-height: 1.5;
+ margin-bottom: .75em;
+}
+
+html body {
+ margin: 1em 5% 1em 5%;
+ line-height: 1.2;
+}
+
+body div {
+ margin: 0;
+}
+
+h1, h2, h3, h4, h5, h6,
+div.toc p b,
+div.list-of-figures p b,
+div.list-of-tables p b,
+div.abstract p.title
+{
+ color: #527bbd;
+ font-family: tahoma, verdana, sans-serif;
+}
+
+div.toc p:first-child,
+div.list-of-figures p:first-child,
+div.list-of-tables p:first-child,
+div.example p.title
+{
+ margin-bottom: 0.2em;
+}
+
+body h1 {
+ margin: .0em 0 0 -4%;
+ line-height: 1.3;
+ border-bottom: 2px solid silver;
+}
+
+body h2 {
+ margin: 0.5em 0 0 -4%;
+ line-height: 1.3;
+ border-bottom: 2px solid silver;
+}
+
+body h3 {
+ margin: .8em 0 0 -3%;
+ line-height: 1.3;
+}
+
+body h4 {
+ margin: .8em 0 0 -3%;
+ line-height: 1.3;
+}
+
+body h5 {
+ margin: .8em 0 0 -2%;
+ line-height: 1.3;
+}
+
+body h6 {
+ margin: .8em 0 0 -1%;
+ line-height: 1.3;
+}
+
+body hr {
+ border: none; /* Broken on IE6 */
+}
+div.footnotes hr {
+ border: 1px solid silver;
+}
+
+div.navheader th, div.navheader td, div.navfooter td {
+ font-family: sans-serif;
+ font-size: 0.9em;
+ font-weight: bold;
+ color: #527bbd;
+}
+div.navheader img, div.navfooter img {
+ border-style: none;
+}
+div.navheader a, div.navfooter a {
+ font-weight: normal;
+}
+div.navfooter hr {
+ border: 1px solid silver;
+}
+
+body td {
+ line-height: 1.2
+}
+
+body th {
+ line-height: 1.2;
+}
+
+ol {
+ line-height: 1.2;
+}
+
+ul, body dir, body menu {
+ line-height: 1.2;
+}
+
+html {
+ margin: 0;
+ padding: 0;
+}
+
+body h1, body h2, body h3, body h4, body h5, body h6 {
+ margin-left: 0
+}
+
+body pre {
+ margin: 0.5em 10% 0.5em 1em;
+ line-height: 1.0;
+ color: navy;
+}
+
+tt.literal, code.literal {
+ color: navy;
+}
+
+div.literallayout p {
+ padding: 0em;
+ margin: 0em;
+}
+
+div.literallayout {
+ font-family: monospace;
+# margin: 0.5em 10% 0.5em 1em;
+ margin: 0em;
+ color: navy;
+ border: 1px solid silver;
+ background: #f4f4f4;
+ padding: 0.5em;
+}
+
+.programlisting, .screen {
+ border: 1px solid silver;
+ background: #f4f4f4;
+ margin: 0.5em 10% 0.5em 0;
+ padding: 0.5em 1em;
+}
+
+div.sidebar {
+ background: #ffffee;
+ margin: 1.0em 10% 0.5em 0;
+ padding: 0.5em 1em;
+ border: 1px solid silver;
+}
+div.sidebar * { padding: 0; }
+div.sidebar div { margin: 0; }
+div.sidebar p.title {
+ font-family: sans-serif;
+ margin-top: 0.5em;
+ margin-bottom: 0.2em;
+}
+
+div.bibliomixed {
+ margin: 0.5em 5% 0.5em 1em;
+}
+
+div.glossary dt {
+ font-weight: bold;
+}
+div.glossary dd p {
+ margin-top: 0.2em;
+}
+
+dl {
+ margin: .8em 0;
+ line-height: 1.2;
+}
+
+dt {
+ margin-top: 0.5em;
+}
+
+dt span.term {
+ font-style: italic;
+}
+
+div.variablelist dd p {
+ margin-top: 0;
+}
+
+div.itemizedlist li, div.orderedlist li {
+ margin-left: -0.8em;
+ margin-top: 0.5em;
+}
+
+ul, ol {
+ list-style-position: outside;
+}
+
+div.sidebar ul, div.sidebar ol {
+ margin-left: 2.8em;
+}
+
+div.itemizedlist p.title,
+div.orderedlist p.title,
+div.variablelist p.title
+{
+ margin-bottom: -0.8em;
+}
+
+div.revhistory table {
+ border-collapse: collapse;
+ border: none;
+}
+div.revhistory th {
+ border: none;
+ color: #527bbd;
+ font-family: tahoma, verdana, sans-serif;
+}
+div.revhistory td {
+ border: 1px solid silver;
+}
+
+/* Keep TOC and index lines close together. */
+div.toc dl, div.toc dt,
+div.list-of-figures dl, div.list-of-figures dt,
+div.list-of-tables dl, div.list-of-tables dt,
+div.indexdiv dl, div.indexdiv dt
+{
+ line-height: normal;
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+/*
+ Table styling does not work because of overriding attributes in
+ generated HTML.
+*/
+div.table table,
+div.informaltable table
+{
+ margin-left: 0;
+ margin-right: 5%;
+ margin-bottom: 0.8em;
+}
+div.informaltable table
+{
+ margin-top: 0.4em
+}
+div.table thead,
+div.table tfoot,
+div.table tbody,
+div.informaltable thead,
+div.informaltable tfoot,
+div.informaltable tbody
+{
+ /* No effect in IE6. */
+ border-top: 2px solid #527bbd;
+ border-bottom: 2px solid #527bbd;
+}
+div.table thead, div.table tfoot,
+div.informaltable thead, div.informaltable tfoot
+{
+ font-weight: bold;
+}
+
+div.mediaobject img {
+ border: 1px solid silver;
+ margin-bottom: 0.8em;
+}
+div.figure p.title,
+div.table p.title
+{
+ margin-top: 1em;
+ margin-bottom: 0.4em;
+}
+
+@media print {
+ div.navheader, div.navfooter { display: none; }
+}
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 4e83994c58..08c61b1f1a 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -28,7 +28,7 @@ Everybody uses these commands to maintain git repositories. * gitlink:git-init[1] or gitlink:git-clone[1] to create a new repository. - * gitlink:git-fsck-objects[1] to check the repository for errors. + * gitlink:git-fsck[1] to check the repository for errors. * gitlink:git-prune[1] to remove unused objects in the repository. @@ -43,7 +43,7 @@ Examples Check health and remove cruft.:: + ------------ -$ git fsck-objects <1> +$ git fsck <1> $ git count-objects <2> $ git repack <3> $ git gc <4> @@ -148,8 +148,7 @@ modification will be caught if you do `git commit -a` later. <8> redo the commit undone in the previous step, using the message you originally wrote. <9> switch to the master branch. -<10> merge a topic branch into your master branch. You can also use -`git pull . alsa-audio`, i.e. pull from the local repository. +<10> merge a topic branch into your master branch. <11> review commit logs; other forms to limit output can be combined and include `\--max-count=10` (show 10 commits), `\--until=2005-12-10`, etc. @@ -213,12 +212,12 @@ Push into another repository.:: ------------ satellite$ git clone mothership:frotz frotz <1> satellite$ cd frotz -satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2> +satellite$ git config --get-regexp '^(remote|branch)\.' <2> remote.origin.url mothership:frotz remote.origin.fetch refs/heads/*:refs/remotes/origin/* branch.master.remote origin branch.master.merge refs/heads/master -satellite$ git repo-config remote.origin.push \ +satellite$ git config remote.origin.push \ master:refs/remotes/satellite/master <3> satellite$ edit/compile/test/commit satellite$ git push origin <4> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 95bea66374..b73a99d61f 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next SYNOPSIS -------- -'git-add' [-n] [-v] [-f] [--interactive] [--] <file>... +'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>... DESCRIPTION ----------- @@ -52,7 +52,7 @@ OPTIONS -f:: Allow adding otherwise ignored files. -\--interactive:: +\i, \--interactive:: Add modified contents in the working tree interactively to the index. @@ -83,7 +83,7 @@ git-add git-*.sh:: Interactive mode ---------------- When the command enters the interactive mode, it shows the -output of the 'status' subcommand, and then goes into ints +output of the 'status' subcommand, and then goes into its interactive command loop. The command loop shows the list of subcommands available, and diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 53e81cb103..4fb1d84413 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -3,14 +3,15 @@ git-am(1) NAME ---- -git-am - Apply a series of patches in a mailbox +git-am - Apply a series of patches from a mailbox SYNOPSIS -------- [verse] 'git-am' [--signoff] [--dotest=<dir>] [--utf8 | --no-utf8] [--binary] [--3way] - [--interactive] [--whitespace=<option>] <mbox>... + [--interactive] [--whitespace=<option>] [-C<n>] [-p<n>] + <mbox>... 'git-am' [--skip | --resolved] DESCRIPTION @@ -21,6 +22,10 @@ current branch. OPTIONS ------- +<mbox>...:: + The list of mailbox files to read patches from. If you do not + supply this argument, reads from the standard input. + --signoff:: Add `Signed-off-by:` line to the commit message, using the committer identity of yourself. @@ -64,6 +69,10 @@ default. You could use `--no-utf8` to override this. This flag is passed to the `git-apply` program that applies the patch. +-C<n>, -p<n>:: + These flag are passed to the `git-apply` program that applies + the patch. + --interactive:: Run interactively, just like git-applymbox. diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 33b93db508..065ba1bf24 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -3,7 +3,7 @@ git-apply(1) NAME ---- -git-apply - Apply patch on a git index file and a work tree +git-apply - Apply a patch on a git index file and a working tree SYNOPSIS diff --git a/Documentation/git-applymbox.txt b/Documentation/git-applymbox.txt index f74c6a49b3..95dc65a583 100644 --- a/Documentation/git-applymbox.txt +++ b/Documentation/git-applymbox.txt @@ -42,13 +42,13 @@ OPTIONS and the current tree. -u:: - By default, the commit log message, author name and - author email are taken from the e-mail without any - charset conversion, after minimally decoding MIME - transfer encoding. This flag causes the resulting - commit to be encoded in utf-8 by transliterating them. - Note that the patch is always used as is without charset - conversion, even with this flag. + The commit log message, author name and author email are + taken from the e-mail, and after minimally decoding MIME + transfer encoding, re-coded in UTF-8 by transliterating + them. 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. -c .dotest/<num>:: When the patch contained in an e-mail does not cleanly diff --git a/Documentation/git-applypatch.txt b/Documentation/git-applypatch.txt index 2b1ff1454b..451434a757 100644 --- a/Documentation/git-applypatch.txt +++ b/Documentation/git-applypatch.txt @@ -12,6 +12,9 @@ SYNOPSIS DESCRIPTION ----------- +This is usually not what an end user wants to run directly. See +gitlink: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. diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 031fcd5190..493474b2ee 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -3,7 +3,7 @@ git-archive(1) NAME ---- -git-archive - Creates a archive of the files in the named tree +git-archive - Creates an archive of files from a named tree SYNOPSIS diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index ac4b4965a9..16ec7269b2 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -3,7 +3,7 @@ git-bisect(1) NAME ---- -git-bisect - Find the change that introduced a bug +git-bisect - Find the change that introduced a bug by binary search SYNOPSIS diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index bdfc666928..5c9888d014 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -8,8 +8,8 @@ git-blame - Show what revision and author last modified each line of a file SYNOPSIS -------- [verse] -'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] - [-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file> +'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [--incremental] [-L n,m] [-S <revs-file>] + [-M] [-C] [-C] [--since=<date>] [<rev> | --contents <file>] [--] <file> DESCRIPTION ----------- @@ -24,7 +24,7 @@ replaced; you need to use a tool such as gitlink: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 +development history for when a code snippet occurred 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: @@ -63,6 +63,17 @@ OPTIONS -p, --porcelain:: Show in a format designed for machine consumption. +--incremental:: + Show the result incrementally in a format designed for + machine consumption. + +--contents <file>:: + When <rev> is not specified, the command annotates the + changes starting backwards from the working tree copy. + This flag makes the command pretend as if the working + tree copy has the contents of he named file (specify + `-` to make the command read from the standard input). + -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 @@ -89,7 +100,7 @@ THE PORCELAIN FORMAT -------------------- In this format, each line is output after a header; the -header at the minumum has the first line which has: +header at the minimum 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; @@ -112,15 +123,18 @@ header, prefixed by a TAB. This is to allow adding more header elements later. -SPECIFIYING RANGES ------------------- +SPECIFYING 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: +ll. 40-60 for file `foo`, you can use `-L` option like these +(they mean the same thing -- both ask for 21 lines starting at +line 40): git blame -L 40,60 foo + git blame -L 40,+21 foo Also you can use regular expression to specify the line range. @@ -155,6 +169,47 @@ parents, using `commit{caret}!` notation: git blame -C -C -f $commit^! -- foo +INCREMENTAL OUTPUT +------------------ + +When called with `--incremental` option, the command outputs the +result as it is built. The output generally will talk about +lines touched by more recent commits first (i.e. the lines will +be annotated out of order) and is meant to be used by +interactive viewers. + +The output format is similar to the Porcelain format, but it +does not contain the actual lines from the file that is being +annotated. + +. Each blame entry always starts with a line of: + + <40-byte hex sha1> <sourceline> <resultline> <num_lines> ++ +Line numbers count from 1. + +. The first time that commit shows up in the stream, it has various + other information about it printed out with a one-word tag at the + beginning of each line about that "extended commit info" (author, + email, committer, dates, summary etc). + +. Unlike Porcelain format, the filename information is always + given and terminates the entry: + + "filename" <whitespace-quoted-filename-goes-here> ++ +and thus it's really quite easy to parse for some line- and word-oriented +parser (which should be quite natural for most scripting languages). ++ +[NOTE] +For people who do parsing: to make it more robust, just ignore any +lines in between the first and last one ("<sha1>" and "filename" lines) +where you don't recognize the tag-words (or care about that particular +one) at the beginning of the "extended information" lines. That way, if +there is ever added information (like the commit encoding or extended +commit commentary), a blame viewer won't ever care. + + SEE ALSO -------- gitlink:git-annotate[1] diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index e872fc89fc..aa1fdd402a 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -3,7 +3,7 @@ git-branch(1) NAME ---- -git-branch - List, create, or delete branches. +git-branch - List, create, or delete branches SYNOPSIS -------- @@ -74,7 +74,7 @@ OPTIONS List both remote-tracking branches and local branches. -v:: - Show sha1 and commit subjectline for each head. + Show sha1 and commit subject line for each head. --abbrev=<length>:: Alter minimum display length for sha1 in output listing, diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 5e9cbf875d..075c0d05ef 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -3,7 +3,7 @@ git-cat-file(1) NAME ---- -git-cat-file - Provide content or type information for repository objects +git-cat-file - Provide content or type/size information for repository objects SYNOPSIS @@ -19,7 +19,9 @@ or '-s' is used to find the object size. OPTIONS ------- <object>:: - The sha1 identifier of the object. + The name of the object to show. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. -t:: Instead of the content, show the object type identified by diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt index 765c173e15..6dd6db04bb 100644 --- a/Documentation/git-checkout-index.txt +++ b/Documentation/git-checkout-index.txt @@ -3,7 +3,7 @@ git-checkout-index(1) NAME ---- -git-checkout-index - Copy files from the index to the working directory +git-checkout-index - Copy files from the index to the working tree SYNOPSIS diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index fbdbadc74f..e4ffde4fdd 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -8,8 +8,8 @@ git-checkout - Checkout and switch to a branch SYNOPSIS -------- [verse] -'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>] -'git-checkout' [-m] [<branch>] <paths>... +'git-checkout' [-q] [-f] [-b <new_branch> [-l]] [-m] [<branch>] +'git-checkout' [<tree-ish>] <paths>... DESCRIPTION ----------- @@ -22,15 +22,20 @@ be created. When <paths> are given, this command does *not* switch branches. It updates the named paths in the working tree from -the index file (i.e. it runs `git-checkout-index -f -u`). In +the index file (i.e. it runs `git-checkout-index -f -u`), or a +named commit. In this case, `-f` and `-b` options are meaningless and giving -either of them results in an error. <branch> argument can be -used to specify a specific tree-ish to update the index for the -given paths before updating the working tree. +either of them results in an error. <tree-ish> argument can be +used to specify a specific tree-ish (i.e. commit, tag or tree) +to update the index for the given paths before updating the +working tree. OPTIONS ------- +-q:: + Quiet, supress feedback messages. + -f:: Force a re-read of everything. @@ -63,7 +68,47 @@ and mark the resolved paths with `git update-index`. <branch>:: Branch to checkout; may be any object ID that resolves to a - commit. Defaults to HEAD. + commit. Defaults to HEAD. ++ +When this parameter names a non-branch (but still a valid commit object), +your HEAD becomes 'detached'. + + +Detached HEAD +------------- + +It is sometimes useful to be able to 'checkout' a commit that is +not at the tip of one of your branches. The most obvious +example is to check out the commit at a tagged official release +point, like this: + +------------ +$ git checkout v2.6.18 +------------ + +Earlier versions of git did not allow this and asked you to +create a temporary branch using `-b` option, but starting from +version 1.5.0, the above command 'detaches' your HEAD from the +current branch and directly point at the commit named by the tag +(`v2.6.18` in the above example). + +You can use usual git commands while in this state. You can use +`git-reset --hard $othercommit` to further move around, for +example. You can make changes and create a new commit on top of +a detached HEAD. You can even create a merge by using `git +merge $othercommit`. + +The state you are in while your HEAD is detached is not recorded +by any branch (which is natural --- you are not on any branch). +What this means is that you can discard your temporary commits +and merges by switching back to an existing branch (e.g. `git +checkout master`), and a later `git prune` or `git gc` would +garbage-collect them. If you did this by mistake, you can ask +the reflog for HEAD where you were, e.g. + +------------ +$ git log -g -2 HEAD +------------ EXAMPLES diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 875edb6b9f..3149d08da8 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -19,6 +19,8 @@ OPTIONS ------- <commit>:: Commit to cherry-pick. + For a more complete list of ways to spell commits, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. -e|--edit:: With this option, `git-cherry-pick` will let you edit the commit diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index a78207461d..707376f22c 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -3,7 +3,7 @@ git-clone(1) NAME ---- -git-clone - Clones a repository +git-clone - Clones a repository into a new directory SYNOPSIS diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt index 77ba96ed8a..cf25507f8f 100644 --- a/Documentation/git-commit-tree.txt +++ b/Documentation/git-commit-tree.txt @@ -3,7 +3,7 @@ git-commit-tree(1) NAME ---- -git-commit-tree - Creates a new commit object +git-commit-tree - Create a new commit object SYNOPSIS @@ -12,6 +12,9 @@ SYNOPSIS DESCRIPTION ----------- +This is usually not what an end user wants to run directly. See +gitlink:git-commit[1] instead. + Creates a new commit object based on the provided tree object and emits the new commit object id on stdout. If no parent is given then it is considered to be an initial tree. diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index a7adf24fa5..2187eee416 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -3,13 +3,13 @@ git-commit(1) NAME ---- -git-commit - Record your changes +git-commit - Record changes to the repository SYNOPSIS -------- [verse] -'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] - [--no-verify] [--amend] [-e] [--author <author>] +'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg> | + --amend] [--no-verify] [-e] [--author <author>] [--] [[-i | -o ]<file>...] DESCRIPTION @@ -32,7 +32,8 @@ methods: 4. by using the -a switch with the 'commit' command to automatically "add" changes from all known files i.e. files that have already been committed - before, and perform the actual commit. + before, and to automatically "rm" files that have been + removed from the working tree, and perform the actual commit. The gitlink:git-status[1] command can be used to obtain a summary of what is included by any of the above for the next @@ -72,12 +73,8 @@ OPTIONS Add Signed-off-by line at the end of the commit message. --no-verify:: - By default, the command looks for suspicious lines the - commit introduces, and aborts committing if there is one. - The definition of 'suspicious lines' is currently the - lines that has trailing whitespaces, and the lines whose - indentation has a SP character immediately followed by a - TAB character. This option turns off the check. + This option bypasses the pre-commit hook. + See also link:hooks.html[hooks]. -e|--edit:: The message taken from file with `-F`, command line with @@ -114,7 +111,7 @@ but can be used to amend a merge commit. are concluding a conflicted merge. -q|--quiet:: - Supress commit summary message. + Suppress commit summary message. \--:: Do not interpret any more arguments as options. @@ -145,11 +142,6 @@ $ git add hello.c $ git commit ------------ -//////////// -We should fix 'git rm' to remove goodbye.c from both index and -working tree for the above example. -//////////// - Instead of staging files after each individual change, you can tell `git commit` to notice the changes to the files whose contents are tracked in @@ -226,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option). DISCUSSION ---------- +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. + include::i18n.txt[] ENVIRONMENT VARIABLES diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt new file mode 100644 index 0000000000..6624484fe1 --- /dev/null +++ b/Documentation/git-config.txt @@ -0,0 +1,227 @@ +git-config(1) +============= + +NAME +---- +git-config - Get and set repository or global options + + +SYNOPSIS +-------- +[verse] +'git-config' [--global] [type] name [value [value_regex]] +'git-config' [--global] [type] --add name value +'git-config' [--global] [type] --replace-all name [value [value_regex]] +'git-config' [--global] [type] --get name [value_regex] +'git-config' [--global] [type] --get-all name [value_regex] +'git-config' [--global] [type] --unset name [value_regex] +'git-config' [--global] [type] --unset-all name [value_regex] +'git-config' [--global] -l | --list + +DESCRIPTION +----------- +You can query/set/replace/unset options with this command. The name is +actually the section and the key separated by a dot, and the value will be +escaped. + +Multiple lines can be added to an option by using the '--add' option. +If you want to update or unset an option which can occur on multiple +lines, a POSIX regexp `value_regex` needs to be given. Only the +existing values that match the regexp are updated or unset. If +you want to handle the lines that do *not* match the regex, just +prepend a single exclamation mark in front (see EXAMPLES). + +The type specifier can be either '--int' or '--bool', which will make +'git-config' ensure that the variable(s) are of the given type and +convert the value to the canonical form (simple decimal number for int, +a "true" or "false" string for bool). If no type specifier is passed, +no checks or transformations are performed on the value. + +This command will fail if: + +. The .git/config file is invalid, +. Can not write to .git/config, +. no section was provided, +. the section or key is invalid, +. you try to unset an option which does not exist, +. you try to unset/set an option for which multiple lines match, or +. you use --global option without $HOME being properly set. + + +OPTIONS +------- + +--replace-all:: + Default behavior is to replace at most one line. This replaces + all lines matching the key (and optionally the value_regex). + +--add:: + Adds a new line to the option without altering any existing + values. This is the same as providing '^$' as the value_regex. + +--get:: + Get the value for a given key (optionally filtered by a regex + matching the value). Returns error code 1 if the key was not + found and error code 2 if multiple key values were found. + +--get-all:: + Like get, but does not fail if the number of values for the key + is not exactly one. + +--get-regexp:: + Like --get-all, but interprets the name as a regular expression. + +--global:: + Use global ~/.gitconfig file rather than the repository .git/config. + +--unset:: + Remove the line matching the key from config file. + +--unset-all:: + Remove all matching lines from config file. + +-l, --list:: + List all variables set in config file. + +--bool:: + git-config will ensure that the output is "true" or "false" + +--int:: + git-config will ensure that the output is a simple + decimal number. An optional value suffix of 'k', 'm', or 'g' + in the config file will cause the value to be multiplied + by 1024, 1048576, or 1073741824 prior to output. + + +ENVIRONMENT +----------- + +GIT_CONFIG:: + Take the configuration from the given file instead of .git/config. + Using the "--global" option forces this to ~/.gitconfig. + +GIT_CONFIG_LOCAL:: + Currently the same as $GIT_CONFIG; when Git will support global + configuration files, this will cause it to take the configuration + from the global configuration file in addition to the given file. + + +EXAMPLE +------- + +Given a .git/config like this: + + # + # This is the config file, and + # a '#' or ';' character indicates + # a comment + # + + ; core variables + [core] + ; Don't trust file modes + filemode = false + + ; Our diff algorithm + [diff] + external = "/usr/local/bin/gnu-diff -u" + renames = true + + ; Proxy settings + [core] + gitproxy="ssh" for "ssh://kernel.org/" + gitproxy="proxy-command" for kernel.org + gitproxy="myprotocol-command" for "my://" + gitproxy=default-proxy ; for all the rest + +you can set the filemode to true with + +------------ +% git config core.filemode true +------------ + +The hypothetical proxy command entries actually have a postfix to discern +what URL they apply to. Here is how to change the entry for kernel.org +to "ssh". + +------------ +% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$' +------------ + +This makes sure that only the key/value pair for kernel.org is replaced. + +To delete the entry for renames, do + +------------ +% git config --unset diff.renames +------------ + +If you want to delete an entry for a multivar (like core.gitproxy above), +you have to provide a regex matching the value of exactly one line. + +To query the value for a given key, do + +------------ +% git config --get core.filemode +------------ + +or + +------------ +% git config core.filemode +------------ + +or, to query a multivar: + +------------ +% git config --get core.gitproxy "for kernel.org$" +------------ + +If you want to know all the values for a multivar, do: + +------------ +% git config --get-all core.gitproxy +------------ + +If you like to live dangerous, you can replace *all* core.gitproxy by a +new one with + +------------ +% git config --replace-all core.gitproxy ssh +------------ + +However, if you really only want to replace the line for the default proxy, +i.e. the one without a "for ..." postfix, do something like this: + +------------ +% git config core.gitproxy ssh '! for ' +------------ + +To actually match only values with an exclamation mark, you have to + +------------ +% git config section.key value '[!]' +------------ + +To add a new proxy, without altering any of the existing ones, use + +------------ +% git config core.gitproxy '"proxy" for example.com' +------------ + + +include::config.txt[] + + +Author +------ +Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> + +Documentation +-------------- +Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index c59df6438c..91c8c92c76 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -3,7 +3,7 @@ git-count-objects(1) NAME ---- -git-count-objects - Reports on unpacked objects +git-count-objects - Count unpacked number of objects and their disk consumption SYNOPSIS -------- diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt index 092d0d6730..27d531b888 100644 --- a/Documentation/git-cvsexportcommit.txt +++ b/Documentation/git-cvsexportcommit.txt @@ -3,12 +3,12 @@ git-cvsexportcommit(1) NAME ---- -git-cvsexportcommit - Export a commit to a CVS checkout +git-cvsexportcommit - Export a single commit to a CVS checkout SYNOPSIS -------- -'git-cvsexportcommit' [-h] [-v] [-c] [-p] [-a] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID +'git-cvsexportcommit' [-h] [-v] [-c] [-P] [-p] [-a] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID DESCRIPTION @@ -46,6 +46,9 @@ OPTIONS -f:: Force the merge even if the files are not up to date. +-P:: + Force the parent commit, even if it is not a direct parent. + -m:: Prepend the commit message with the provided prefix. Useful for patch series and the like. diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 5c402de267..f5450de74a 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -3,7 +3,7 @@ git-cvsimport(1) NAME ---- -git-cvsimport - Import a CVS repository into git +git-cvsimport - Salvage your data out of another SCM people love to hate SYNOPSIS @@ -97,7 +97,7 @@ If you need to pass multiple options, separate them with a comma. Substitute the character "/" in branch names with <subst> -A <author-conv-file>:: - CVS by default uses the unix username when writing its + CVS by default uses the Unix username when writing its commit logs. Using this option and an author-conv-file in this format diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 993adc7c5a..9ddab71203 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -131,14 +131,14 @@ Giving these options is an error when used with `--inetd`; use the facility of inet daemon to achieve the same before spawning `git-daemon` if needed. ---enable-service, --disable-service:: +--enable=service, --disable=service:: Enable/disable the service site-wide per default. Note that a service disabled site-wide can still be enabled per repository if it is marked overridable and the repository enables the service with an configuration item. ---allow-override, --forbid-override:: +--allow-override=service, --forbid-override=service:: Allow/forbid overriding the site-wide default with per repository configuration. By default, all the services are overridable. diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 2700f35bdb..47a583d3a6 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -14,8 +14,8 @@ DESCRIPTION ----------- The command finds the most recent tag that is reachable from a commit, and if the commit itself is pointed at by the tag, shows -the tag. Otherwise, it suffixes the tag name with abbreviated -object name of the commit. +the tag. Otherwise, it suffixes the tag name with the number of +additional commits and the abbreviated object name of the commit. OPTIONS @@ -35,6 +35,16 @@ OPTIONS Instead of using the default 8 hexadecimal digits as the abbreviated object name, use <n> digits. +--candidates=<n>:: + Instead of considering only the 10 most recent tags as + candidates to describe the input committish consider + up to <n> candidates. Increasing <n> above 10 will take + slightly longer but may produce a more accurate result. + +--debug:: + Verbosely display information about the searching strategy + being employed to standard error. The tag name will still + be printed to standard out. EXAMPLES -------- @@ -42,12 +52,18 @@ EXAMPLES With something like git.git current tree, I get: [torvalds@g5 git]$ git-describe parent - v1.0.4-g2414721b + v1.0.4-14-g2414721 i.e. the current head of my "parent" branch is based on v1.0.4, -but since it has a few commits on top of that, it has added the -git hash of the thing to the end: "-g" + 8-char shorthand for -the commit `2414721b194453f058079d897d13c4e377f92dc6`. +but since it has a handful commits on top of that, +describe has added the number of additional commits ("14") and +an abbreviated object name for the commit itself ("2414721") +at the end. + +The number of additional commits is the number +of commits which would be displayed by "git log v1.0.4..parent". +The hash suffix is "-g" + 7-char abbreviation for the tip commit +of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). Doing a "git-describe" on a tag-name will just show the tag name: @@ -58,16 +74,43 @@ With --all, the command can use branch heads as references, so the output shows the reference path as well: [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2 - tags/v1.0.0-g975b + tags/v1.0.0-21-g975b [torvalds@g5 git]$ git describe --all HEAD^ - heads/lt/describe-g975b + heads/lt/describe-7-g975b + +With --abbrev set to 0, the command can be used to find the +closest tagname without any suffix: + + [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2 + tags/v1.0.0 + +SEARCH STRATEGY +--------------- + +For each committish supplied "git describe" will first look for +a tag which tags exactly that commit. Annotated tags will always +be preferred over lightweight tags, and tags with newer dates will +always be preferred over tags with older dates. If an exact match +is found, its name will be output and searching will stop. + +If an exact match was not found "git describe" will walk back +through the commit history to locate an ancestor commit which +has been tagged. The ancestor's tag will be output along with an +abbreviation of the input committish's SHA1. + +If multiple tags were found during the walk then the tag which +has the fewest commits different from the input committish will be +selected and output. Here fewest commits different is defined as +the number of commits which would be shown by "git log tag..input" +will be the smallest number of commits possible. Author ------ Written by Linus Torvalds <torvalds@osdl.org>, but somewhat -butchered by Junio C Hamano <junkio@cox.net> +butchered by Junio C Hamano <junkio@cox.net>. Later significantly +updated by Shawn Pearce <spearce@spearce.org>. Documentation -------------- diff --git a/Documentation/git-diff-stages.txt b/Documentation/git-diff-stages.txt deleted file mode 100644 index 3273918627..0000000000 --- a/Documentation/git-diff-stages.txt +++ /dev/null @@ -1,40 +0,0 @@ -git-diff-stages(1) -================== - -NAME ----- -git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file - - -SYNOPSIS --------- -'git-diff-stages' [<common diff options>] <stage1> <stage2> [<path>...] - -DESCRIPTION ------------ -Compares the content and mode of the blobs in two stages in an -unmerged index file. - -OPTIONS -------- -include::diff-options.txt[] - -<stage1>,<stage2>:: - The stage number to be compared. - -Output format -------------- -include::diff-format.txt[] - - -Author ------- -Written by Junio C Hamano <junkio@cox.net> - -Documentation --------------- -Documentation by Junio C Hamano. - -GIT ---- -Part of the gitlink:git[7] suite diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 8977877b21..6a098df26b 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -47,6 +47,9 @@ Just in case if you are doing something exotic, it should be noted that all of the <commit> in the above description can be any <tree-ish>. +For a more complete list of ways to spell <commit>, see +"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. + OPTIONS ------- diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt new file mode 100644 index 0000000000..445f6b8544 --- /dev/null +++ b/Documentation/git-fast-import.txt @@ -0,0 +1,901 @@ +git-fast-import(1) +================== + +NAME +---- +git-fast-import - Backend for fast Git data importers. + + +SYNOPSIS +-------- +frontend | 'git-fast-import' [options] + +DESCRIPTION +----------- +This program is usually not what the end user wants to run directly. +Most end users want to use one of the existing frontend programs, +which parses a specific type of foreign source and feeds the contents +stored there to git-fast-import. + +fast-import reads a mixed command/data stream from standard input and +writes one or more packfiles directly into the current repository. +When EOF is received on standard input, fast import writes out +updated branch and tag refs, fully updating the current repository +with the newly imported data. + +The fast-import backend itself can import into an empty repository (one that +has already been initialized by gitlink:git-init[1]) or incrementally +update an existing populated repository. Whether or not incremental +imports are supported from a particular foreign source depends on +the frontend program in use. + + +OPTIONS +------- +--date-format=<fmt>:: + Specify the type of dates the frontend will supply to + fast-import within `author`, `committer` and `tagger` commands. + See ``Date Formats'' below for details about which formats + are supported, and their syntax. + +--force:: + Force updating modified existing branches, even if doing + so would cause commits to be lost (as the new commit does + not contain the old commit). + +--max-pack-size=<n>:: + Maximum size of each output packfile, expressed in MiB. + The default is 4096 (4 GiB) as that is the maximum allowed + packfile size (due to file format limitations). Some + importers may wish to lower this, such as to ensure the + resulting packfiles fit on CDs. + +--depth=<n>:: + Maximum delta depth, for blob and tree deltification. + Default is 10. + +--active-branches=<n>:: + Maximum number of branches to maintain active at once. + See ``Memory Utilization'' below for details. Default is 5. + +--export-marks=<file>:: + Dumps the internal marks table to <file> when complete. + Marks are written one per line as `:markid SHA-1`. + Frontends can use this file to validate imports after they + have been completed. + +--export-pack-edges=<file>:: + After creating a packfile, print a line of data to + <file> listing the filename of the packfile and the last + commit on each branch that was written to that packfile. + This information may be useful after importing projects + whose total object set exceeds the 4 GiB packfile limit, + as these commits can be used as edge points during calls + to gitlink:git-pack-objects[1]. + +--quiet:: + Disable all non-fatal output, making fast-import silent when it + is successful. This option disables the output shown by + \--stats. + +--stats:: + Display some basic statistics about the objects fast-import has + created, the packfiles they were stored into, and the + memory used by fast-import during this run. Showing this output + is currently the default, but can be disabled with \--quiet. + + +Performance +----------- +The design of fast-import allows it to import large projects in a minimum +amount of memory usage and processing time. Assuming the frontend +is able to keep up with fast-import and feed it a constant stream of data, +import times for projects holding 10+ years of history and containing +100,000+ individual commits are generally completed in just 1-2 +hours on quite modest (~$2,000 USD) hardware. + +Most bottlenecks appear to be in foreign source data access (the +source just cannot extract revisions fast enough) or disk IO (fast-import +writes as fast as the disk will take the data). Imports will run +faster if the source data is stored on a different drive than the +destination Git repository (due to less IO contention). + + +Development Cost +---------------- +A typical frontend for fast-import tends to weigh in at approximately 200 +lines of Perl/Python/Ruby code. Most developers have been able to +create working importers in just a couple of hours, even though it +is their first exposure to fast-import, and sometimes even to Git. This is +an ideal situation, given that most conversion tools are throw-away +(use once, and never look back). + + +Parallel Operation +------------------ +Like `git-push` or `git-fetch`, imports handled by fast-import are safe to +run alongside parallel `git repack -a -d` or `git gc` invocations, +or any other Git operation (including `git prune`, as loose objects +are never used by fast-import). + +fast-import does not lock the branch or tag refs it is actively importing. +After the import, during its ref update phase, fast-import tests each +existing branch ref to verify the update will be a fast-forward +update (the commit stored in the ref is contained in the new +history of the commit to be written). If the update is not a +fast-forward update, fast-import will skip updating that ref and instead +prints a warning message. fast-import will always attempt to update all +branch refs, and does not stop on the first failure. + +Branch updates can be forced with \--force, but its recommended that +this only be used on an otherwise quiet repository. Using \--force +is not necessary for an initial import into an empty repository. + + +Technical Discussion +-------------------- +fast-import tracks a set of branches in memory. Any branch can be created +or modified at any point during the import process by sending a +`commit` command on the input stream. This design allows a frontend +program to process an unlimited number of branches simultaneously, +generating commits in the order they are available from the source +data. It also simplifies the frontend programs considerably. + +fast-import does not use or alter the current working directory, or any +file within it. (It does however update the current Git repository, +as referenced by `GIT_DIR`.) Therefore an import frontend may use +the working directory for its own purposes, such as extracting file +revisions from the foreign source. This ignorance of the working +directory also allows fast-import to run very quickly, as it does not +need to perform any costly file update operations when switching +between branches. + +Input Format +------------ +With the exception of raw file data (which Git does not interpret) +the fast-import input format is text (ASCII) based. This text based +format simplifies development and debugging of frontend programs, +especially when a higher level language such as Perl, Python or +Ruby is being used. + +fast-import is very strict about its input. Where we say SP below we mean +*exactly* one space. Likewise LF means one (and only one) linefeed. +Supplying additional whitespace characters will cause unexpected +results, such as branch names or file names with leading or trailing +spaces in their name, or early termination of fast-import when it encounters +unexpected input. + +Date Formats +~~~~~~~~~~~~ +The following date formats are supported. A frontend should select +the format it will use for this import by passing the format name +in the \--date-format=<fmt> command line option. + +`raw`:: + This is the Git native format and is `<time> SP <offutc>`. + It is also fast-import's default format, if \--date-format was + not specified. ++ +The time of the event is specified by `<time>` as the number of +seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is +written as an ASCII decimal integer. ++ +The local offset is specified by `<offutc>` as a positive or negative +offset from UTC. For example EST (which is 5 hours behind UTC) +would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''. +The local offset does not affect `<time>`; it is used only as an +advisement to help formatting routines display the timestamp. ++ +If the local offset is not available in the source material, use +``+0000'', or the most common local offset. For example many +organizations have a CVS repository which has only ever been accessed +by users who are located in the same location and timezone. In this +case a reasonable offset from UTC could be assumed. ++ +Unlike the `rfc2822` format, this format is very strict. Any +variation in formatting will cause fast-import to reject the value. + +`rfc2822`:: + This is the standard email format as described by RFC 2822. ++ +An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git +parser is accurate, but a little on the lenient side. It is the +same parser used by gitlink:git-am[1] when applying patches +received from email. ++ +Some malformed strings may be accepted as valid dates. In some of +these cases Git will still be able to obtain the correct date from +the malformed string. There are also some types of malformed +strings which Git will parse wrong, and yet consider valid. +Seriously malformed strings will be rejected. ++ +Unlike the `raw` format above, the timezone/UTC offset information +contained in an RFC 2822 date string is used to adjust the date +value to UTC prior to storage. Therefore it is important that +this information be as accurate as possible. ++ +If the source material uses RFC 2822 style dates, +the frontend should let fast-import handle the parsing and conversion +(rather than attempting to do it itself) as the Git parser has +been well tested in the wild. ++ +Frontends should prefer the `raw` format if the source material +already uses UNIX-epoch format, can be coaxed to give dates in that +format, or its format is easiliy convertible to it, as there is no +ambiguity in parsing. + +`now`:: + Always use the current time and timezone. The literal + `now` must always be supplied for `<when>`. ++ +This is a toy format. The current time and timezone of this system +is always copied into the identity string at the time it is being +created by fast-import. There is no way to specify a different time or +timezone. ++ +This particular format is supplied as its short to implement and +may be useful to a process that wants to create a new commit +right now, without needing to use a working directory or +gitlink:git-update-index[1]. ++ +If separate `author` and `committer` commands are used in a `commit` +the timestamps may not match, as the system clock will be polled +twice (once for each command). The only way to ensure that both +author and committer identity information has the same timestamp +is to omit `author` (thus copying from `committer`) or to use a +date format other than `now`. + +Commands +~~~~~~~~ +fast-import accepts several commands to update the current repository +and control the current import process. More detailed discussion +(with examples) of each command follows later. + +`commit`:: + Creates a new branch or updates an existing branch by + creating a new commit and updating the branch to point at + the newly created commit. + +`tag`:: + Creates an annotated tag object from an existing commit or + branch. Lightweight tags are not supported by this command, + as they are not recommended for recording meaningful points + in time. + +`reset`:: + Reset an existing branch (or a new branch) to a specific + revision. This command must be used to change a branch to + a specific revision without making a commit on it. + +`blob`:: + Convert raw file data into a blob, for future use in a + `commit` command. This command is optional and is not + needed to perform an import. + +`checkpoint`:: + Forces fast-import to close the current packfile, generate its + unique SHA-1 checksum and index, and start a new packfile. + This command is optional and is not needed to perform + an import. + +`commit` +~~~~~~~~ +Create or update a branch with a new commit, recording one logical +change to the project. + +.... + 'commit' SP <ref> LF + mark? + ('author' SP <name> SP LT <email> GT SP <when> LF)? + 'committer' SP <name> SP LT <email> GT SP <when> LF + data + ('from' SP <committish> LF)? + ('merge' SP <committish> LF)? + (filemodify | filedelete | filedeleteall)* + LF +.... + +where `<ref>` is the name of the branch to make the commit on. +Typically branch names are prefixed with `refs/heads/` in +Git, so importing the CVS branch symbol `RELENG-1_0` would use +`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of +`<ref>` must be a valid refname in Git. As `LF` is not valid in +a Git refname, no quoting or escaping syntax is supported here. + +A `mark` command may optionally appear, requesting fast-import to save a +reference to the newly created commit for future use by the frontend +(see below for format). It is very common for frontends to mark +every commit they create, thereby allowing future branch creation +from any imported commit. + +The `data` command following `committer` must supply the commit +message (see below for `data` command syntax). To import an empty +commit message use a 0 length data. Commit messages are free-form +and are not interpreted by Git. Currently they must be encoded in +UTF-8, as fast-import does not permit other encodings to be specified. + +Zero or more `filemodify`, `filedelete` and `filedeleteall` commands +may be included to update the contents of the branch prior to +creating the commit. These commands may be supplied in any order. +However it is recommended that a `filedeleteall` command preceed +all `filemodify` commands in the same commit, as `filedeleteall` +wipes the branch clean (see below). + +`author` +^^^^^^^^ +An `author` command may optionally appear, if the author information +might differ from the committer information. If `author` is omitted +then fast-import will automatically use the committer's information for +the author portion of the commit. See below for a description of +the fields in `author`, as they are identical to `committer`. + +`committer` +^^^^^^^^^^^ +The `committer` command indicates who made this commit, and when +they made it. + +Here `<name>` is the person's display name (for example +``Com M Itter'') and `<email>` is the person's email address +(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c) +and greater-than (\x3e) symbols. These are required to delimit +the email address from the other fields in the line. Note that +`<name>` is free-form and may contain any sequence of bytes, except +`LT` and `LF`. It is typically UTF-8 encoded. + +The time of the change is specified by `<when>` using the date format +that was selected by the \--date-format=<fmt> command line option. +See ``Date Formats'' above for the set of supported formats, and +their syntax. + +`from` +^^^^^^ +The `from` command is used to specify the commit to initialize +this branch from. This revision will be the first ancestor of the +new commit. + +Omitting the `from` command in the first commit of a new branch +will cause fast-import to create that commit with no ancestor. This +tends to be desired only for the initial commit of a project. +Omitting the `from` command on existing branches is usually desired, +as the current commit on that branch is automatically assumed to +be the first ancestor of the new commit. + +As `LF` is not valid in a Git refname or SHA-1 expression, no +quoting or escaping syntax is supported within `<committish>`. + +Here `<committish>` is any of the following: + +* The name of an existing branch already in fast-import's internal branch + table. If fast-import doesn't know the name, its treated as a SHA-1 + expression. + +* A mark reference, `:<idnum>`, where `<idnum>` is the mark number. ++ +The reason fast-import uses `:` to denote a mark reference is this character +is not legal in a Git branch name. The leading `:` makes it easy +to distingush between the mark 42 (`:42`) and the branch 42 (`42` +or `refs/heads/42`), or an abbreviated SHA-1 which happened to +consist only of base-10 digits. ++ +Marks must be declared (via `mark`) before they can be used. + +* A complete 40 byte or abbreviated commit SHA-1 in hex. + +* Any valid Git SHA-1 expression that resolves to a commit. See + ``SPECIFYING REVISIONS'' in gitlink:git-rev-parse[1] for details. + +The special case of restarting an incremental import from the +current branch value should be written as: +---- + from refs/heads/branch^0 +---- +The `{caret}0` suffix is necessary as fast-import does not permit a branch to +start from itself, and the branch is created in memory before the +`from` command is even read from the input. Adding `{caret}0` will force +fast-import to resolve the commit through Git's revision parsing library, +rather than its internal branch table, thereby loading in the +existing value of the branch. + +`merge` +^^^^^^^ +Includes one additional ancestor commit, and makes the current +commit a merge commit. An unlimited number of `merge` commands per +commit are permitted by fast-import, thereby establishing an n-way merge. +However Git's other tools never create commits with more than 15 +additional ancestors (forming a 16-way merge). For this reason +it is suggested that frontends do not use more than 15 `merge` +commands per commit. + +Here `<committish>` is any of the commit specification expressions +also accepted by `from` (see above). + +`filemodify` +^^^^^^^^^^^^ +Included in a `commit` command to add a new file or change the +content of an existing file. This command has two different means +of specifying the content of the file. + +External data format:: + The data content for the file was already supplied by a prior + `blob` command. The frontend just needs to connect it. ++ +.... + 'M' SP <mode> SP <dataref> SP <path> LF +.... ++ +Here `<dataref>` can be either a mark reference (`:<idnum>`) +set by a prior `blob` command, or a full 40-byte SHA-1 of an +existing Git blob object. + +Inline data format:: + The data content for the file has not been supplied yet. + The frontend wants to supply it as part of this modify + command. ++ +.... + 'M' SP <mode> SP 'inline' SP <path> LF + data +.... ++ +See below for a detailed description of the `data` command. + +In both formats `<mode>` is the type of file entry, specified +in octal. Git only supports the following modes: + +* `100644` or `644`: A normal (not-executable) file. The majority + of files in most projects use this mode. If in doubt, this is + what you want. +* `100755` or `755`: A normal, but executable, file. +* `120000`: A symlink, the content of the file will be the link target. + +In both formats `<path>` is the complete path of the file to be added +(if not already existing) or modified (if already existing). + +A `<path>` string must use UNIX-style directory seperators (forward +slash `/`), may contain any byte other than `LF`, and must not +start with double quote (`"`). + +If an `LF` or double quote must be encoded into `<path>` shell-style +quoting should be used, e.g. `"path/with\n and \" in it"`. + +The value of `<path>` must be in canoncial form. That is it must not: + +* contain an empty directory component (e.g. `foo//bar` is invalid), +* end with a directory seperator (e.g. `foo/` is invalid), +* start with a directory seperator (e.g. `/foo` is invalid), +* contain the special component `.` or `..` (e.g. `foo/./bar` and + `foo/../bar` are invalid). + +It is recommended that `<path>` always be encoded using UTF-8. + +`filedelete` +^^^^^^^^^^^^ +Included in a `commit` command to remove a file from the branch. +If the file removal makes its directory empty, the directory will +be automatically removed too. This cascades up the tree until the +first non-empty directory or the root is reached. + +.... + 'D' SP <path> LF +.... + +here `<path>` is the complete path of the file to be removed. +See `filemodify` above for a detailed description of `<path>`. + +`filedeleteall` +^^^^^^^^^^^^^^^ +Included in a `commit` command to remove all files (and also all +directories) from the branch. This command resets the internal +branch structure to have no files in it, allowing the frontend +to subsequently add all interesting files from scratch. + +.... + 'deleteall' LF +.... + +This command is extremely useful if the frontend does not know +(or does not care to know) what files are currently on the branch, +and therefore cannot generate the proper `filedelete` commands to +update the content. + +Issuing a `filedeleteall` followed by the needed `filemodify` +commands to set the correct content will produce the same results +as sending only the needed `filemodify` and `filedelete` commands. +The `filedeleteall` approach may however require fast-import to use slightly +more memory per active branch (less than 1 MiB for even most large +projects); so frontends that can easily obtain only the affected +paths for a commit are encouraged to do so. + +`mark` +~~~~~~ +Arranges for fast-import to save a reference to the current object, allowing +the frontend to recall this object at a future point in time, without +knowing its SHA-1. Here the current object is the object creation +command the `mark` command appears within. This can be `commit`, +`tag`, and `blob`, but `commit` is the most common usage. + +.... + 'mark' SP ':' <idnum> LF +.... + +where `<idnum>` is the number assigned by the frontend to this mark. +The value of `<idnum>` is expressed as an ASCII decimal integer. +The value 0 is reserved and cannot be used as +a mark. Only values greater than or equal to 1 may be used as marks. + +New marks are created automatically. Existing marks can be moved +to another object simply by reusing the same `<idnum>` in another +`mark` command. + +`tag` +~~~~~ +Creates an annotated tag referring to a specific commit. To create +lightweight (non-annotated) tags see the `reset` command below. + +.... + 'tag' SP <name> LF + 'from' SP <committish> LF + 'tagger' SP <name> SP LT <email> GT SP <when> LF + data + LF +.... + +where `<name>` is the name of the tag to create. + +Tag names are automatically prefixed with `refs/tags/` when stored +in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would +use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the +corresponding ref as `refs/tags/RELENG-1_0-FINAL`. + +The value of `<name>` must be a valid refname in Git and therefore +may contain forward slashes. As `LF` is not valid in a Git refname, +no quoting or escaping syntax is supported here. + +The `from` command is the same as in the `commit` command; see +above for details. + +The `tagger` command uses the same format as `committer` within +`commit`; again see above for details. + +The `data` command following `tagger` must supply the annotated tag +message (see below for `data` command syntax). To import an empty +tag message use a 0 length data. Tag messages are free-form and are +not interpreted by Git. Currently they must be encoded in UTF-8, +as fast-import does not permit other encodings to be specified. + +Signing annotated tags during import from within fast-import is not +supported. Trying to include your own PGP/GPG signature is not +recommended, as the frontend does not (easily) have access to the +complete set of bytes which normally goes into such a signature. +If signing is required, create lightweight tags from within fast-import with +`reset`, then create the annotated versions of those tags offline +with the standard gitlink:git-tag[1] process. + +`reset` +~~~~~~~ +Creates (or recreates) the named branch, optionally starting from +a specific revision. The reset command allows a frontend to issue +a new `from` command for an existing branch, or to create a new +branch from an existing commit without creating a new commit. + +.... + 'reset' SP <ref> LF + ('from' SP <committish> LF)? + LF +.... + +For a detailed description of `<ref>` and `<committish>` see above +under `commit` and `from`. + +The `reset` command can also be used to create lightweight +(non-annotated) tags. For example: + +==== + reset refs/tags/938 + from :938 +==== + +would create the lightweight tag `refs/tags/938` referring to +whatever commit mark `:938` references. + +`blob` +~~~~~~ +Requests writing one file revision to the packfile. The revision +is not connected to any commit; this connection must be formed in +a subsequent `commit` command by referencing the blob through an +assigned mark. + +.... + 'blob' LF + mark? + data +.... + +The mark command is optional here as some frontends have chosen +to generate the Git SHA-1 for the blob on their own, and feed that +directly to `commit`. This is typically more work than its worth +however, as marks are inexpensive to store and easy to use. + +`data` +~~~~~~ +Supplies raw data (for use as blob/file content, commit messages, or +annotated tag messages) to fast-import. Data can be supplied using an exact +byte count or delimited with a terminating line. Real frontends +intended for production-quality conversions should always use the +exact byte count format, as it is more robust and performs better. +The delimited format is intended primarily for testing fast-import. + +Exact byte count format:: + The frontend must specify the number of bytes of data. ++ +.... + 'data' SP <count> LF + <raw> LF +.... ++ +where `<count>` is the exact number of bytes appearing within +`<raw>`. The value of `<count>` is expressed as an ASCII decimal +integer. The `LF` on either side of `<raw>` is not +included in `<count>` and will not be included in the imported data. + +Delimited format:: + A delimiter string is used to mark the end of the data. + fast-import will compute the length by searching for the delimiter. + This format is primarly useful for testing and is not + recommended for real data. ++ +.... + 'data' SP '<<' <delim> LF + <raw> LF + <delim> LF +.... ++ +where `<delim>` is the chosen delimiter string. The string `<delim>` +must not appear on a line by itself within `<raw>`, as otherwise +fast-import will think the data ends earlier than it really does. The `LF` +immediately trailing `<raw>` is part of `<raw>`. This is one of +the limitations of the delimited format, it is impossible to supply +a data chunk which does not have an LF as its last byte. + +`checkpoint` +~~~~~~~~~~~~ +Forces fast-import to close the current packfile, start a new one, and to +save out all current branch refs, tags and marks. + +.... + 'checkpoint' LF + LF +.... + +Note that fast-import automatically switches packfiles when the current +packfile reaches \--max-pack-size, or 4 GiB, whichever limit is +smaller. During an automatic packfile switch fast-import does not update +the branch refs, tags or marks. + +As a `checkpoint` can require a significant amount of CPU time and +disk IO (to compute the overall pack SHA-1 checksum, generate the +corresponding index file, and update the refs) it can easily take +several minutes for a single `checkpoint` command to complete. + +Frontends may choose to issue checkpoints during extremely large +and long running imports, or when they need to allow another Git +process access to a branch. However given that a 30 GiB Subversion +repository can be loaded into Git through fast-import in about 3 hours, +explicit checkpointing may not be necessary. + + +Tips and Tricks +--------------- +The following tips and tricks have been collected from various +users of fast-import, and are offered here as suggestions. + +Use One Mark Per Commit +~~~~~~~~~~~~~~~~~~~~~~~ +When doing a repository conversion, use a unique mark per commit +(`mark :<n>`) and supply the \--export-marks option on the command +line. fast-import will dump a file which lists every mark and the Git +object SHA-1 that corresponds to it. If the frontend can tie +the marks back to the source repository, it is easy to verify the +accuracy and completeness of the import by comparing each Git +commit to the corresponding source revision. + +Coming from a system such as Perforce or Subversion this should be +quite simple, as the fast-import mark can also be the Perforce changeset +number or the Subversion revision number. + +Freely Skip Around Branches +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Don't bother trying to optimize the frontend to stick to one branch +at a time during an import. Although doing so might be slightly +faster for fast-import, it tends to increase the complexity of the frontend +code considerably. + +The branch LRU builtin to fast-import tends to behave very well, and the +cost of activating an inactive branch is so low that bouncing around +between branches has virtually no impact on import performance. + +Handling Renames +~~~~~~~~~~~~~~~~ +When importing a renamed file or directory, simply delete the old +name(s) and modify the new name(s) during the corresponding commit. +Git performs rename detection after-the-fact, rather than explicitly +during a commit. + +Use Tag Fixup Branches +~~~~~~~~~~~~~~~~~~~~~~ +Some other SCM systems let the user create a tag from multiple +files which are not from the same commit/changeset. Or to create +tags which are a subset of the files available in the repository. + +Importing these tags as-is in Git is impossible without making at +least one commit which ``fixes up'' the files to match the content +of the tag. Use fast-import's `reset` command to reset a dummy branch +outside of your normal branch space to the base commit for the tag, +then commit one or more file fixup commits, and finally tag the +dummy branch. + +For example since all normal branches are stored under `refs/heads/` +name the tag fixup branch `TAG_FIXUP`. This way it is impossible for +the fixup branch used by the importer to have namespace conflicts +with real branches imported from the source (the name `TAG_FIXUP` +is not `refs/heads/TAG_FIXUP`). + +When committing fixups, consider using `merge` to connect the +commit(s) which are supplying file revisions to the fixup branch. +Doing so will allow tools such as gitlink:git-blame[1] to track +through the real commit history and properly annotate the source +files. + +After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP` +to remove the dummy branch. + +Import Now, Repack Later +~~~~~~~~~~~~~~~~~~~~~~~~ +As soon as fast-import completes the Git repository is completely valid +and ready for use. Typicallly this takes only a very short time, +even for considerably large projects (100,000+ commits). + +However repacking the repository is necessary to improve data +locality and access performance. It can also take hours on extremely +large projects (especially if -f and a large \--window parameter is +used). Since repacking is safe to run alongside readers and writers, +run the repack in the background and let it finish when it finishes. +There is no reason to wait to explore your new Git project! + +If you choose to wait for the repack, don't try to run benchmarks +or performance tests until repacking is completed. fast-import outputs +suboptimal packfiles that are simply never seen in real use +situations. + +Repacking Historical Data +~~~~~~~~~~~~~~~~~~~~~~~~~ +If you are repacking very old imported data (e.g. older than the +last year), consider expending some extra CPU time and supplying +\--window=50 (or higher) when you run gitlink:git-repack[1]. +This will take longer, but will also produce a smaller packfile. +You only need to expend the effort once, and everyone using your +project will benefit from the smaller repository. + + +Packfile Optimization +--------------------- +When packing a blob fast-import always attempts to deltify against the last +blob written. Unless specifically arranged for by the frontend, +this will probably not be a prior version of the same file, so the +generated delta will not be the smallest possible. The resulting +packfile will be compressed, but will not be optimal. + +Frontends which have efficient access to all revisions of a +single file (for example reading an RCS/CVS ,v file) can choose +to supply all revisions of that file as a sequence of consecutive +`blob` commands. This allows fast-import to deltify the different file +revisions against each other, saving space in the final packfile. +Marks can be used to later identify individual file revisions during +a sequence of `commit` commands. + +The packfile(s) created by fast-import do not encourage good disk access +patterns. This is caused by fast-import writing the data in the order +it is received on standard input, while Git typically organizes +data within packfiles to make the most recent (current tip) data +appear before historical data. Git also clusters commits together, +speeding up revision traversal through better cache locality. + +For this reason it is strongly recommended that users repack the +repository with `git repack -a -d` after fast-import completes, allowing +Git to reorganize the packfiles for faster data access. If blob +deltas are suboptimal (see above) then also adding the `-f` option +to force recomputation of all deltas can significantly reduce the +final packfile size (30-50% smaller can be quite typical). + + +Memory Utilization +------------------ +There are a number of factors which affect how much memory fast-import +requires to perform an import. Like critical sections of core +Git, fast-import uses its own memory allocators to ammortize any overheads +associated with malloc. In practice fast-import tends to ammoritize any +malloc overheads to 0, due to its use of large block allocations. + +per object +~~~~~~~~~~ +fast-import maintains an in-memory structure for every object written in +this execution. On a 32 bit system the structure is 32 bytes, +on a 64 bit system the structure is 40 bytes (due to the larger +pointer sizes). Objects in the table are not deallocated until +fast-import terminates. Importing 2 million objects on a 32 bit system +will require approximately 64 MiB of memory. + +The object table is actually a hashtable keyed on the object name +(the unique SHA-1). This storage configuration allows fast-import to reuse +an existing or already written object and avoid writing duplicates +to the output packfile. Duplicate blobs are surprisingly common +in an import, typically due to branch merges in the source. + +per mark +~~~~~~~~ +Marks are stored in a sparse array, using 1 pointer (4 bytes or 8 +bytes, depending on pointer size) per mark. Although the array +is sparse, frontends are still strongly encouraged to use marks +between 1 and n, where n is the total number of marks required for +this import. + +per branch +~~~~~~~~~~ +Branches are classified as active and inactive. The memory usage +of the two classes is significantly different. + +Inactive branches are stored in a structure which uses 96 or 120 +bytes (32 bit or 64 bit systems, respectively), plus the length of +the branch name (typically under 200 bytes), per branch. fast-import will +easily handle as many as 10,000 inactive branches in under 2 MiB +of memory. + +Active branches have the same overhead as inactive branches, but +also contain copies of every tree that has been recently modified on +that branch. If subtree `include` has not been modified since the +branch became active, its contents will not be loaded into memory, +but if subtree `src` has been modified by a commit since the branch +became active, then its contents will be loaded in memory. + +As active branches store metadata about the files contained on that +branch, their in-memory storage size can grow to a considerable size +(see below). + +fast-import automatically moves active branches to inactive status based on +a simple least-recently-used algorithm. The LRU chain is updated on +each `commit` command. The maximum number of active branches can be +increased or decreased on the command line with \--active-branches=. + +per active tree +~~~~~~~~~~~~~~~ +Trees (aka directories) use just 12 bytes of memory on top of the +memory required for their entries (see ``per active file'' below). +The cost of a tree is virtually 0, as its overhead ammortizes out +over the individual file entries. + +per active file entry +~~~~~~~~~~~~~~~~~~~~~ +Files (and pointers to subtrees) within active trees require 52 or 64 +bytes (32/64 bit platforms) per entry. To conserve space, file and +tree names are pooled in a common string table, allowing the filename +``Makefile'' to use just 16 bytes (after including the string header +overhead) no matter how many times it occurs within the project. + +The active branch LRU, when coupled with the filename string pool +and lazy loading of subtrees, allows fast-import to efficiently import +projects with 2,000+ branches and 45,114+ files in a very limited +memory footprint (less than 2.7 MiB per active branch). + + +Author +------ +Written by Shawn O. Pearce <spearce@spearce.org>. + +Documentation +-------------- +Documentation by Shawn O. Pearce <spearce@spearce.org>. + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 3e6cd880b0..105d76b0ba 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -8,10 +8,13 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS -------- -'git-fetch-pack' [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...] +'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--upload-pack=<git-upload-pack>] [--depth=<n>] [-v] [<host>:]<directory> [<refs>...] DESCRIPTION ----------- +Usually you would want to use gitlink:git-fetch[1] which is a +higher level wrapper of this command instead. + Invokes 'git-upload-pack' on a potentially remote repository, and asks it to send objects missing from this repository, to update the named heads. The list of commits available locally @@ -25,17 +28,24 @@ have a common ancestor commit. OPTIONS ------- --q:: +\--all:: + Fetch all remote refs. + +\--quiet, \-q:: Pass '-q' flag to 'git-unpack-objects'; this makes the cloning process less verbose. --k:: +\--keep, \-k:: Do not invoke 'git-unpack-objects' on received data, but create a single packfile out of it instead, and store it in the object database. If provided twice then the pack is locked against repacking. ---exec=<git-upload-pack>:: +\--thin:: + Spend extra cycles to minimize the number of objects to be sent. + Use it on slower connection. + +\--upload-pack=<git-upload-pack>:: Use this to specify the path to 'git-upload-pack' on the remote side, if is not found on your $PATH. Installations of sshd ignores the user's environment @@ -47,6 +57,15 @@ OPTIONS shells by having a lean .bashrc file (they set most of the things up in .bash_profile). +\--exec=<git-upload-pack>:: + Same as \--upload-pack=<git-upload-pack>. + +\--depth=<n>:: + Limit fetching to ancestor-chains not longer than n. + +\-v:: + Run verbosely. + <host>:: A remote host that houses the repository. When this part is specified, 'git-upload-pack' is invoked via diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index a9e86fd26b..5fbeab76b7 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -3,7 +3,7 @@ git-fetch(1) NAME ---- -git-fetch - Download objects and a head from another repository +git-fetch - Download objects and refs from another repository SYNOPSIS @@ -20,6 +20,14 @@ The ref names and their object names of fetched refs are stored in `.git/FETCH_HEAD`. This information is left for a later merge operation done by "git merge". +When <refspec> stores the fetched result in tracking branches, +the tags that point at these branches are automatically +followed. This is done by first fetching from the remote using +the given <refspec>s, and if the repository has objects that are +pointed by remote tags that it does not yet have, then fetch +those missing tags. If the other end has tags that point at +branches you are not interested in, you will not get them. + OPTIONS ------- diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 2bf6aef735..f49b0d944c 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -7,7 +7,7 @@ git-for-each-ref - Output information on each ref SYNOPSIS -------- -'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python] [--sort=<key>]\* [--format=<format>] [<pattern>] +'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python|--tcl] [--sort=<key>]\* [--format=<format>] [<pattern>] DESCRIPTION ----------- @@ -15,7 +15,7 @@ DESCRIPTION Iterate over all refs that match `<pattern>` and show them according to the given `<format>`, after sorting them according to the given set of `<key>`. If `<max>` is given, stop after -showing that many refs. The interporated values in `<format>` +showing that many refs. The interpolated values in `<format>` can optionally be quoted as string literals in the specified host language allowing their direct evaluation in that language. @@ -49,7 +49,7 @@ OPTIONS using fnmatch(3). Refs that do not match the pattern are not shown. ---shell, --perl, --python:: +--shell, --perl, --python, --tcl:: If given, strings that substitute `%(fieldname)` placeholders are quoted as string literals suitable for the specified host language. This is meant to produce @@ -66,7 +66,7 @@ keys. For all objects, the following names can be used: refname:: - The name of the ref (the part after $GIT_DIR/refs/). + The name of the ref (the part after $GIT_DIR/). objecttype:: The type of the object (`blob`, `tree`, `commit`, `tag`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 67425dc035..59f34b9f0d 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -11,7 +11,8 @@ SYNOPSIS [verse] 'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread] [-s | --signoff] [--diff-options] [--start-number <n>] - [--in-reply-to=Message-Id] + [--in-reply-to=Message-Id] [--suffix=.<sfx>] + [--ignore-if-in-upstream] <since>[..<until>] DESCRIPTION @@ -20,7 +21,9 @@ DESCRIPTION Prepare each commit between <since> and <until> with its patch in one file per commit, formatted to resemble UNIX mailbox format. If ..<until> is not specified, the head of the current working -tree is implied. +tree is implied. For a more complete list of ways to spell +<since> and <until>, see "SPECIFYING REVISIONS" section in +gitlink:git-rev-parse[1]. The output of this command is convenient for e-mail submission or for use with gitlink:git-am[1]. @@ -78,13 +81,34 @@ OPTIONS reply to the given Message-Id, which avoids breaking threads to provide a new patch series. +--ignore-if-in-upstream:: + Do not include a patch that matches a commit in + <until>..<since>. This will examine all patches reachable + from <since> but not from <until> and compare them with the + patches being generated, and any patch that matches is + ignored. + +--suffix=.<sfx>:: + Instead of using `.patch` as the suffix for generated + filenames, use specifed suffix. A common alternative is + `--suffix=.txt`. ++ +Note that you would need to include the leading dot `.` if you +want a filename like `0001-description-of-my-change.patch`, and +the first letter does not have to be a dot. Leaving it empty would +not add any suffix. + CONFIGURATION ------------- You can specify extra mail header lines to be added to each -message in the repository configuration as follows: +message in the repository configuration. Also you can specify +the default suffix different from the built-in one: +------------ [format] headers = "Organization: git-foo\n" + suffix = .txt +------------ EXAMPLES @@ -109,6 +133,9 @@ git-format-patch -M -B origin:: understand renaming patches, so use it only when you know the recipient uses git to apply your patch. +git-format-patch -3:: + Extract three topmost commits from the current branch + and format them as e-mailable patches. See Also -------- diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt index d0af99d351..f21061ecfe 100644 --- a/Documentation/git-fsck-objects.txt +++ b/Documentation/git-fsck-objects.txt @@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the SYNOPSIS -------- -[verse] -'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache] - [--full] [--strict] [<object>*] +'git-fsck-objects' ... DESCRIPTION ----------- -Verifies the connectivity and validity of the objects in the database. - -OPTIONS -------- -<object>:: - An object to treat as the head of an unreachability trace. -+ -If no objects are given, git-fsck-objects defaults to using the -index file and all SHA1 references in .git/refs/* as heads. - ---unreachable:: - Print out objects that exist but that aren't readable from any - of the reference nodes. - ---root:: - Report root nodes. - ---tags:: - Report tags. - ---cache:: - Consider any object recorded in the index also as a head node for - an unreachability trace. - ---full:: - Check not just objects in GIT_OBJECT_DIRECTORY - ($GIT_DIR/objects), but also the ones found in alternate - object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES - or $GIT_DIR/objects/info/alternates, - and in packed git archives found in $GIT_DIR/objects/pack - and corresponding pack subdirectories in alternate - object pools. - ---strict:: - Enable more strict checking, namely to catch a file mode - recorded with g+w bit set, which was created by older - versions of git. Existing repositories, including the - Linux kernel, git itself, and sparse repository have old - objects that triggers this check, but it is recommended - to check new projects with this flag. - -It tests SHA1 and general object sanity, and it does full tracking of -the resulting reachability and everything else. It prints out any -corruption it finds (missing or bad objects), and if you use the -'--unreachable' flag it will also print out objects that exist but -that aren't readable from any of the specified head nodes. - -So for example - - git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*) - -will do quite a _lot_ of verification on the tree. There are a few -extra validity tests to be added (make sure that tree objects are -sorted properly etc), but on the whole if "git-fsck-objects" is happy, you -do have a valid tree. - -Any corrupt objects you will have to find in backups or other archives -(i.e., you can just remove them and do an "rsync" with some other site in -the hopes that somebody else has the object you have corrupted). - -Of course, "valid tree" doesn't mean that it wasn't generated by some -evil person, and the end result might be crap. git is a revision -tracking system, not a quality assurance system ;) - -Extracted Diagnostics ---------------------- - -expect dangling commits - potential heads - due to lack of head information:: - You haven't specified any nodes as heads so it won't be - possible to differentiate between un-parented commits and - root nodes. - -missing sha1 directory '<dir>':: - The directory holding the sha1 objects is missing. - -unreachable <type> <object>:: - The <type> object <object>, isn't actually referred to directly - or indirectly in any of the trees or commits seen. This can - mean that there's another root node that you're not specifying - or that the tree is corrupt. If you haven't missed a root node - then you might as well delete unreachable nodes since they - can't be used. - -missing <type> <object>:: - The <type> object <object>, is referred to but isn't present in - the database. - -dangling <type> <object>:: - The <type> object <object>, is present in the database but never - 'directly' used. A dangling commit could be a root node. - -warning: git-fsck-objects: tree <tree> has full pathnames in it:: - And it shouldn't... - -sha1 mismatch <object>:: - The database has an object who's sha1 doesn't match the - database value. - This indicates a serious data integrity problem. - -Environment Variables ---------------------- - -GIT_OBJECT_DIRECTORY:: - used to specify the object database root (usually $GIT_DIR/objects) - -GIT_INDEX_FILE:: - used to specify the index file of the index - -GIT_ALTERNATE_OBJECT_DIRECTORIES:: - used to specify additional object database roots (usually unset) - -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 gitlink:git[7] suite +This is a synonym for gitlink:git-fsck[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt new file mode 100644 index 0000000000..058009d2fa --- /dev/null +++ b/Documentation/git-fsck.txt @@ -0,0 +1,139 @@ +git-fsck(1) +=========== + +NAME +---- +git-fsck - Verifies the connectivity and validity of the objects in the database + + +SYNOPSIS +-------- +[verse] +'git-fsck' [--tags] [--root] [--unreachable] [--cache] + [--full] [--strict] [<object>*] + +DESCRIPTION +----------- +Verifies the connectivity and validity of the objects in the database. + +OPTIONS +------- +<object>:: + An object to treat as the head of an unreachability trace. ++ +If no objects are given, git-fsck defaults to using the +index file and all SHA1 references in .git/refs/* as heads. + +--unreachable:: + Print out objects that exist but that aren't readable from any + of the reference nodes. + +--root:: + Report root nodes. + +--tags:: + Report tags. + +--cache:: + Consider any object recorded in the index also as a head node for + an unreachability trace. + +--full:: + Check not just objects in GIT_OBJECT_DIRECTORY + ($GIT_DIR/objects), but also the ones found in alternate + object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES + or $GIT_DIR/objects/info/alternates, + and in packed git archives found in $GIT_DIR/objects/pack + and corresponding pack subdirectories in alternate + object pools. + +--strict:: + Enable more strict checking, namely to catch a file mode + recorded with g+w bit set, which was created by older + versions of git. Existing repositories, including the + Linux kernel, git itself, and sparse repository have old + objects that triggers this check, but it is recommended + to check new projects with this flag. + +It tests SHA1 and general object sanity, and it does full tracking of +the resulting reachability and everything else. It prints out any +corruption it finds (missing or bad objects), and if you use the +'--unreachable' flag it will also print out objects that exist but +that aren't readable from any of the specified head nodes. + +So for example + + git-fsck --unreachable HEAD $(cat .git/refs/heads/*) + +will do quite a _lot_ of verification on the tree. There are a few +extra validity tests to be added (make sure that tree objects are +sorted properly etc), but on the whole if "git-fsck" is happy, you +do have a valid tree. + +Any corrupt objects you will have to find in backups or other archives +(i.e., you can just remove them and do an "rsync" with some other site in +the hopes that somebody else has the object you have corrupted). + +Of course, "valid tree" doesn't mean that it wasn't generated by some +evil person, and the end result might be crap. git is a revision +tracking system, not a quality assurance system ;) + +Extracted Diagnostics +--------------------- + +expect dangling commits - potential heads - due to lack of head information:: + You haven't specified any nodes as heads so it won't be + possible to differentiate between un-parented commits and + root nodes. + +missing sha1 directory '<dir>':: + The directory holding the sha1 objects is missing. + +unreachable <type> <object>:: + The <type> object <object>, isn't actually referred to directly + or indirectly in any of the trees or commits seen. This can + mean that there's another root node that you're not specifying + or that the tree is corrupt. If you haven't missed a root node + then you might as well delete unreachable nodes since they + can't be used. + +missing <type> <object>:: + The <type> object <object>, is referred to but isn't present in + the database. + +dangling <type> <object>:: + The <type> object <object>, is present in the database but never + 'directly' used. A dangling commit could be a root node. + +warning: git-fsck: tree <tree> has full pathnames in it:: + And it shouldn't... + +sha1 mismatch <object>:: + The database has an object who's sha1 doesn't match the + database value. + This indicates a serious data integrity problem. + +Environment Variables +--------------------- + +GIT_OBJECT_DIRECTORY:: + used to specify the object database root (usually $GIT_DIR/objects) + +GIT_INDEX_FILE:: + used to specify the index file of the index + +GIT_ALTERNATE_OBJECT_DIRECTORIES:: + used to specify additional object database roots (usually unset) + +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 gitlink:git[7] suite + diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 73d78c15e8..bc1658434a 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- -'git-gc' +'git-gc' [--prune] DESCRIPTION ----------- @@ -21,6 +21,21 @@ Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance. +OPTIONS +------- + +--prune:: + Usually `git-gc` packs refs, expires old reflog entries, + packs loose objects, + and removes old 'rerere' records. Removal + of unreferenced loose objects is an unsafe operation + while other git operations are in progress, so it is not + done by default. Pass this option if you want it, and only + when you know nobody else is creating new objects in the + repository at the same time (e.g. never use this option + in a cron script). + + Configuration ------------- @@ -35,7 +50,7 @@ can be set to indicate how long historical reflog entries which are not part of the current branch should remain available in this repository. These types of entries are generally created as a result of using `git commit \--amend` or `git rebase` and are the -commits prior to the amend or rebase occuring. Since these changes +commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner. This option defaults to '30 days'. @@ -47,6 +62,10 @@ The optional configuration variable 'gc.rerereunresolved' indicates how long records of conflicted merge you have not resolved are kept. This defaults to 15 days. +The optional configuration variable 'gc.packrefs' determines if +`git gc` runs `git-pack-refs`. Without the configuration, `git-pack-refs` +is not run in bare repositories by default, to allow older dumb-transport +clients fetch from the repository, but this will change in the future. See Also -------- diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index bfbece9864..0140c8e358 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -91,7 +91,7 @@ OPTIONS combined by 'or'. --and | --or | --not | ( | ):: - Specify how multiple patterns are combined using boolean + Specify how multiple patterns are combined using Boolean expressions. `--or` is the default operator. `--and` has higher precedence than `--or`. `-e` has to be used for all patterns. diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 04e8d00436..5edc36f060 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -3,7 +3,7 @@ git-hash-object(1) NAME ---- -git-hash-object - Computes object ID and optionally creates a blob from a file +git-hash-object - Compute object ID and optionally creates a blob from a file SYNOPSIS diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt index 3d508094af..7dc2df3044 100644 --- a/Documentation/git-http-fetch.txt +++ b/Documentation/git-http-fetch.txt @@ -3,7 +3,7 @@ git-http-fetch(1) NAME ---- -git-http-fetch - downloads a remote git repository via HTTP +git-http-fetch - Download from a remote git repository via HTTP SYNOPSIS diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt index c2485c6e9c..4b4a46169c 100644 --- a/Documentation/git-http-push.txt +++ b/Documentation/git-http-push.txt @@ -3,7 +3,7 @@ git-http-push(1) NAME ---- -git-http-push - Push missing objects using HTTP/DAV +git-http-push - Push objects over HTTP/DAV to another repository SYNOPSIS diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index bc3ba14939..5412135d76 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -11,96 +11,9 @@ SYNOPSIS 'git-init-db' [--template=<template_directory>] [--shared[=<permissions>]] -OPTIONS -------- - --- - ---template=<template_directory>:: - -Provide the directory from which templates will be used. The default template -directory is `/usr/share/git-core/templates`. - -When specified, `<template_directory>` is used as the source of the template -files rather than the default. The template files include some directory -structure, some suggested "exclude patterns", and copies of non-executing -"hook" files. The suggested patterns and hook files are all modifiable and -extensible. - ---shared[={false|true|umask|group|all|world|everybody}]:: - -Specify that the git repository is to be shared amongst several users. This -allows users belonging to the same group to push into that -repository. When specified, the config variable "core.sharedRepository" is -set so that files and directories under `$GIT_DIR` are created with the -requested permissions. When not specified, git will use permissions reported -by umask(2). - -The option can have the following values, defaulting to 'group' if no value -is given: - - - 'umask' (or 'false'): Use permissions reported by umask(2). The default, - when `--shared` is not specified. - - - 'group' (or 'true'): Make the repository group-writable, (and g+sx, since - the git group may be not the primary group of all users). - - - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository - readable by all users. - -By default, the configuration flag receive.denyNonFastforward is enabled -in shared repositories, so that you cannot force a non fast-forwarding push -into it. - --- - - DESCRIPTION ----------- -This command creates an empty git repository - basically a `.git` directory -with subdirectories for `objects`, `refs/heads`, `refs/tags`, and -template files. -An initial `HEAD` file that references the HEAD of the master branch -is also created. - -If the `$GIT_DIR` environment variable is set then it specifies a path -to use instead of `./.git` for the base of the repository. - -If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY` -environment variable then the sha1 directories are created underneath - -otherwise the default `$GIT_DIR/objects` directory is used. - -Running `git-init-db` in an existing repository is safe. It will not overwrite -things that are already there. The primary reason for rerunning `git-init-db` -is to pick up newly added templates. - -Note that `git-init` is the same as `git-init-db`. - - -EXAMPLES --------- - -Start a new git repository for an existing code base:: -+ ----------------- -$ cd /path/to/my/codebase -$ git-init-db <1> -$ git-add . <2> ----------------- -+ -<1> prepare /path/to/my/codebase/.git directory -<2> add all existing file to the index - - -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 gitlink:git[7] suite +This is a synonym for gitlink:git-init[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt new file mode 100644 index 0000000000..1b64d3ab03 --- /dev/null +++ b/Documentation/git-init.txt @@ -0,0 +1,111 @@ +git-init(1) +=========== + +NAME +---- +git-init - Create an empty git repository or reinitialize an existing one + + +SYNOPSIS +-------- +'git-init' [--template=<template_directory>] [--shared[=<permissions>]] + + +OPTIONS +------- + +-- + +--template=<template_directory>:: + +Provide the directory from which templates will be used. The default template +directory is `/usr/share/git-core/templates`. + +When specified, `<template_directory>` is used as the source of the template +files rather than the default. The template files include some directory +structure, some suggested "exclude patterns", and copies of non-executing +"hook" files. The suggested patterns and hook files are all modifiable and +extensible. + +--shared[={false|true|umask|group|all|world|everybody}]:: + +Specify that the git repository is to be shared amongst several users. This +allows users belonging to the same group to push into that +repository. When specified, the config variable "core.sharedRepository" is +set so that files and directories under `$GIT_DIR` are created with the +requested permissions. When not specified, git will use permissions reported +by umask(2). + +The option can have the following values, defaulting to 'group' if no value +is given: + + - 'umask' (or 'false'): Use permissions reported by umask(2). The default, + when `--shared` is not specified. + + - 'group' (or 'true'): Make the repository group-writable, (and g+sx, since + the git group may be not the primary group of all users). + + - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository + readable by all users. + +By default, the configuration flag receive.denyNonFastforward is enabled +in shared repositories, so that you cannot force a non fast-forwarding push +into it. + +-- + + +DESCRIPTION +----------- +This command creates an empty git repository - basically a `.git` directory +with subdirectories for `objects`, `refs/heads`, `refs/tags`, and +template files. +An initial `HEAD` file that references the HEAD of the master branch +is also created. + +If the `$GIT_DIR` environment variable is set then it specifies a path +to use instead of `./.git` for the base of the repository. + +If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY` +environment variable then the sha1 directories are created underneath - +otherwise the default `$GIT_DIR/objects` directory is used. + +Running `git-init` in an existing repository is safe. It will not overwrite +things that are already there. The primary reason for rerunning `git-init` +is to pick up newly added templates. + +Note that `git-init` is the same as `git-init-db`. The command +was primarily meant to initialize the object database, but over +time it has become responsible for setting up the other aspects +of the repository, such as installing the default hooks and +setting the configuration variables. The old name is retained +for backward compatibility reasons. + + +EXAMPLES +-------- + +Start a new git repository for an existing code base:: ++ +---------------- +$ cd /path/to/my/codebase +$ git-init <1> +$ git-add . <2> +---------------- ++ +<1> prepare /path/to/my/codebase/.git directory +<2> add all existing file to the index + + +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 gitlink:git[7] suite + diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index 7dd393b97f..52a6aa6e82 100644 --- a/Documentation/git-instaweb.txt +++ b/Documentation/git-instaweb.txt @@ -3,7 +3,7 @@ git-instaweb(1) NAME ---- -git-instaweb - instantly browse your working repository in gitweb +git-instaweb - Instantly browse your working repository in gitweb SYNOPSIS -------- diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt index 2fbdfe086a..22048d82bd 100644 --- a/Documentation/git-local-fetch.txt +++ b/Documentation/git-local-fetch.txt @@ -3,7 +3,7 @@ git-local-fetch(1) NAME ---- -git-local-fetch - Duplicates another git repository on a local system +git-local-fetch - Duplicate another git repository on a local system SYNOPSIS diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index e9f746bbd4..361eaec700 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -16,7 +16,7 @@ Shows the commit logs. The command takes options applicable to the gitlink:git-rev-list[1] command to control what is shown and how, and options applicable to -the gitlink:git-diff-tree[1] commands to control how the change +the gitlink:git-diff-tree[1] commands to control how the changes each commit introduces are shown. This manual page describes only the most frequently used options. @@ -27,13 +27,16 @@ OPTIONS include::pretty-formats.txt[] ---max-count=<n>:: +-<n>:: Limits the number of commits to show. <since>..<until>:: Show only commits between the named two commits. When either <since> or <until> is omitted, it defaults to `HEAD`, i.e. the tip of the current branch. + For a more complete list of ways to spell <since> + and <until>, see "SPECIFYING REVISIONS" section in + gitlink:git-rev-parse[1]. -p:: Show the change the commit introduces in a patch form. diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 8520b97111..79e0b7b71a 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -3,7 +3,7 @@ git-ls-files(1) NAME ---- -git-ls-files - Information about files in the index/working directory +git-ls-files - Show information about files in the index and the working tree SYNOPSIS diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index c8a4c5a4d9..c254005ca3 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -29,7 +29,7 @@ OPTIONS -u <exec>, --upload-pack=<exec>:: Specify the full path of gitlink:git-upload-pack[1] on the remote host. This allows listing references from repositories accessed via - SSH and where the SSH deamon does not use the PATH configured by the + SSH and where the SSH daemon does not use the PATH configured by the user. Also see the '--exec' option for gitlink:git-peek-remote[1]. <repository>:: diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt index f283bacb65..7899394081 100644 --- a/Documentation/git-ls-tree.txt +++ b/Documentation/git-ls-tree.txt @@ -3,7 +3,7 @@ git-ls-tree(1) NAME ---- -git-ls-tree - Lists the contents of a tree object +git-ls-tree - List the contents of a tree object SYNOPSIS diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index ea0a06557f..ba18133ead 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -3,7 +3,7 @@ git-mailinfo(1) NAME ---- -git-mailinfo - Extracts patch from a single e-mail message +git-mailinfo - Extracts patch and authorship from a single e-mail message SYNOPSIS @@ -18,7 +18,7 @@ writes the commit log message in <msg> file, and the patches in <patch> file. The author name, e-mail and e-mail subject are written out to the standard output to be used by git-applypatch to create a commit. It is usually not necessary to use this -command directly. +command directly. See gitlink:git-am[1] instead. OPTIONS @@ -33,15 +33,13 @@ OPTIONS format-patch --mbox' output. -u:: - By default, the commit log message, author name and - author email are taken from the e-mail without any - charset conversion, after minimally decoding MIME - transfer encoding. This flag causes the resulting - commit to be encoded in the encoding specified by - i18n.commitencoding configuration (defaults to utf-8) by - transliterating them. - Note that the patch is always used as is without charset - conversion, even with this flag. + The commit log message, author name and author email are + taken from the e-mail, and after minimally decoding MIME + transfer encoding, re-coded in UTF-8 by transliterating + them. 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. --encoding=<encoding>:: Similar to -u but if the local convention is different diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt index 5a17801f6a..c11d6a530f 100644 --- a/Documentation/git-mailsplit.txt +++ b/Documentation/git-mailsplit.txt @@ -3,7 +3,7 @@ git-mailsplit(1) NAME ---- -git-mailsplit - Totally braindamaged mbox splitter program +git-mailsplit - Simple UNIX mbox splitter program SYNOPSIS -------- diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 6099be2add..3190aed108 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -3,7 +3,7 @@ git-merge-base(1) NAME ---- -git-merge-base - Finds as good a common ancestor as possible for a merge +git-merge-base - Find as good common ancestors as possible for a merge SYNOPSIS diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index 29d3faa556..31882abb87 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -3,7 +3,7 @@ git-merge-file(1) NAME ---- -git-merge-file - three-way file merge +git-merge-file - Run a three-way file merge SYNOPSIS diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt index 0cf505ea84..b8ee1ff2b0 100644 --- a/Documentation/git-merge-index.txt +++ b/Documentation/git-merge-index.txt @@ -3,7 +3,7 @@ git-merge-index(1) NAME ---- -git-merge-index - Runs a merge for files needing merging +git-merge-index - Run a merge for files needing merging SYNOPSIS diff --git a/Documentation/git-merge-one-file.txt b/Documentation/git-merge-one-file.txt index 86aad37c6a..f80ab3b8c4 100644 --- a/Documentation/git-merge-one-file.txt +++ b/Documentation/git-merge-one-file.txt @@ -3,7 +3,7 @@ git-merge-one-file(1) NAME ---- -git-merge-one-file - The standard helper program to use with "git-merge-index" +git-merge-one-file - The standard helper program to use with git-merge-index SYNOPSIS diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 0f79665ea6..e53ff4b4e7 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -3,14 +3,14 @@ git-merge(1) NAME ---- -git-merge - Grand Unified Merge Driver +git-merge - Join two or more development histories together SYNOPSIS -------- [verse] 'git-merge' [-n] [--no-commit] [--squash] [-s <strategy>]... - -m=<msg> <remote> <remote>... + [-m <msg>] <remote> <remote>... DESCRIPTION ----------- diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt index 207c43a631..6756b76bb1 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -3,7 +3,7 @@ git-mv(1) NAME ---- -git-mv - Move or rename a file, directory or symlink +git-mv - Move or rename a file, a directory, or a symlink SYNOPSIS diff --git a/Documentation/git-p4import.txt b/Documentation/git-p4import.txt index ee9e8fa909..6edb9f12b8 100644 --- a/Documentation/git-p4import.txt +++ b/Documentation/git-p4import.txt @@ -93,7 +93,7 @@ perforce branch into a branch named "jammy", like so: ------------ $ mkdir -p /home/sean/import/jam $ cd /home/sean/import/jam -$ git init-db +$ git init $ git p4import //public/jam jammy ------------ diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt index 7d54b17e37..94bbea0db2 100644 --- a/Documentation/git-pack-redundant.txt +++ b/Documentation/git-pack-redundant.txt @@ -3,7 +3,7 @@ git-pack-redundant(1) NAME ---- -git-pack-redundant - Program used to find redundant pack files +git-pack-redundant - Find redundant pack files SYNOPSIS @@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the following command useful when wanting to remove packs which contain unreachable objects. -git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \ +git-fsck --full --unreachable | cut -d ' ' -f3 | \ git-pack-redundant --all | xargs rm OPTIONS diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index 464269fbb9..a20fc7de40 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -29,12 +29,23 @@ file and used if found. Subsequent updates to branches always creates new file under `$GIT_DIR/refs` hierarchy. +A recommended practice to deal with a repository with too many +refs is to pack its refs with `--all --prune` once, and +occasionally run `git-pack-refs \--prune`. Tags are by +definition stationary and are not expected to change. Branch +heads will be packed with the initial `pack-refs --all`, but +only the currently active branch heads will become unpacked, +and next `pack-refs` (without `--all`) will leave them +unpacked. + + OPTIONS ------- \--all:: -The command by default packs all tags and leaves branch tips +The command by default packs all tags and refs that are already +packed, and leaves other refs alone. This is because branches are expected to be actively developed and packing their tips does not help performance. This option causes branch tips to be packed as well. Useful for diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt index fc27afe26d..11b1f4d2e2 100644 --- a/Documentation/git-parse-remote.txt +++ b/Documentation/git-parse-remote.txt @@ -3,7 +3,7 @@ git-parse-remote(1) NAME ---- -git-parse-remote - Routines to help parsing $GIT_DIR/remotes/ +git-parse-remote - Routines to help parsing remote repository access parameters SYNOPSIS @@ -14,7 +14,8 @@ DESCRIPTION ----------- This script is included in various scripts to supply routines to parse files under $GIT_DIR/remotes/ and -$GIT_DIR/branches/. +$GIT_DIR/branches/ and configuration variables that are related +to fetching, pulling and pushing. The primary entry points are: @@ -25,7 +26,8 @@ get_remote_refs_for_fetch:: (e.g. `refs/heads/foo`). When `<refspec>...` is empty the returned list of refs consists of the defaults for the given `<repo>`, if specified in - `$GIT_DIR/remotes/` or `$GIT_DIR/branches/`. + `$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch` + configuration. get_remote_refs_for_push:: Given the list of user-supplied `<repo> <refspec>...`, diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt index 5389097f73..a7e9fd021a 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -3,7 +3,7 @@ git-patch-id(1) NAME ---- -git-patch-id - Generate a patch ID +git-patch-id - Compute unique ID for a patch SYNOPSIS -------- diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt index a00060c507..74f37bd904 100644 --- a/Documentation/git-peek-remote.txt +++ b/Documentation/git-peek-remote.txt @@ -3,12 +3,12 @@ git-peek-remote(1) NAME ---- -git-peek-remote - Lists the references in a remote repository +git-peek-remote - List the references in a remote repository SYNOPSIS -------- -'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory> +'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory> DESCRIPTION ----------- @@ -17,7 +17,7 @@ stores them in the local repository under the same name. OPTIONS ------- ---exec=<git-upload-pack>:: +\--upload-pack=<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. Some installations of sshd ignores the user's environment @@ -29,6 +29,9 @@ OPTIONS shells, but prefer having a lean .bashrc file (they set most of the things up in .bash_profile). +\--exec=<git-upload-pack>:: + Same \--upload-pack=<git-upload-pack>. + <host>:: A remote host that houses the repository. When this part is specified, 'git-upload-pack' is invoked via diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index 234882685d..310033e460 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -3,13 +3,12 @@ git-prune-packed(1) NAME ---- -git-prune-packed - Program used to remove the extra object files that are now -residing in a pack file. +git-prune-packed - Remove extra objects that are already in pack files SYNOPSIS -------- -'git-prune-packed' [-n] +'git-prune-packed' [-n] [-q] DESCRIPTION @@ -32,6 +31,9 @@ OPTIONS Don't actually remove any objects, only show those that would have been removed. +-q:: + Squelch the progress indicator. + Author ------ Written by Linus Torvalds <torvalds@osdl.org> diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index a11e303094..0b44f3015d 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -13,7 +13,7 @@ SYNOPSIS DESCRIPTION ----------- -This runs `git-fsck-objects --unreachable` using all the refs +This runs `git-fsck --unreachable` using all the refs available in `$GIT_DIR/refs`, optionally with additional set of objects specified on the command line, and prunes all objects unreachable from any of these head objects from the object database. diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 13be992006..94478ed94d 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -3,7 +3,7 @@ git-pull(1) NAME ---- -git-pull - Pull and merge from another repository or a local branch +git-pull - Fetch from and merge with another repository or a local branch SYNOPSIS @@ -33,6 +33,60 @@ include::urls.txt[] include::merge-strategies.txt[] +DEFAULT BEHAVIOUR +----------------- + +Often people use `git pull` without giving any parameter. +Traditionally, this has been equivalent to saying `git pull +origin`. However, when configuration `branch.<name>.remote` is +present while on branch `<name>`, that value is used instead of +`origin`. + +In order to determine what URL to use to fetch from, the value +of the configuration `remote.<origin>.url` is consulted +and if there is not any such variable, the value on `URL: ` line +in `$GIT_DIR/remotes/<origin>` file is used. + +In order to determine what remote branches to fetch (and +optionally store in the tracking branches) when the command is +run without any refspec parameters on the command line, values +of the configuration variable `remote.<origin>.fetch` are +consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` +file is consulted and its `Pull: ` lines are used. +In addition to the refspec formats described in the OPTIONS +section, you can have a globbing refspec that looks like this: + +------------ +refs/heads/*:refs/remotes/origin/* +------------ + +A globbing refspec must have a non-empty RHS (i.e. must store +what were fetched in tracking branches), and its LHS and RHS +must end with `/*`. The above specifies that all remote +branches are tracked using tracking branches in +`refs/remotes/origin/` hierarchy under the same name. + +The rule to determine which remote branch to merge after +fetching is a bit involved, in order not to break backward +compatibility. + +If explicit refspecs were given on the command +line of `git pull`, they are all merged. + +When no refspec was given on the command line, then `git pull` +uses the refspec from the configuration or +`$GIT_DIR/remotes/<origin>`. In such cases, the following +rules apply: + +. If `branch.<name>.merge` configuration for the current + branch `<name>` exists, that is the name of the branch at the + remote site that is merged. + +. If the refspec is a globbing one, nothing is merged. + +. Otherwise the remote branch of the first refspec is merged. + + EXAMPLES -------- @@ -42,7 +96,7 @@ git pull, git pull origin:: current branch. Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and - branch.<name>.merge options; see gitlink:git-repo-config[1] + branch.<name>.merge options; see gitlink:git-config[1] for details. git pull origin next:: @@ -52,7 +106,8 @@ git pull origin next:: git pull . fixes enhancements:: Bundle local branch `fixes` and `enhancements` on top of - the current branch, making an Octopus merge. + the current branch, making an Octopus merge. This `git pull .` + syntax is equivalent to `git merge`. git pull -s ours . obsolete:: Merge local branch `obsolete` into the current branch, @@ -93,7 +148,7 @@ gitlink:git-reset[1]. SEE ALSO -------- -gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1] +gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1] Author diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 197f4b512f..f8cc2b5432 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- -'git-push' [--all] [--tags] [-f | --force] <repository> <refspec>... +'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...] DESCRIPTION ----------- @@ -67,12 +67,33 @@ the remote repository. addition to refspecs explicitly listed on the command line. +\--receive-pack=<git-receive-pack>:: + Path to the 'git-receive-pack' program on the remote + end. Sometimes useful when pushing to a remote + repository over ssh, and you do not have the program in + a directory on the default $PATH. + +\--exec=<git-receive-pack>:: + Same as \--receive-pack=<git-receive-pack>. + -f, \--force:: Usually, the command refuses to update a remote ref that is not a descendant of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care. +\--repo=<repo>:: + When no repository is specified the command defaults to + "origin"; this overrides it. + +\--thin, \--no-thin:: + These options are passed to `git-send-pack`. Thin + transfer spends extra cycles to minimize the number of + objects to be sent and meant to be used on slower connection. + +-v:: + Run verbosely. + include::urls.txt[] Author diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 03e867a403..f2ef1f7dc0 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -3,11 +3,11 @@ git-rebase(1) NAME ---- -git-rebase - Rebase local commits to a new head +git-rebase - Forward-port local commits to the updated upstream head SYNOPSIS -------- -'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>] +'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>] 'git-rebase' --continue | --skip | --abort @@ -114,6 +114,27 @@ would result in: This is useful when topicB does not depend on topicA. +A range of commits could also be removed with rebase. If we have +the following situation: + +------------ + E---F---G---H---I---J topicA +------------ + +then the command + + git-rebase --onto topicA~5 topicA~2 topicA + +would result in the removal of commits F and G: + +------------ + E---H'---I'---J' topicA +------------ + +This is useful if F and G were flawed in some way, or should not be +part of topicA. Note that the argument to --onto and the <upstream> +parameter can be any valid commit-ish. + In case of conflict, git-rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each @@ -141,10 +162,12 @@ OPTIONS <newbase>:: Starting point at which to create the new commits. If the --onto option is not specified, the starting point is - <upstream>. + <upstream>. May be any valid commit, and not just an + existing branch name. <upstream>:: - Upstream branch to compare against. + Upstream branch to compare against. May be any valid commit, + not just an existing branch name. <branch>:: Working branch; defaults to HEAD. @@ -173,6 +196,12 @@ OPTIONS -v, \--verbose:: Display a diffstat of what changed upstream since the last rebase. +-C<n>:: + Ensure at least <n> lines of surrounding context match before + and after each change. When fewer lines of surrounding + context exist they all must match. By default no context is + ever ignored. + include::merge-strategies.txt[] NOTES diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index 0dfadc2a32..10e8c46c4c 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -3,7 +3,7 @@ git-receive-pack(1) NAME ---- -git-receive-pack - Receive what is pushed into it +git-receive-pack - Receive what is pushed into the repository SYNOPSIS diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 55a24d3266..1e343bcdcd 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -8,13 +8,18 @@ git-reflog - Manage reflog information SYNOPSIS -------- -[verse] -'git-reflog' expire [--dry-run] - [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>... - +'git reflog' <subcommand> <options> DESCRIPTION ----------- +The command takes various subcommands, and different options +depending on the subcommand: + +[verse] +git reflog expire [--dry-run] [--stale-fix] + [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>... + +git reflog [show] [log-options] Reflog is a mechanism to record when the tip of branches are updated. This command is to manage the information recorded in it. @@ -25,6 +30,10 @@ Entries older than `expire` time, or entries older than tip, are removed from the reflog. This is typically not used directly by the end users -- instead, see gitlink:git-gc[1]. +The subcommand "show" (which is also the default, in the absense of any +subcommands) will take all the normal log options, and show the log of +the current branch. It is basically an alias for 'git log -g --abbrev-commit +--pretty=oneline', see gitlink:git-log[1]. OPTIONS diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 5b93a8c8be..a60c31a315 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -12,23 +12,43 @@ SYNOPSIS 'git-remote' 'git-remote' add <name> <url> 'git-remote' show <name> +'git-remote' prune <name> DESCRIPTION ----------- Manage the set of repositories ("remotes") whose branches you track. -With no arguments, shows a list of existing remotes. -In the second form, adds a remote named <name> for the repository at +COMMANDS +-------- + +With no arguments, shows a list of existing remotes. Several +subcommands are available to perform operations on the remotes. + +'add':: + +Adds a remote named <name> for the repository at <url>. The command `git fetch <name>` can then be used to create and update remote-tracking branches <name>/<branch>. -In the third form, gives some information about the remote <name>. +'show':: + +Gives some information about the remote <name>. + +'prune':: + +Deletes all stale tracking branches under <name>. +These stale branches have already been removed from the remote repository +referenced by <name>, but are still locally available in "remotes/<name>". + + +DISCUSSION +---------- The remote configuration is achieved using the `remote.origin.url` and `remote.origin.fetch` configuration variables. (See -gitlink:git-repo-config[1]). +gitlink:git-config[1]). Examples -------- @@ -58,7 +78,7 @@ See Also -------- gitlink:git-fetch[1] gitlink:git-branch[1] -gitlink:git-repo-config[1] +gitlink:git-config[1] Author ------ diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index 0fa47e3b01..d39abc126d 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -3,8 +3,7 @@ git-repack(1) NAME ---- -git-repack - Script used to pack a repository from a collection of -objects into pack files. +git-repack - Pack unpacked objects in a repository SYNOPSIS @@ -31,9 +30,9 @@ OPTIONS Instead of incrementally packing the unpacked objects, pack everything available into a single pack. Especially useful when packing a repository that is used - for a private development and there no need to worry - about people fetching via dumb protocols from it. Use - with '-d'. + for private development and there is no need to worry + about people fetching via dumb file transfer protocols + from it. Use with '-d'. -d:: After packing, if the newly created packs make some diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt index c55a8ba0dc..2deba31763 100644 --- a/Documentation/git-repo-config.txt +++ b/Documentation/git-repo-config.txt @@ -3,225 +3,16 @@ git-repo-config(1) NAME ---- -git-repo-config - Get and set repository or global options. +git-repo-config - Get and set repository or global options SYNOPSIS -------- -[verse] -'git-repo-config' [--global] [type] name [value [value_regex]] -'git-repo-config' [--global] [type] --add name value -'git-repo-config' [--global] [type] --replace-all name [value [value_regex]] -'git-repo-config' [--global] [type] --get name [value_regex] -'git-repo-config' [--global] [type] --get-all name [value_regex] -'git-repo-config' [--global] [type] --unset name [value_regex] -'git-repo-config' [--global] [type] --unset-all name [value_regex] -'git-repo-config' [--global] -l | --list +'git-repo-config' ... -DESCRIPTION ------------ -You can query/set/replace/unset options with this command. The name is -actually the section and the key separated by a dot, and the value will be -escaped. - -Multiple lines can be added to an option by using the '--add' option. -If you want to update or unset an option which can occur on multiple -lines, a POSIX regexp `value_regex` needs to be given. Only the -existing values that match the regexp are updated or unset. If -you want to handle the lines that do *not* match the regex, just -prepend a single exclamation mark in front (see EXAMPLES). - -The type specifier can be either '--int' or '--bool', which will make -'git-repo-config' ensure that the variable(s) are of the given type and -convert the value to the canonical form (simple decimal number for int, -a "true" or "false" string for bool). If no type specifier is passed, -no checks or transformations are performed on the value. - -This command will fail if: - -. The .git/config file is invalid, -. Can not write to .git/config, -. no section was provided, -. the section or key is invalid, -. you try to unset an option which does not exist, -. you try to unset/set an option for which multiple lines match, or -. you use --global option without $HOME being properly set. - - -OPTIONS -------- - ---replace-all:: - Default behavior is to replace at most one line. This replaces - all lines matching the key (and optionally the value_regex). - ---add:: - Adds a new line to the option without altering any existing - values. This is the same as providing '^$' as the value_regex. - ---get:: - Get the value for a given key (optionally filtered by a regex - matching the value). Returns error code 1 if the key was not - found and error code 2 if multiple key values were found. - ---get-all:: - Like get, but does not fail if the number of values for the key - is not exactly one. - ---get-regexp:: - Like --get-all, but interprets the name as a regular expression. - ---global:: - Use global ~/.gitconfig file rather than the repository .git/config. - ---unset:: - Remove the line matching the key from config file. ---unset-all:: - Remove all matching lines from config file. - --l, --list:: - List all variables set in config file. - ---bool:: - git-repo-config will ensure that the output is "true" or "false" - ---int:: - git-repo-config will ensure that the output is a simple - decimal number. An optional value suffix of 'k', 'm', or 'g' - in the config file will cause the value to be multiplied - by 1024, 1048576, or 1073741824 prior to output. - - -ENVIRONMENT +DESCRIPTION ----------- -GIT_CONFIG:: - Take the configuration from the given file instead of .git/config. - Using the "--global" option forces this to ~/.gitconfig. - -GIT_CONFIG_LOCAL:: - Currently the same as $GIT_CONFIG; when Git will support global - configuration files, this will cause it to take the configuration - from the global configuration file in addition to the given file. - - -EXAMPLE -------- - -Given a .git/config like this: - - # - # This is the config file, and - # a '#' or ';' character indicates - # a comment - # - - ; core variables - [core] - ; Don't trust file modes - filemode = false - - ; Our diff algorithm - [diff] - external = "/usr/local/bin/gnu-diff -u" - renames = true - - ; Proxy settings - [core] - gitproxy="ssh" for "ssh://kernel.org/" - gitproxy="proxy-command" for kernel.org - gitproxy="myprotocol-command" for "my://" - gitproxy=default-proxy ; for all the rest - -you can set the filemode to true with - ------------- -% git repo-config core.filemode true ------------- - -The hypothetical proxy command entries actually have a postfix to discern -what URL they apply to. Here is how to change the entry for kernel.org -to "ssh". - ------------- -% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$' ------------- - -This makes sure that only the key/value pair for kernel.org is replaced. - -To delete the entry for renames, do - ------------- -% git repo-config --unset diff.renames ------------- - -If you want to delete an entry for a multivar (like core.gitproxy above), -you have to provide a regex matching the value of exactly one line. - -To query the value for a given key, do - ------------- -% git repo-config --get core.filemode ------------- - -or - ------------- -% git repo-config core.filemode ------------- - -or, to query a multivar: - ------------- -% git repo-config --get core.gitproxy "for kernel.org$" ------------- - -If you want to know all the values for a multivar, do: - ------------- -% git repo-config --get-all core.gitproxy ------------- - -If you like to live dangerous, you can replace *all* core.gitproxy by a -new one with - ------------- -% git repo-config --replace-all core.gitproxy ssh ------------- - -However, if you really only want to replace the line for the default proxy, -i.e. the one without a "for ..." postfix, do something like this: - ------------- -% git repo-config core.gitproxy ssh '! for ' ------------- - -To actually match only values with an exclamation mark, you have to - ------------- -% git repo-config section.key value '[!]' ------------- - -To add a new proxy, without altering any of the existing ones, use - ------------- -% git repo-config core.gitproxy '"proxy" for example.com' ------------- - - -include::config.txt[] - - -Author ------- -Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> - -Documentation --------------- -Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>. - -GIT ---- -Part of the gitlink:git[7] suite - +This is a synonym for gitlink:git-config[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index b57a72bdd7..139b6eb773 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -3,7 +3,7 @@ git-rerere(1) NAME ---- -git-rerere - Reuse recorded resolve +git-rerere - Reuse recorded resolution of conflicted merges SYNOPSIS -------- @@ -38,7 +38,7 @@ its working state. This resets the metadata used by rerere if a merge resolution is to be is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1] -[--skip|--abort] will automatcally invoke this command. +[--skip|--abort] will automatically invoke this command. 'diff':: @@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch: ------------ $ git checkout topic - $ git pull . master + $ git merge master o---*---o---+ topic / / @@ -103,10 +103,10 @@ in which case the final commit graph would look like this: ------------ $ git checkout topic - $ git pull . master + $ git merge master $ ... work on both topic and master branches $ git checkout master - $ git pull . topic + $ git merge topic o---*---o---+---o---o topic / / \ @@ -126,11 +126,11 @@ top of the tip before the test merge: ------------ $ git checkout topic - $ git pull . master + $ git merge master $ git reset --hard HEAD^ ;# rewind the test merge $ ... work on both topic and master branches $ git checkout master - $ git pull . topic + $ git merge topic o---*---o-------o---o topic / \ diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 4f424782eb..04475a9216 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -121,10 +121,6 @@ Undo a merge or pull:: + ------------ $ git pull <1> -Trying really trivial in-index merge... -fatal: Merge requires file-level merging -Nope. -... Auto-merging nitfol CONFLICT (content): Merge conflict in nitfol Automatic merge failed/prevented; fix up by hand diff --git a/Documentation/git-resolve.txt b/Documentation/git-resolve.txt deleted file mode 100644 index 4e57c2b287..0000000000 --- a/Documentation/git-resolve.txt +++ /dev/null @@ -1,36 +0,0 @@ -git-resolve(1) -============== - -NAME ----- -git-resolve - Merge two commits - - -SYNOPSIS --------- -'git-resolve' <current> <merged> <message> - -DESCRIPTION ------------ -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 gitlink:git[7] suite - diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 86c94e7dfd..c742117595 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -27,6 +27,7 @@ SYNOPSIS [ \--pretty | \--header ] [ \--bisect ] [ \--merge ] + [ \--walk-reflogs ] <commit>... [ \-- <paths>... ] DESCRIPTION @@ -190,6 +191,22 @@ limiting may be applied. In addition to the '<commit>' listed on the command line, read them from the standard input. +-g, --walk-reflogs:: + + Instead of walking the commit ancestry chain, walk + reflog entries from the most recent one to older ones. + When this option is used you cannot specify commits to + exclude (that is, '{caret}commit', 'commit1..commit2', + nor 'commit1...commit2' notations cannot be used). ++ +With '\--pretty' format other than oneline (for obvious reasons), +this causes the output to have two extra lines of information +taken from the reflog. By default, 'commit@{Nth}' notation is +used in the output. When the starting commit is specified as +'commit@{now}', output also uses 'commit@{timestamp}' notation +instead. Under '\--pretty=oneline', the commit message is +prefixed with this information on the same line. + --merge:: After a failed merge, show refs that touch files having a diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 4eaf5a0d1e..4041a16070 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -152,6 +152,18 @@ blobs contained in a commit. used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/<ref>). +* A ref followed by the suffix '@' with an ordinal specification + enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify + the n-th prior value of that ref. For example 'master@\{1\}' + is the immediate prior value of 'master' while 'master@\{5\}' + is the 5th prior value of 'master'. This suffix may only be used + immediately following a ref name and the ref must have an existing + log ($GIT_DIR/logs/<ref>). + +* You can use the '@' construct with an empty ref part to get at a + reflog of the current branch. For example, if you are on the + branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'. + * A suffix '{caret}' to a revision parameter means the first parent of that commit object. '{caret}<n>' means the <n>th parent (i.e. 'rev{caret}' diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 71f7815d65..8081bbaffa 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -19,6 +19,8 @@ OPTIONS ------- <commit>:: Commit to revert. + For a more complete list of ways to spell commit names, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. -e|--edit:: With this option, `git-revert` will let you edit the commit diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 3a8f279e1a..6feebc0400 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file. EXAMPLES -------- git-rm Documentation/\\*.txt:: - Removes all `\*.txt` files from the index that are under the - `Documentation` directory and any of its subdirectories. The - files are not removed from the working tree. + `Documentation` directory and any of its subdirectories. + Note that the asterisk `\*` is quoted from the shell in this example; this lets the command include the files from subdirectories of `Documentation/` directory. git-rm -f git-*.sh:: - - Remove all git-*.sh scripts that are in the index. The files - are removed from the index, and from the working - tree. Because this example lets the shell expand the - asterisk (i.e. you are listing the files explicitly), it + Remove all git-*.sh scripts that are in the index. + Because this example lets the shell expand the asterisk + (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. See Also diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index 5376f68548..205bfd2d25 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -3,38 +3,51 @@ git-send-pack(1) NAME ---- -git-send-pack - Push missing objects packed +git-send-pack - Push objects over git protocol to another repository SYNOPSIS -------- -'git-send-pack' [--all] [--force] [--exec=<git-receive-pack>] [<host>:]<directory> [<ref>...] +'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...] DESCRIPTION ----------- +Usually you would want to use gitlink:git-push[1] which is a +higher level wrapper of this command instead. + Invokes 'git-receive-pack' on a possibly remote repository, and updates it from the current repository, sending named refs. OPTIONS ------- ---exec=<git-receive-pack>:: +\--receive-pack=<git-receive-pack>:: Path to the 'git-receive-pack' program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH. ---all:: +\--exec=<git-receive-pack>:: + Same as \--receive-pack=<git-receive-pack>. + +\--all:: Instead of explicitly specifying which refs to update, update all refs that locally exist. ---force:: +\--force:: Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. What this means is that the remote repository can lose commits; use it with care. +\--verbose:: + Run verbosely. + +\--thin:: + Spend extra cycles to minimize the number of objects to be sent. + Use it on slower connection. + <host>:: A remote host to house the repository. When this part is specified, 'git-receive-pack' is invoked via diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt index 79217d8a56..2b2abebd60 100644 --- a/Documentation/git-sh-setup.txt +++ b/Documentation/git-sh-setup.txt @@ -12,14 +12,51 @@ SYNOPSIS DESCRIPTION ----------- -Sets up the normal git environment variables and a few helper functions -(currently just "die()"), and returns OK if it all looks like a git archive. -So, to make the rest of the git scripts more careful and readable, -use it as follows: - -------------------------------------------------- -. git-sh-setup || die "Not a git archive" -------------------------------------------------- +This is not a command the end user would want to run. Ever. +This documentation is meant for people who are studying the +Porcelain-ish scripts and/or are writing new ones. + +The `git-sh-setup` scriptlet is designed to be sourced (using +`.`) by other shell scripts to set up some variables pointing at +the normal git directories and a few helper shell functions. + +Before sourcing it, your script should set up a few variables; +`USAGE` (and `LONG_USAGE`, if any) is used to define message +given by `usage()` shell function. `SUBDIRECTORY_OK` can be set +if the script can run from a subdirectory of the working tree +(some commands do not). + +The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell +variables, but does *not* export them to the environment. + +FUNCTIONS +--------- + +die:: + exit after emitting the supplied error message to the + standard error stream. + +usage:: + die with the usage message. + +set_reflog_action:: + set the message that will be recorded to describe the + end-user action in the reflog, when the script updates a + ref. + +is_bare_repository:: + outputs `true` or `false` to the standard output stream + to indicate if the repository is a bare repository + (i.e. without an associated working tree). + +cd_to_toplevel:: + runs chdir to the toplevel of the working tree. + +require_work_tree:: + checks if the repository is a bare repository, and dies + if so. Used by scripts that require working tree + (e.g. `checkout`). + Author ------ diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt index cc4266d83b..228b9f14f3 100644 --- a/Documentation/git-shell.txt +++ b/Documentation/git-shell.txt @@ -3,7 +3,7 @@ git-shell(1) NAME ---- -git-shell - Restricted login shell for GIT over SSH only +git-shell - Restricted login shell for GIT-only SSH access SYNOPSIS diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 95fa9010c1..b0df92e819 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -29,7 +29,7 @@ OPTIONS of author alphabetic order. -s:: - Supress commit description and provide a commit count summary only. + Suppress commit description and provide a commit count summary only. FILES ----- diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index 912e15bcba..ba5313d51f 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -11,7 +11,7 @@ SYNOPSIS 'git-show-branch' [--all] [--remotes] [--topo-order] [--current] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] [--topics] [<rev> | <glob>]... -'git-show-branch' --reflog[=<n>] <ref> +'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>] DESCRIPTION ----------- @@ -97,9 +97,13 @@ OPTIONS will show the revisions given by "git rev-list {caret}master topic1 topic2" ---reflog[=<n>] <ref>:: - Shows <n> most recent ref-log entries for the given ref. - +--reflog[=<n>[,<base>]] [<ref>]:: + Shows <n> most recent ref-log entries for the given + ref. If <base> is given, <n> entries going back from + that entry. <base> can be specified as count or date. + `-g` can be used as a short-hand for this option. When + no explicit <ref> parameter is given, it defaults to the + current branch (or `HEAD` if it is detached). Note that --more, --list, --independent and --merge-base options are mutually exclusive. @@ -165,6 +169,13 @@ With this, `git show-branch` without extra parameters would show only the primary branches. In addition, if you happen to be on your topic branch, it is shown as well. +------------ +$ git show-branch --reflog='10,1 hour ago' --list master +------------ + +shows 10 reflog entries going back from the tip as of 1 hour ago. +Without `--list`, the output also shows how these tips are +topologically related with each other. Author diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index c210b9af6b..f56f164983 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -25,6 +25,9 @@ with \--name-only). For plain blobs, it shows the plain contents. +The command takes options applicable to the gitlink:git-diff-tree[1] command to +control how the changes the commit introduces are shown. + This manual page describes only the most frequently used options. @@ -32,6 +35,8 @@ OPTIONS ------- <object>:: The name of the object to show. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. include::pretty-formats.txt[] diff --git a/Documentation/git-ssh-fetch.txt b/Documentation/git-ssh-fetch.txt index b7116b30e0..192b1f15a9 100644 --- a/Documentation/git-ssh-fetch.txt +++ b/Documentation/git-ssh-fetch.txt @@ -3,7 +3,7 @@ git-ssh-fetch(1) NAME ---- -git-ssh-fetch - Pulls from a remote repository over ssh connection +git-ssh-fetch - Fetch from a remote repository over ssh connection diff --git a/Documentation/git-ssh-upload.txt b/Documentation/git-ssh-upload.txt index 702674e45d..a9b7e9f974 100644 --- a/Documentation/git-ssh-upload.txt +++ b/Documentation/git-ssh-upload.txt @@ -3,7 +3,7 @@ git-ssh-upload(1) NAME ---- -git-ssh-upload - Pushes to a remote repository over ssh connection +git-ssh-upload - Push to a remote repository over ssh connection SYNOPSIS diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index ce7857e5a9..03871e5d73 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -3,7 +3,7 @@ git-status(1) NAME ---- -git-status - Show working tree status +git-status - Show the working tree status SYNOPSIS @@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit template comments, and all the output lines are prefixed with '#'. +CONFIGURATION +------------- + +The command honors `color.status` (or `status.color` -- they +mean the same thing and the latter is kept for backward +compatibility) and `color.status.<slot>` configuration variables +to colorize its output. + + Author ------ Written by Linus Torvalds <torvalds@osdl.org> and diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 1b013139af..6ce6a3944d 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -3,7 +3,7 @@ git-svn(1) NAME ---- -git-svn - bidirectional operation between Subversion and git +git-svn - Bidirectional operation between a single Subversion branch and git SYNOPSIS -------- @@ -113,7 +113,7 @@ manually joining branches on commit. 'commit-diff':: Commits the diff of two tree-ish arguments from the - command-line. This command is intended for interopability with + command-line. This command is intended for interoperability with git-svnimport and does not rely on being inside an git-svn init-ed repository. This command takes three arguments, (a) the original tree to diff against, (b) the new tree result, (c) the @@ -133,7 +133,7 @@ manually joining branches on commit. 'multi-init':: This command supports git-svnimport-like command-line syntax for - importing repositories that are layed out as recommended by the + importing repositories that are laid out as recommended by the SVN folks. This is a bit more tolerant than the git-svnimport command-line syntax and doesn't require the user to figure out where the repository URL ends and where the repository path @@ -171,7 +171,7 @@ OPTIONS --shared:: --template=<template_directory>:: Only used with the 'init' command. - These are passed directly to gitlink:git-init-db[1]. + These are passed directly to gitlink:git-init[1]. -r <ARG>:: --revision <ARG>:: @@ -204,7 +204,7 @@ removed by default if there are no files left in them. git cannot version empty directories. Enabling this flag will make the commit to SVN act like git. -repo-config key: svn.rmdir +config key: svn.rmdir -e:: --edit:: @@ -215,7 +215,7 @@ Edit the commit message before committing to SVN. This is off by default for objects that are commits, and forced on when committing tree objects. -repo-config key: svn.edit +config key: svn.edit -l<num>:: --find-copies-harder:: @@ -226,8 +226,8 @@ They are both passed directly to git-diff-tree see gitlink:git-diff-tree[1] for more information. [verse] -repo-config key: svn.l -repo-config key: svn.findcopiesharder +config key: svn.l +config key: svn.findcopiesharder -A<filename>:: --authors-file=<filename>:: @@ -245,7 +245,7 @@ will abort operation. The user will then have to add the appropriate entry. Re-running the previous git-svn command after the authors-file is modified should continue operation. -repo-config key: svn.authorsfile +config key: svn.authorsfile -q:: --quiet:: @@ -262,8 +262,8 @@ repo-config key: svn.authorsfile --repack-flags are passed directly to gitlink:git-repack[1]. -repo-config key: svn.repack -repo-config key: svn.repackflags +config key: svn.repack +config key: svn.repackflags -m:: --merge:: @@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_. This option may be specified multiple times, once for each branch. -repo-config key: svn.branch +config key: svn.branch -i<GIT_SVN_ID>:: --id <GIT_SVN_ID>:: @@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID. started tracking a branch and never tracked the trunk it was descended from. -repo-config key: svn.followparent +config key: svn.followparent --no-metadata:: This gets rid of the git-svn-id: lines at the end of every commit. @@ -332,7 +332,7 @@ repo-config key: svn.followparent The 'git-svn log' command will not work on repositories using this, either. -repo-config key: svn.nometadata +config key: svn.nometadata -- @@ -367,7 +367,7 @@ Basic Examples Tracking and contributing to a the trunk of a Subversion-managed project: ------------------------------------------------------------------------ -# Initialize a repo (like git init-db): +# Initialize a repo (like git init): git-svn init http://svn.foo.org/project/trunk # Fetch remote revisions: git-svn fetch @@ -388,7 +388,7 @@ See also: '<<tracking-multiple-repos,Tracking Multiple Repositories or Branches>>' ------------------------------------------------------------------------ -# Initialize a repo (like git init-db): +# Initialize a repo (like git init): git-svn multi-init http://svn.foo.org/project \ -T trunk -b branches -t tags # Fetch remote revisions: diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt index 4bc35a1d4b..a88f722860 100644 --- a/Documentation/git-symbolic-ref.txt +++ b/Documentation/git-symbolic-ref.txt @@ -3,11 +3,11 @@ git-symbolic-ref(1) NAME ---- -git-symbolic-ref - read and modify symbolic refs +git-symbolic-ref - Read and modify symbolic refs SYNOPSIS -------- -'git-symbolic-ref' <name> [<ref>] +'git-symbolic-ref' [-q] [-m <reason>] <name> [<ref>] DESCRIPTION ----------- @@ -23,6 +23,18 @@ A symbolic ref is a regular file that stores a string that begins with `ref: refs/`. For example, your `.git/HEAD` is a regular file whose contents is `ref: refs/heads/master`. +OPTIONS +------- + +-q:: + Do not issue an error message if the <name> is not a + symbolic ref but a detached HEAD; instead exit with + non-zero status silently. + +-m:: + Update the reflog for <name> with <reason>. This is valid only + when creating or updating a symbolic ref. + NOTES ----- In the past, `.git/HEAD` was a symbolic link pointing at @@ -36,6 +48,10 @@ cumbersome. On some platforms, `ln -sf` does not even work as advertised (horrors). Therefore symbolic links are now deprecated and symbolic refs are used by default. +git-symbolic-ref will exit with status 0 if the contents of the +symbolic ref were printed correctly, with status 1 if the requested +name is not a symbolic ref, or 128 if another error occurs. + Author ------ Written by Junio C Hamano <junkio@cox.net> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 80bece0775..70235e8ddb 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -3,14 +3,14 @@ git-tag(1) NAME ---- -git-tag - Create a tag object signed with GPG +git-tag - Create, list, delete or verify a tag object signed with GPG SYNOPSIS -------- [verse] -'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>] - <name> [<head>] +'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>] <name> [<head>] +'git-tag' -d <name>... 'git-tag' -l [<pattern>] DESCRIPTION @@ -55,7 +55,7 @@ OPTIONS Replace an existing tag with the given name (instead of failing) -d:: - Delete an existing tag with the given name + Delete existing tags with the given names. -v:: Verify the gpg signature of given the tag @@ -70,6 +70,147 @@ OPTIONS Take the tag message from the given file. Use '-' to read the message from the standard input. +CONFIGURATION +------------- +By default, git-tag in sign-with-default mode (-s) will use your +committer identity (of the form "Your Name <your@email.address>") to +find a key. If you want to use a different default key, you can specify +it in the repository configuration as follows: + +[user] + signingkey = <gpg-key-id> + + +DISCUSSION +---------- + +On Re-tagging +~~~~~~~~~~~~~ + +What should you do when you tag a wrong commit and you would +want to re-tag? + +If you never pushed anything out, just re-tag it. Use "-f" to +replace the old one. And you're done. + +But if you have pushed things out (or others could just read +your repository directly), then others will have already seen +the old tag. In that case you can do one of two things: + +. The sane thing. +Just admit you screwed up, and use a different name. Others have +already seen one tag-name, and if you keep the same name, you +may be in the situation that two people both have "version X", +but they actually have 'different' "X"'s. So just call it "X.1" +and be done with it. + +. The insane thing. +You really want to call the new version "X" too, 'even though' +others have already seen the old one. So just use "git tag -f" +again, as if you hadn't already published the old one. + +However, Git does *not* (and it should not)change tags behind +users back. So if somebody already got the old tag, doing a "git +pull" on your tree shouldn't just make them overwrite the old +one. + +If somebody got a release tag from you, you cannot just change +the tag for them by updating your own one. This is a big +security issue, in that people MUST be able to trust their +tag-names. If you really want to do the insane thing, you need +to just fess up to it, and tell people that you messed up. You +can do that by making a very public announcement saying: + +------------ +Ok, I messed up, and I pushed out an earlier version tagged as X. I +then fixed something, and retagged the *fixed* tree as X again. + +If you got the wrong tag, and want the new one, please delete +the old one and fetch the new one by doing: + + git tag -d X + git fetch origin tag X + +to get my updated tag. + +You can test which tag you have by doing + + git rev-parse X + +which should return 0123456789abcdef.. if you have the new version. + +Sorry for inconvenience. +------------ + +Does this seem a bit complicated? It *should* be. There is no +way that it would be correct to just "fix" it behind peoples +backs. People need to know that their tags might have been +changed. + + +On Automatic following +~~~~~~~~~~~~~~~~~~~~~~ + +If you are following somebody else's tree, you are most likely +using tracking branches (`refs/heads/origin` in traditional +layout, or `refs/remotes/origin/master` in the separate-remote +layout). You usually want the tags from the other end. + +On the other hand, if you are fetching because you would want a +one-shot merge from somebody else, you typically do not want to +get tags from there. This happens more often for people near +the toplevel but not limited to them. Mere mortals when pulling +from each other do not necessarily want to automatically get +private anchor point tags from the other person. + +You would notice "please pull" messages on the mailing list says +repo URL and branch name alone. This is designed to be easily +cut&pasted to "git fetch" command line: + +------------ +Linus, please pull from + + git://git..../proj.git master + +to get the following updates... +------------ + +becomes: + +------------ +$ git pull git://git..../proj.git master +------------ + +In such a case, you do not want to automatically follow other's +tags. + +One important aspect of git is it is distributed, and being +distributed largely means there is no inherent "upstream" or +"downstream" in the system. On the face of it, the above +example might seem to indicate that the tag namespace is owned +by upper echelon of people and tags only flow downwards, but +that is not the case. It only shows that the usage pattern +determines who are interested in whose tags. + +A one-shot pull is a sign that a commit history is now crossing +the boundary between one circle of people (e.g. "people who are +primarily interested in networking part of the kernel") who may +have their own set of tags (e.g. "this is the third release +candidate from the networking group to be proposed for general +consumption with 2.6.21 release") to another circle of people +(e.g. "people who integrate various subsystem improvements"). +The latter are usually not interested in the detailed tags used +internally in the former group (that is what "internal" means). +That is why it is desirable not to follow tags automatically in +this case. + +It may well be that among networking people, they may want to +exchange the tags internal to their group, but in that workflow +they are most likely tracking with each other's progress by +having tracking branches. Again, the heuristic to automatically +follow such tags is a good thing. + + Author ------ Written by Linus Torvalds <torvalds@osdl.org>, diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt index 74a6fddd9a..595940524e 100644 --- a/Documentation/git-tar-tree.txt +++ b/Documentation/git-tar-tree.txt @@ -3,7 +3,7 @@ git-tar-tree(1) NAME ---- -git-tar-tree - Creates a tar archive of the files in the named tree +git-tar-tree - Create a tar archive of the files in the named tree object SYNOPSIS @@ -50,7 +50,7 @@ repository configuration as follows : umask = 002 ;# group friendly The special umask value "user" indicates that the user's current umask -will be used instead. The default value remains 0, which means world +will be used instead. The default value is 002, which means group readable/writable files and directories. EXAMPLES diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 0914cbb0ba..10653ff898 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -50,7 +50,7 @@ History Viewers gitview is a GTK based repository browser for git - - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/) + - *gitweb* (shipped with git-core) GITweb provides full-fledged web interface for GIT repositories. @@ -63,12 +63,18 @@ History Viewers Currently it is the fastest and most feature rich among the git viewers and commit tools. + - *tig* (http://jonas.nitro.dk/tig/) + + tig by Jonas Fonseca is a simple git repository browser + written using ncurses. Basically, it just acts as a front-end + for git-log and git-show/git-diff. Additionally, you can also + use it as a pager for git commands. Foreign SCM interface --------------------- - - *git-svn* (contrib/) + - *git-svn* (shipped with git-core) git-svn is a simple conduit for changesets between a single Subversion branch and git. @@ -80,6 +86,14 @@ Foreign SCM interface series in git back and forth. + - *hg-to-git* (contrib/) + + hg-to-git converts a Mercurial repository into a git one, and + preserves the full branch history in the process. hg-to-git can + also be used in an incremental way to keep the git repository + in sync with the master Mercurial repository. + + Others ------ @@ -95,3 +109,7 @@ Others This is an Emacs interface for git. The user interface is modeled on pcl-cvs. It has been developed on Emacs 21 and will probably need some tweaking to work on XEmacs. + + +http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more +comprehensive list. diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 0e0a3af1be..b161c8b32b 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -3,7 +3,7 @@ git-update-index(1) NAME ---- -git-update-index - Modifies the index or directory cache +git-update-index - Register file contents in the working tree to the index SYNOPSIS @@ -289,7 +289,7 @@ Configuration The command honors `core.filemode` configuration variable. If your repository is on an filesystem whose executable bits are -unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]). +unreliable, this should be set to 'false' (see gitlink:git-config[1]). This causes the command to ignore differences in file modes recorded in the index and the file mode on the filesystem if they differ only on executable bit. On such an unfortunate filesystem, you may @@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See See Also -------- -gitlink:git-repo-config[1] +gitlink:git-config[1] Author diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index 71bcb7954f..9424feab32 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -3,7 +3,7 @@ git-update-ref(1) NAME ---- -git-update-ref - update the object name stored in a ref safely +git-update-ref - Update the object name stored in a ref safely SYNOPSIS -------- diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt index 388bb53d29..403871d7c6 100644 --- a/Documentation/git-upload-archive.txt +++ b/Documentation/git-upload-archive.txt @@ -3,7 +3,7 @@ git-upload-archive(1) NAME ---- -git-upload-archive - Send archive +git-upload-archive - Send archive back to git-archive SYNOPSIS diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index b2c9307661..9da062d5c9 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -3,7 +3,7 @@ git-upload-pack(1) NAME ---- -git-upload-pack - Send missing objects packed +git-upload-pack - Send objects packed back to git-fetch-pack SYNOPSIS diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index a5b1a0dbab..9b0de1c111 100644 --- a/Documentation/git-var.txt +++ b/Documentation/git-var.txt @@ -3,7 +3,7 @@ git-var(1) NAME ---- -git-var - Print the git users identity +git-var - Show a git logical variable SYNOPSIS @@ -20,7 +20,7 @@ OPTIONS Cause the logical variables to be listed. In addition, all the variables of the git configuration file .git/config are listed as well. (However, the configuration variables listing functionality - is deprecated in favor of `git-repo-config -l`.) + is deprecated in favor of `git-config -l`.) EXAMPLE -------- @@ -49,7 +49,7 @@ See Also -------- gitlink:git-commit-tree[1] gitlink:git-tag[1] -gitlink:git-repo-config[1] +gitlink:git-config[1] Author ------ diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index e8f21d02f7..399bff3bbc 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -27,7 +27,7 @@ OPTIONS output format that is useful only to tell the changed paths and their nature of changes. ---max-count=<n>:: +-<n>:: Limit output to <n> commits. <since>..<until>:: diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt index c85fa89c30..96d5e07b11 100644 --- a/Documentation/git-write-tree.txt +++ b/Documentation/git-write-tree.txt @@ -3,7 +3,7 @@ git-write-tree(1) NAME ---- -git-write-tree - Creates a tree object from the current index +git-write-tree - Create a tree object from the current index SYNOPSIS diff --git a/Documentation/git.txt b/Documentation/git.txt index 5662cdc27c..3d8be5931c 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,9 +22,34 @@ See this link:tutorial.html[tutorial] to get started, then see link:everyday.html[Everyday Git] for a useful minimum set of commands, and "man git-commandname" for documentation of each command. CVS users may also want to read link:cvs-migration.html[CVS migration]. +link:user-manual.html[Git User's Manual] is still work in +progress, but when finished hopefully it will guide a new user +in a coherent way to git enlightenment ;-). The COMMAND is either a name of a Git command (see below) or an alias -as defined in the configuration file (see gitlink:git-repo-config[1]). +as defined in the configuration file (see gitlink:git-config[1]). + +ifdef::stalenotes[] +[NOTE] +============ +You are reading the documentation for the latest version of git. +Documentation for older releases are available here: + +* link:v1.5.0/git.html[documentation for release 1.5.0] + +* link:v1.5.0/RelNotes-1.5.0.txt[release notes for 1.5.0] + +* link:v1.4.4.4/git.html[documentation for release 1.4.4.4] + +* link:v1.3.3/git.html[documentation for release 1.3.3] + +* link:v1.2.6/git.html[documentation for release 1.2.6] + +* link:v1.0.13/git.html[documentation for release 1.0.13] + +============ + +endif::stalenotes[] OPTIONS ------- @@ -81,244 +106,26 @@ ancillary user utilities. Main porcelain commands ~~~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-add[1]:: - Add paths to the index. - -gitlink:git-am[1]:: - Apply patches from a mailbox, but cooler. - -gitlink:git-applymbox[1]:: - Apply patches from a mailbox, original version by Linus. - -gitlink:git-archive[1]:: - Creates an archive of files from a named tree. - -gitlink:git-bisect[1]:: - Find the change that introduced a bug by binary search. - -gitlink:git-branch[1]:: - Create and Show branches. - -gitlink:git-checkout[1]:: - Checkout and switch to a branch. - -gitlink:git-cherry-pick[1]:: - Cherry-pick the effect of an existing commit. - -gitlink:git-clean[1]:: - Remove untracked files from the working tree. - -gitlink:git-clone[1]:: - Clones a repository into a new directory. - -gitlink:git-commit[1]:: - Record changes to the repository. - -gitlink:git-diff[1]:: - Show changes between commits, commit and working tree, etc. - -gitlink:git-fetch[1]:: - Download from a remote repository via various protocols. - -gitlink:git-format-patch[1]:: - Prepare patches for e-mail submission. - -gitlink:git-grep[1]:: - Print lines matching a pattern. - -gitlink:gitk[1]:: - The git repository browser. - -gitlink:git-log[1]:: - Shows commit logs. - -gitlink:git-ls-remote[1]:: - Shows references in a remote or local repository. - -gitlink:git-merge[1]:: - Grand unified merge driver. - -gitlink:git-mv[1]:: - Move or rename a file, a directory, or a symlink. - -gitlink:git-pack-refs[1]:: - Pack heads and tags for efficient repository access. - -gitlink:git-pull[1]:: - Fetch from and merge with a remote repository or a local branch. - -gitlink:git-push[1]:: - Update remote refs along with associated objects. - -gitlink:git-rebase[1]:: - Rebase local commits to the updated upstream head. - -gitlink:git-repack[1]:: - Pack unpacked objects in a repository. - -gitlink:git-rerere[1]:: - Reuse recorded resolution of conflicted merges. - -gitlink:git-reset[1]:: - Reset current HEAD to the specified state. - -gitlink:git-resolve[1]:: - Merge two commits. - -gitlink:git-revert[1]:: - Revert an existing commit. - -gitlink:git-rm[1]:: - Remove files from the working tree and from the index. - -gitlink:git-shortlog[1]:: - Summarizes 'git log' output. - -gitlink:git-show[1]:: - Show one commit log and its diff. - -gitlink:git-show-branch[1]:: - Show branches and their commits. - -gitlink:git-status[1]:: - Shows the working tree status. - -gitlink:git-verify-tag[1]:: - Check the GPG signature of tag. - -gitlink:git-whatchanged[1]:: - Shows commit logs and differences they introduce. - +include::cmds-mainporcelain.txt[] Ancillary Commands ~~~~~~~~~~~~~~~~~~ Manipulators: -gitlink:git-applypatch[1]:: - Apply one patch extracted from an e-mail. - -gitlink:git-archimport[1]:: - Import an arch repository into git. - -gitlink:git-convert-objects[1]:: - Converts old-style git repository. - -gitlink:git-cvsimport[1]:: - Salvage your data out of another SCM people love to hate. - -gitlink:git-cvsexportcommit[1]:: - Export a single commit to a CVS checkout. - -gitlink:git-cvsserver[1]:: - A CVS server emulator for git. - -gitlink:git-gc[1]:: - Cleanup unnecessary files and optimize the local repository. - -gitlink:git-lost-found[1]:: - Recover lost refs that luckily have not yet been pruned. - -gitlink:git-merge-one-file[1]:: - The standard helper program to use with `git-merge-index`. - -gitlink:git-prune[1]:: - Prunes all unreachable objects from the object database. - -gitlink:git-quiltimport[1]:: - Applies a quilt patchset onto the current branch. - -gitlink:git-reflog[1]:: - Manage reflog information. - -gitlink:git-relink[1]:: - Hardlink common objects in local repositories. - -gitlink:git-svn[1]:: - Bidirectional operation between a single Subversion branch and git. - -gitlink:git-svnimport[1]:: - Import a SVN repository into git. - -gitlink:git-sh-setup[1]:: - Common git shell script setup code. - -gitlink:git-symbolic-ref[1]:: - Read and modify symbolic refs. - -gitlink:git-tag[1]:: - An example script to create a tag object signed with GPG. - -gitlink:git-update-ref[1]:: - Update the object name stored in a ref safely. - +include::cmds-ancillarymanipulators.txt[] Interrogators: -gitlink:git-annotate[1]:: - Annotate file lines with commit info. - -gitlink:git-blame[1]:: - Find out where each line in a file came from. - -gitlink:git-check-ref-format[1]:: - Make sure ref name is well formed. - -gitlink:git-cherry[1]:: - Find commits not merged upstream. - -gitlink:git-count-objects[1]:: - Count unpacked number of objects and their disk consumption. - -gitlink:git-daemon[1]:: - A really simple server for git repositories. - -gitlink:git-fmt-merge-msg[1]:: - Produce a merge commit message. - -gitlink:git-get-tar-commit-id[1]:: - Extract commit ID from an archive created using git-tar-tree. - -gitlink:git-imap-send[1]:: - Dump a mailbox from stdin into an imap folder. - -gitlink:git-instaweb[1]:: - Instantly browse your working repository in gitweb. - -gitlink:git-mailinfo[1]:: - Extracts patch and authorship information from a single - e-mail message, optionally transliterating the commit - message into utf-8. - -gitlink:git-mailsplit[1]:: - A stupid program to split UNIX mbox format mailbox into - individual pieces of e-mail. - -gitlink:git-merge-tree[1]:: - Show three-way merge without touching index. - -gitlink:git-patch-id[1]:: - Compute unique ID for a patch. - -gitlink:git-parse-remote[1]:: - Routines to help parsing `$GIT_DIR/remotes/` files. +include::cmds-ancillaryinterrogators.txt[] -gitlink:git-request-pull[1]:: - git-request-pull. -gitlink:git-rev-parse[1]:: - Pick out and massage parameters. - -gitlink:git-runstatus[1]:: - A helper for git-status and git-commit. - -gitlink:git-send-email[1]:: - Send patch e-mails out of "format-patch --mbox" output. +Interacting with Others +~~~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-symbolic-ref[1]:: - Read and modify symbolic refs. +These commands are to interact with foreign SCM and with other +people via patch over e-mail. -gitlink:git-stripspace[1]:: - Filter out empty lines. +include::cmds-foreignscminterface.txt[] Low-level commands (plumbing) @@ -330,130 +137,30 @@ development of alternative porcelains. Developers of such porcelains might start by reading about gitlink:git-update-index[1] and gitlink:git-read-tree[1]. -We divide the low-level commands into commands that manipulate objects (in +The interface (input, output, set of options and the semantics) +to these low-level commands are meant to be a lot more stable +than Porcelain level commands, because these commands are +primarily for scripted use. The interface to Porcelain commands +on the other hand are subject to change in order to improve the +end user experience. + +The following description divides +the low-level commands into commands that manipulate objects (in the repository, index, and working tree), commands that interrogate and compare objects, and commands that move objects and references between repositories. + Manipulation commands ~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-apply[1]:: - Reads a "diff -up1" or git generated patch file and - applies it to the working tree. - -gitlink:git-checkout-index[1]:: - Copy files from the index to the working tree. - -gitlink:git-commit-tree[1]:: - Creates a new commit object. - -gitlink:git-hash-object[1]:: - Computes the object ID from a file. - -gitlink:git-index-pack[1]:: - Build pack idx file for an existing packed archive. - -gitlink:git-init[1]:: -gitlink:git-init-db[1]:: - Creates an empty git object database, or reinitialize an - existing one. - -gitlink:git-merge-file[1]:: - Runs a threeway merge. - -gitlink:git-merge-index[1]:: - Runs a merge for files needing merging. - -gitlink:git-mktag[1]:: - Creates a tag object. - -gitlink:git-mktree[1]:: - Build a tree-object from ls-tree formatted text. - -gitlink:git-pack-objects[1]:: - Creates a packed archive of objects. -gitlink:git-prune-packed[1]:: - Remove extra objects that are already in pack files. - -gitlink:git-read-tree[1]:: - Reads tree information into the index. - -gitlink:git-repo-config[1]:: - Get and set options in .git/config. - -gitlink:git-unpack-objects[1]:: - Unpacks objects out of a packed archive. - -gitlink:git-update-index[1]:: - Registers files in the working tree to the index. - -gitlink:git-write-tree[1]:: - Creates a tree from the index. +include::cmds-plumbingmanipulators.txt[] Interrogation commands ~~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-cat-file[1]:: - Provide content or type/size information for repository objects. - -gitlink:git-describe[1]:: - Show the most recent tag that is reachable from a commit. - -gitlink:git-diff-index[1]:: - Compares content and mode of blobs between the index and repository. - -gitlink:git-diff-files[1]:: - Compares files in the working tree and the index. - -gitlink:git-diff-stages[1]:: - Compares two "merge stages" in the index. - -gitlink:git-diff-tree[1]:: - Compares the content and mode of blobs found via two tree objects. - -gitlink:git-for-each-ref[1]:: - Output information on each ref. - -gitlink:git-fsck-objects[1]:: - Verifies the connectivity and validity of the objects in the database. - -gitlink:git-ls-files[1]:: - Information about files in the index and the working tree. - -gitlink:git-ls-tree[1]:: - Displays a tree object in human readable form. - -gitlink:git-merge-base[1]:: - Finds as good common ancestors as possible for a merge. - -gitlink:git-name-rev[1]:: - Find symbolic names for given revs. - -gitlink:git-pack-redundant[1]:: - Find redundant pack files. - -gitlink:git-rev-list[1]:: - Lists commit objects in reverse chronological order. - -gitlink:git-show-index[1]:: - Displays contents of a pack idx file. - -gitlink:git-show-ref[1]:: - List references in a local repository. - -gitlink:git-tar-tree[1]:: - Creates a tar archive of the files in the named tree object. - -gitlink:git-unpack-file[1]:: - Creates a temporary file with a blob's contents. - -gitlink:git-var[1]:: - Displays a git logical variable. - -gitlink:git-verify-pack[1]:: - Validates packed git archive files. +include::cmds-plumbinginterrogators.txt[] In general, the interrogate commands do not touch the files in the working tree. @@ -462,52 +169,21 @@ the working tree. Synching repositories ~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-fetch-pack[1]:: - Updates from a remote repository (engine for ssh and - local transport). - -gitlink:git-http-fetch[1]:: - Downloads a remote git repository via HTTP by walking - commit chain. - -gitlink:git-local-fetch[1]:: - Duplicates another git repository on a local system by - walking commit chain. - -gitlink:git-peek-remote[1]:: - Lists references on a remote repository using - upload-pack protocol (engine for ssh and local - transport). - -gitlink:git-receive-pack[1]:: - Invoked by 'git-send-pack' to receive what is pushed to it. - -gitlink:git-send-pack[1]:: - Pushes to a remote repository, intelligently. - -gitlink:git-http-push[1]:: - Push missing objects using HTTP/DAV. +include::cmds-synchingrepositories.txt[] -gitlink:git-shell[1]:: - Restricted shell for GIT-only SSH access. +The following are helper programs used by the above; end users +typically do not use them directly. -gitlink:git-ssh-fetch[1]:: - Pulls from a remote repository over ssh connection by - walking commit chain. +include::cmds-synchelpers.txt[] -gitlink:git-ssh-upload[1]:: - Helper "server-side" program used by git-ssh-fetch. -gitlink:git-update-server-info[1]:: - Updates auxiliary information on a dumb server to help - clients discover references and packs on it. +Internal helper commands +~~~~~~~~~~~~~~~~~~~~~~~~ -gitlink:git-upload-archive[1]:: - Invoked by 'git-archive' to send a generated archive. +These are internal helper commands used by other commands; end +users typically do not use them directly. -gitlink:git-upload-pack[1]:: - Invoked by 'git-fetch-pack' to push - what are asked for. +include::cmds-purehelpers.txt[] Configuration Mechanism @@ -700,7 +376,7 @@ other Discussion[[Discussion]] ------------------------ -include::README[] +include::core-intro.txt[] Authors ------- diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index f1aeb07f64..48c5894736 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -3,7 +3,7 @@ gitk(1) NAME ---- -gitk - git repository browser +gitk - The git repository browser SYNOPSIS -------- @@ -47,12 +47,14 @@ frequently used options. meaning show from the given revision and back, or it can be a range in the form "'<from>'..'<to>'" to show all revisions between '<from>' and back to '<to>'. Note, more advanced revision selection can be applied. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. <path>:: Limit commits to the ones touching files in the given paths. Note, to avoid ambiguity wrt. revision names use "--" to separate the paths - from any preceeding options. + from any preceding options. Examples -------- diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt index cd61aa2606..d20eb6270c 100644 --- a/Documentation/glossary.txt +++ b/Documentation/glossary.txt @@ -259,7 +259,7 @@ refspec:: means "grab the master branch head from the $URL and store it as my origin branch head". And `git push $URL refs/heads/master:refs/heads/to-upstream` - means "publish my master branch head as to-upstream master head + means "publish my master branch head as to-upstream branch at $URL". See also gitlink:git-push[1] repository:: @@ -286,6 +286,18 @@ SCM:: SHA1:: Synonym for object name. +shallow repository:: + A shallow repository has an incomplete history some of + whose commits have parents cauterized away (in other + words, git is told to pretend that these commits do not + have the parents, even though they are recorded in the + commit object). This is sometimes useful when you are + interested only in the recent history of a project even + though the real history recorded in the upstream is + much larger. A shallow repository is created by giving + `--depth` option to gitlink:git-clone[1], and its + history can be later deepened with gitlink:git-fetch[1]. + symref:: Symbolic reference: instead of containing the SHA1 id itself, it is of the format 'ref: refs/some/thing' and when referenced, it diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt index 161123f142..b083290d12 100644 --- a/Documentation/hooks.txt +++ b/Documentation/hooks.txt @@ -3,7 +3,7 @@ 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-db` is run, a handful example hooks are copied in the +`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`. @@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of `git-commit`. -The default 'post-commit' hook, when enabled, demonstrates how to -send out a commit notification e-mail. - update ------ @@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you want to report something to the `git-send-pack` on the other end, you can simply `echo` your messages. +The default 'update' hook, when enabled, demonstrates how to +send out a notification e-mail. post-update ----------- diff --git a/Documentation/howto/dangling-objects.txt b/Documentation/howto/dangling-objects.txt new file mode 100644 index 0000000000..e82ddae3cf --- /dev/null +++ b/Documentation/howto/dangling-objects.txt @@ -0,0 +1,109 @@ +From: Linus Torvalds <torvalds@linux-foundation.org> +Subject: Re: Question about fsck-objects output +Date: Thu, 25 Jan 2007 12:01:06 -0800 (PST) +Message-ID: <Pine.LNX.4.64.0701251144290.25027@woody.linux-foundation.org> +Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/37754> +Abstract: Linus describes what dangling objects are, when they + are left behind, and how to view their relationship with branch + heads in gitk + +On Thu, 25 Jan 2007, Larry Streepy wrote: + +> Sorry to ask such a basic question, but I can't quite decipher the output of +> fsck-objects. When I run it, I get this: +> +> git fsck-objects +> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b +> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f +> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761 +> +> +> Even after a "repack -a -d" they still exist. The man page has a short +> explanation, but, at least for me, it wasn't fully enlightening. :-) +> +> The man page says that dangling commits could be "root" commits, but since my +> repo started as a clone of another repo, I don't see how I could have any root +> commits. Also, the page doesn't really describe what a dangling blob is. +> +> So, can someone explain what these artifacts are and if they are a problem +> that I should be worried about? + +The most common situation is that you've rebased a branch (or you have +pulled from somebody else who rebased a branch, like the "pu" branch in +the git.git archive itself). + +What happens is that the old head of the original branch still exists, as +does obviously everything it pointed to. The branch pointer itself just +doesn't, since you replaced it with another one. + +However, there are certainly other situations too that cause dangling +objects. For example, the "dangling blob" situation you have tends to be +because you did a "git add" of a file, but then, before you actually +committed it and made it part of the bigger picture, you changed something +else in that file and committed that *updated* thing - the old state that +you added originally ends up not being pointed to by any commit/tree, so +it's now a dangling blob object. + +Similarly, when the "recursive" merge strategy runs, and finds that there +are criss-cross merges and thus more than one merge base (which is fairly +unusual, but it does happen), it will generate one temporary midway tree +(or possibly even more, if you had lots of criss-crossing merges and +more than two merge bases) as a temporary internal merge base, and again, +those are real objects, but the end result will not end up pointing to +them, so they end up "dangling" in your repository. + +Generally, dangling objects aren't anything to worry about. They can even +be very useful: if you screw something up, the dangling objects can be how +you recover your old tree (say, you did a rebase, and realized that you +really didn't want to - you can look at what dangling objects you have, +and decide to reset your head to some old dangling state). + +For commits, the most useful thing to do with dangling objects tends to be +to do a simple + + gitk <dangling-commit-sha-goes-here> --not --all + +which means exactly what it sounds like: it says that you want to see the +commit history that is described by the dangling commit(s), but you do NOT +want to see the history that is described by all your branches and tags +(which are the things you normally reach). That basically shows you in a +nice way what the danglign commit was (and notice that it might not be +just one commit: we only report the "tip of the line" as being dangling, +but there might be a whole deep and complex commit history that has gotten +dropped - rebasing will do that). + +For blobs and trees, you can't do the same, but you can examine them. You +can just do + + git show <dangling-blob/tree-sha-goes-here> + +to show what the contents of the blob were (or, for a tree, basically what +the "ls" for that directory was), and that may give you some idea of what +the operation was that left that dangling object. + +Usually, dangling blobs and trees aren't very interesting. They're almost +always the result of either being a half-way mergebase (the blob will +often even have the conflict markers from a merge in it, if you have had +conflicting merges that you fixed up by hand), or simply because you +interrupted a "git fetch" with ^C or something like that, leaving _some_ +of the new objects in the object database, but just dangling and useless. + +Anyway, once you are sure that you're not interested in any dangling +state, you can just prune all unreachable objects: + + git prune + +and they'll be gone. But you should only run "git prune" on a quiescent +repository - it's kind of like doing a filesystem fsck recovery: you don't +want to do that while the filesystem is mounted. + +(The same is true of "git-fsck-objects" itself, btw - but since +git-fsck-objects never actually *changes* the repository, it just reports +on what it found, git-fsck-objects itself is never "dangerous" to run. +Running it while somebody is actually changing the repository can cause +confusing and scary messages, but it won't actually do anything bad. In +contrast, running "git prune" while somebody is actively changing the +repository is a *BAD* idea). + + Linus + diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index fcd64e9b9b..3b3a5c2e69 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -106,7 +106,7 @@ prepare #2 and #3 for e-mail submission. $ git format-patch master^^ master -This creates two files, 0001-XXXX.txt and 0002-XXXX.txt. Send +This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send them out "To: " your project maintainer and "Cc: " your mailing list. You could use contributed script git-send-email if your host has necessary perl modules for this, but your usual diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt index d10476b56e..d88ec23a97 100644 --- a/Documentation/howto/revert-branch-rebase.txt +++ b/Documentation/howto/revert-branch-rebase.txt @@ -85,7 +85,7 @@ Fortunately I did not have to; what I have in the current branch ------------------------------------------------ $ git checkout master -$ git resolve master revert-c99 fast ;# this should be a fast forward +$ git merge revert-c99 ;# this should be a fast forward Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c... cache.h | 8 ++++---- commit.c | 2 +- @@ -95,13 +95,6 @@ Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c... 5 files changed, 8 insertions(+), 8 deletions(-) ------------------------------------------------ -The 'fast' in the above 'git resolve' is not a magic. I knew this -'resolve' would result in a fast forward merge, and if not, there is -something very wrong (so I would do 'git reset' on the 'master' branch -and examine the situation). When a fast forward merge is done, the -message parameter to 'git resolve' is discarded, because no new commit -is created. You could have said 'junk' or 'nothing' there as well. - There is no need to redo the test at this point. We fast forwarded and we know 'master' matches 'revert-c99' exactly. In fact: diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index ba191569af..8eadc20494 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -70,7 +70,7 @@ DocumentRoot /where/ever/httpd.conf" to find your root: Initialize a bare repository $ cd my-new-repo.git - $ git --bare init-db + $ git --bare init Change the ownership to your web-server's credentials. Use "grep ^User @@ -205,7 +205,7 @@ To check whether all is OK, do: Now, add the remote in your existing repository which contains the project you want to export: - $ git-repo-config remote.upload.url \ + $ git-config remote.upload.url \ http://<username>@<servername>/my-new-repo.git/ It is important to put the last '/'; Without it, the server will send @@ -222,7 +222,7 @@ From your client repository, do This pushes branch 'master' (which is assumed to be the branch you want to export) to repository called 'upload', which we previously -defined with git-repo-config. +defined with git-config. Troubleshooting: diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh index 60211a5058..b3981936e3 100755 --- a/Documentation/install-webdoc.sh +++ b/Documentation/install-webdoc.sh @@ -2,7 +2,7 @@ T="$1" -for h in *.html *.txt howto/*.txt howto/*.html +for h in *.html *.txt howto/*.txt howto/*.html RelNotes-*.txt do if test -f "$T/$h" && diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt index e20fb7e74c..0459bd9ca1 100644 --- a/Documentation/repository-layout.txt +++ b/Documentation/repository-layout.txt @@ -18,6 +18,8 @@ could have only commit objects without associated blobs and trees this way, for example. A repository with this kind of incomplete object store is not suitable to be published to the outside world but sometimes useful for private repository. +. You also could have an incomplete but locally usable repository +by cloning shallowly. See gitlink:git-clone[1]. . You can be using `objects/info/alternates` mechanism, or `$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow' objects from other object stores. A repository with this kind @@ -32,7 +34,7 @@ objects/[0-9a-f][0-9a-f]:: two letters from its object name to keep the number of directory entries `objects` directory itself needs to hold. Objects found here are often called 'unpacked' - objects. + (or 'loose') objects. objects/pack:: Packs (files that store many object in compressed form, @@ -80,6 +82,15 @@ refs/tags/`name`:: records any object name (not necessarily a commit object, or a tag object that points at a commit object). +refs/remotes/`name`:: + records tip-of-the-tree commit objects of branches copied + from a remote repository. + +packed-refs:: + records the same information as refs/heads/, refs/tags/, + and friends record in a more efficient way. See + gitlink:git-pack-refs[1]. + HEAD:: A symref (see glossary) to the `refs/heads/` namespace describing the currently active branch. It does not mean @@ -91,6 +102,12 @@ HEAD:: 'name' does not (yet) exist. In some legacy setups, it is a symbolic link instead of a symref that points at the current branch. ++ +HEAD can also record a specific commit directly, instead of +being a symref to point at the current branch. Such a state +is often called 'detached HEAD', and almost all commands work +identically as normal. See gitlink:git-checkout[1] for +details. branches:: A slightly deprecated way to store shorthands to be used @@ -102,7 +119,7 @@ branches:: hooks:: Hooks are customization scripts used by various git commands. A handful of sample hooks are installed when - `git init-db` is run, but all of them are disabled by + `git init` is run, but all of them are disabled by default. To enable, they need to be made executable. Read link:hooks.html[hooks] for more details about each hook. @@ -116,14 +133,14 @@ info:: in this directory. info/refs:: - This file is to help dumb transports to discover what - refs are available in this repository. Whenever you - create/delete a new branch or a new tag, `git - update-server-info` should be run to keep this file - up-to-date if the repository is published for dumb - transports. The `git-receive-pack` command, which is - run on a remote repository when you `git push` into it, - runs `hooks/update` hook to help you achieve this. + This file helps dumb transports discover what refs are + available in this repository. If the repository is + published for dumb transports, this file should be + regenerated by `git update-server-info` every time a tag + or branch is created or modified. This is normally done + from the `hooks/update` hook, which is run by the + `git-receive-pack` command when you `git push` into the + repository. info/grafts:: This file records fake commit ancestry information, to @@ -156,3 +173,9 @@ logs/refs/heads/`name`:: logs/refs/tags/`name`:: Records all changes made to the tag named `name`. + +shallow:: + This is similar to `info/grafts` but is internally used + and maintained by shallow clone mechanism. See `--depth` + option to gitlink:git-clone[1] and gitlink:git-fetch[1]. + diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt index f48894c9a2..8d89992712 100644 --- a/Documentation/tutorial-2.txt +++ b/Documentation/tutorial-2.txt @@ -343,8 +343,8 @@ And, as you can see with cat-file, this new entry refers to the current contents of the file: ------------------------------------------------ -$ git cat-file blob a6b11f7a -goodbye, word +$ git cat-file blob 8b9743b2 +goodbye, world ------------------------------------------------ The "status" command is a useful way to get a quick summary of the @@ -352,24 +352,23 @@ situation: ------------------------------------------------ $ git status -# -# Added but not yet committed: -# (will commit) +# On branch master +# Changes to be committed: +# (use "git reset HEAD <file>..." to unstage) # # new file: closing.txt # -# -# Changed but not added: -# (use "git add file1 file2" to include for commit) +# 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 "added but not yet committed". Since file.txt has +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 added". At this point, running "git +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. diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index d2bf0b905a..129c5c5f5b 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -11,15 +11,13 @@ diff" with: $ man git-diff ------------------------------------------------ -It is a good idea to introduce yourself to git before doing any -operation. The easiest way to do so is: +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: ------------------------------------------------ -$ cat >~/.gitconfig <<\EOF -[user] - name = Your Name Comes Here - email = you@yourdomain.example.com -EOF +$ git config --global user.name "Your Name Comes Here" +$ git config --global user.email you@yourdomain.example.com ------------------------------------------------ @@ -103,27 +101,27 @@ want to commit together. This can be done in a few different ways: 1) By using 'git add <file_spec>...' - This can be performed multiple times before a commit. Note that this - is not only for adding new files. Even modified files must be - added to the set of changes about to be committed. The "git status" - command gives you a summary of what is included so far for the - next commit. When done you should use the 'git commit' command to - make it real. +This can be performed multiple times before a commit. Note that this +is not only for adding new files. Even modified files must be +added to the set of changes about to be committed. The "git status" +command gives you a summary of what is included so far for the +next commit. When done you should use the 'git commit' command to +make it real. - Note: don't forget to 'add' a file again if you modified it after the - first 'add' and before 'commit'. Otherwise only the previous added - state of that file will be committed. This is because git tracks - content, so what you're really 'add'ing to the commit is the *content* - of the file in the state it is in when you 'add' it. +Note: don't forget to 'add' a file again if you modified it after the +first 'add' and before 'commit'. Otherwise only the previous added +state of that file will be committed. This is because git tracks +content, so what you're really 'add'ing to the commit is the *content* +of the file in the state it is in when you 'add' it. 2) By using 'git commit -a' directly - This is a quick way to automatically 'add' the content from all files - that were modified since the previous commit, and perform the actual - commit without having to separately 'add' them beforehand. This will - not add content from new files i.e. files that were never added before. - Those files still have to be added explicitly before performing a - commit. +This is a quick way to automatically 'add' the content from all files +that were modified since the previous commit, and perform the actual +commit without having to separately 'add' them beforehand. This will +not add content from new files i.e. files that were never added before. +Those files still have to be added explicitly before performing a +commit. But here's a twist. If you do 'git commit <file1> <file2> ...' then only the changes belonging to those explicitly specified files will be @@ -211,7 +209,7 @@ 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 pull . experimental +$ git merge experimental ------------------------------------------------ If the changes don't conflict, you're done. If there are conflicts, @@ -297,46 +295,51 @@ is the default.) The "pull" command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch. -You can perform the first operation alone using the "git fetch" -command. For example, Alice could create a temporary branch just to -track Bob's changes, without merging them with her own, using: +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, you can perform the first operation alone using the +"git fetch" command without merging them with her own branch, +using: ------------------------------------- -$ git fetch /home/bob/myrepo master:bob-incoming +$ git fetch bob ------------------------------------- -which fetches the changes from Bob's master branch into a new branch -named bob-incoming. Then +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-incoming +$ 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, and possibly fixing things, Alice -could pull the changes into her master branch: +After examining those changes, Alice +could merge the changes into her master branch: ------------------------------------- -$ git checkout master -$ git pull . bob-incoming +$ git merge bob/master ------------------------------------- -The last command is a pull from the "bob-incoming" branch in Alice's -own repository. - -Alice could also perform both steps at once with: +This `merge` can also be done by 'pulling from her own remote +tracking branch', like this: ------------------------------------- -$ git pull /home/bob/myrepo master:bob-incoming +$ git pull . remotes/bob/master ------------------------------------- -This is just like the "git pull /home/bob/myrepo master" that we saw -before, except that it also stores the unmerged changes from bob's -master branch in bob-incoming before merging them into Alice's -current branch. Note that git pull always merges into the current -branch, regardless of what else is given on the commandline. +Note that git pull always merges into the current branch, +regardless of what else is given on the commandline. Later, Bob can update his repo with Alice's latest changes using @@ -350,12 +353,12 @@ repository in the repository configuration, and that location is used for pulls: ------------------------------------- -$ git repo-config --get remote.origin.url +$ git config --get remote.origin.url /home/bob/myrepo ------------------------------------- (The complete configuration created by git-clone is visible using -"git repo-config -l", and the gitlink:git-repo-config[1] man page +"git config -l", and the gitlink:git-config[1] man page explains the meaning of each option.) Git also keeps a pristine copy of Alice's master branch under the @@ -455,9 +458,11 @@ $ git reset --hard HEAD^ # reset your current branch and working 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 git will -be confused by history that disappears in this way.) +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 gitlink:git-revert[1] +instead. The git grep command can search for strings in any version of your project, so diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf new file mode 100644 index 0000000000..92b01ecf71 --- /dev/null +++ b/Documentation/user-manual.conf @@ -0,0 +1,21 @@ +[titles] + underlines="__","==","--","~~","^^" + +[attributes] +caret=^ +startsb=[ +endsb=] +tilde=~ + +[gitlink-inlinemacro] +<ulink url="{target}.html">{target}{0?({0})}</ulink> + +ifdef::backend-docbook[] +# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. +[listingblock] +<example><title>{title}</title> +<literallayout> +| +</literallayout> +{title#}</example> +endif::backend-docbook[] diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt new file mode 100644 index 0000000000..03736bbcd3 --- /dev/null +++ b/Documentation/user-manual.txt @@ -0,0 +1,2961 @@ +Git User's Manual +_________________ + +This manual is designed to be readable by someone with basic unix +commandline skills, but no previous knowledge of git. + +Chapter 1 gives a brief overview of git commands, without any +explanation; you may prefer to skip to chapter 2 on a first reading. + +Chapters 2 and 3 explain how to fetch and study a project using +git--the tools you'd need to build and test a particular version of a +software project, to search for regressions, and so on. + +Chapter 4 explains how to do development with git, and chapter 5 how +to share that development with others. + +Further chapters cover more specialized topics. + +Comprehensive reference documentation is available through the man +pages. For a command such as "git clone", just use + +------------------------------------------------ +$ man git-clone +------------------------------------------------ + +Git Quick Start +=============== + +This is a quick summary of the major commands; the following chapters +will explain how these work in more detail. + +Creating a new repository +------------------------- + +From a tarball: + +----------------------------------------------- +$ tar xzf project.tar.gz +$ cd project +$ git init +Initialized empty Git repository in .git/ +$ git add . +$ git commit +----------------------------------------------- + +From a remote repository: + +----------------------------------------------- +$ git clone git://example.com/pub/project.git +$ cd project +----------------------------------------------- + +Managing branches +----------------- + +----------------------------------------------- +$ git branch # list all branches in this repo +$ git checkout test # switch working directory to branch "test" +$ git branch new # create branch "new" starting at current HEAD +$ git branch -d new # delete branch "new" +----------------------------------------------- + +Instead of basing new branch on current HEAD (the default), use: + +----------------------------------------------- +$ git branch new test # branch named "test" +$ git branch new v2.6.15 # tag named v2.6.15 +$ git branch new HEAD^ # commit before the most recent +$ git branch new HEAD^^ # commit before that +$ git branch new test~10 # ten commits before tip of branch "test" +----------------------------------------------- + +Create and switch to a new branch at the same time: + +----------------------------------------------- +$ git checkout -b new v2.6.15 +----------------------------------------------- + +Update and examine branches from the repository you cloned from: + +----------------------------------------------- +$ git fetch # update +$ git branch -r # list + origin/master + origin/next + ... +$ git branch checkout -b masterwork origin/master +----------------------------------------------- + +Fetch a branch from a different repository, and give it a new +name in your repository: + +----------------------------------------------- +$ git fetch git://example.com/project.git theirbranch:mybranch +$ git fetch git://example.com/project.git v2.6.15:mybranch +----------------------------------------------- + +Keep a list of repositories you work with regularly: + +----------------------------------------------- +$ git remote add example git://example.com/project.git +$ git remote # list remote repositories +example +origin +$ git remote show example # get details +* remote example + URL: git://example.com/project.git + Tracked remote branches + master next ... +$ git fetch example # update branches from example +$ git branch -r # list all remote branches +----------------------------------------------- + + +Exploring history +----------------- + +----------------------------------------------- +$ gitk # visualize and browse history +$ git log # list all commits +$ git log src/ # ...modifying src/ +$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15 +$ git log master..test # ...in branch test, not in branch master +$ git log test..master # ...in branch master, but not in test +$ git log test...master # ...in one branch, not in both +$ git log -S'foo()' # ...where difference contain "foo()" +$ git log --since="2 weeks ago" +$ git log -p # show patches as well +$ git show # most recent commit +$ git diff v2.6.15..v2.6.16 # diff between two tagged versions +$ git diff v2.6.15..HEAD # diff with current head +$ git grep "foo()" # search working directory for "foo()" +$ git grep v2.6.15 "foo()" # search old tree for "foo()" +$ git show v2.6.15:a.txt # look at old version of a.txt +----------------------------------------------- + +Search for regressions: + +----------------------------------------------- +$ git bisect start +$ git bisect bad # current version is bad +$ git bisect good v2.6.13-rc2 # last known good revision +Bisecting: 675 revisions left to test after this + # test here, then: +$ git bisect good # if this revision is good, or +$ git bisect bad # if this revision is bad. + # repeat until done. +----------------------------------------------- + +Making changes +-------------- + +Make sure git knows who to blame: + +------------------------------------------------ +$ cat >~/.gitconfig <<\EOF +[user] +name = Your Name Comes Here +email = you@yourdomain.example.com +EOF +------------------------------------------------ + +Select file contents to include in the next commit, then make the +commit: + +----------------------------------------------- +$ git add a.txt # updated file +$ git add b.txt # new file +$ git rm c.txt # old file +$ git commit +----------------------------------------------- + +Or, prepare and create the commit in one step: + +----------------------------------------------- +$ git commit d.txt # use latest content only of d.txt +$ git commit -a # use latest content of all tracked files +----------------------------------------------- + +Merging +------- + +----------------------------------------------- +$ git merge test # merge branch "test" into the current branch +$ git pull git://example.com/project.git master + # fetch and merge in remote branch +$ git pull . test # equivalent to git merge test +----------------------------------------------- + +Sharing your changes +-------------------- + +Importing or exporting patches: + +----------------------------------------------- +$ git format-patch origin..HEAD # format a patch for each commit + # in HEAD but not in origin +$ git-am mbox # import patches from the mailbox "mbox" +----------------------------------------------- + +Fetch a branch in a different git repository, then merge into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch +----------------------------------------------- + +Store the fetched branch into a local branch before merging into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch:mybranch +----------------------------------------------- + +After creating commits on a local branch, update the remote +branch with your commits: + +----------------------------------------------- +$ git push ssh://example.com/project.git mybranch:theirbranch +----------------------------------------------- + +When remote and local branch are both named "test": + +----------------------------------------------- +$ git push ssh://example.com/project.git test +----------------------------------------------- + +Shortcut version for a frequently used remote repository: + +----------------------------------------------- +$ git remote add example ssh://example.com/project.git +$ git push example test +----------------------------------------------- + +Repository maintenance +---------------------- + +Check for corruption: + +----------------------------------------------- +$ git fsck +----------------------------------------------- + +Recompress, remove unused cruft: + +----------------------------------------------- +$ git gc +----------------------------------------------- + +Repositories and Branches +========================= + +How to get a git repository +--------------------------- + +It will be useful to have a git repository to experiment with as you +read this manual. + +The best way to get one is by using the gitlink:git-clone[1] command +to download a copy of an existing repository for a project that you +are interested in. If you don't already have a project in mind, here +are some interesting examples: + +------------------------------------------------ + # git itself (approx. 10MB download): +$ git clone git://git.kernel.org/pub/scm/git/git.git + # the linux kernel (approx. 150MB download): +$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git +------------------------------------------------ + +The initial clone may be time-consuming for a large project, but you +will only need to clone once. + +The clone command creates a new directory named after the project +("git" or "linux-2.6" in the examples above). After you cd into this +directory, you will see that it contains a copy of the project files, +together with a special top-level directory named ".git", which +contains all the information about the history of the project. + +In most of the following, examples will be taken from one of the two +repositories above. + +How to check out a different version of a project +------------------------------------------------- + +Git is best thought of as a tool for storing the history of a +collection of files. It stores the history as a compressed +collection of interrelated snapshots (versions) of the project's +contents. + +A single git repository may contain multiple branches. Each branch +is a bookmark referencing a particular point in the project history. +The gitlink:git-branch[1] command shows you the list of branches: + +------------------------------------------------ +$ git branch +* master +------------------------------------------------ + +A freshly cloned repository contains a single branch, named "master", +and the working directory contains the version of the project +referred to by the master branch. + +Most projects also use tags. Tags, like branches, are references +into the project's history, and can be listed using the +gitlink:git-tag[1] command: + +------------------------------------------------ +$ git tag -l +v2.6.11 +v2.6.11-tree +v2.6.12 +v2.6.12-rc2 +v2.6.12-rc3 +v2.6.12-rc4 +v2.6.12-rc5 +v2.6.12-rc6 +v2.6.13 +... +------------------------------------------------ + +Tags are expected to always point at the same version of a project, +while branches are expected to advance as development progresses. + +Create a new branch pointing to one of these versions and check it +out using gitlink:git-checkout[1]: + +------------------------------------------------ +$ git checkout -b new v2.6.13 +------------------------------------------------ + +The working directory then reflects the contents that the project had +when it was tagged v2.6.13, and gitlink:git-branch[1] shows two +branches, with an asterisk marking the currently checked-out branch: + +------------------------------------------------ +$ git branch + master +* new +------------------------------------------------ + +If you decide that you'd rather see version 2.6.17, you can modify +the current branch to point at v2.6.17 instead, with + +------------------------------------------------ +$ git reset --hard v2.6.17 +------------------------------------------------ + +Note that if the current branch was your only reference to a +particular point in history, then resetting that branch may leave you +with no way to find the history it used to point to; so use this +command carefully. + +Understanding History: Commits +------------------------------ + +Every change in the history of a project is represented by a commit. +The gitlink:git-show[1] command shows the most recent commit on the +current branch: + +------------------------------------------------ +$ git show +commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2 +Author: Jamal Hadi Salim <hadi@cyberus.ca> +Date: Sat Dec 2 22:22:25 2006 -0800 + + [XFRM]: Fix aevent structuring to be more complete. + + aevents can not uniquely identify an SA. We break the ABI with this + patch, but consensus is that since it is not yet utilized by any + (known) application then it is fine (better do it now than later). + + Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> + Signed-off-by: David S. Miller <davem@davemloft.net> + +diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt +index 8be626f..d7aac9d 100644 +--- a/Documentation/networking/xfrm_sync.txt ++++ b/Documentation/networking/xfrm_sync.txt +@@ -47,10 +47,13 @@ aevent_id structure looks like: + + struct xfrm_aevent_id { + struct xfrm_usersa_id sa_id; ++ xfrm_address_t saddr; + __u32 flags; ++ __u32 reqid; + }; +... +------------------------------------------------ + +As you can see, a commit shows who made the latest change, what they +did, and why. + +Every commit has a 40-hexdigit id, sometimes called the "object name" +or the "SHA1 id", shown on the first line of the "git show" output. +You can usually refer to a commit by a shorter name, such as a tag or a +branch name, but this longer name can also be useful. Most +importantly, it is a globally unique name for this commit: so if you +tell somebody else the object name (for example in email), then you are +guaranteed that name will refer to the same commit in their repository +that it does in yours (assuming their repository has that commit at +all). + +Understanding history: commits, parents, and reachability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Every commit (except the very first commit in a project) also has a +parent commit which shows what happened before this commit. +Following the chain of parents will eventually take you back to the +beginning of the project. + +However, the commits do not form a simple list; git allows lines of +development to diverge and then reconverge, and the point where two +lines of development reconverge is called a "merge". The commit +representing a merge can therefore have more than one parent, with +each parent representing the most recent commit on one of the lines +of development leading to that point. + +The best way to see how this works is using the gitlink:gitk[1] +command; running gitk now on a git repository and looking for merge +commits will help understand how the git organizes history. + +In the following, we say that commit X is "reachable" from commit Y +if commit X is an ancestor of commit Y. Equivalently, you could say +that Y is a descendent of X, or that there is a chain of parents +leading from commit Y to commit X. + +Understanding history: History diagrams +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We will sometimes represent git history using diagrams like the one +below. Commits are shown as "o", and the links between them with +lines drawn with - / and \. Time goes left to right: + + o--o--o <-- Branch A + / + o--o--o <-- master + \ + o--o--o <-- Branch B + +If we need to talk about a particular commit, the character "o" may +be replaced with another letter or number. + +Understanding history: What is a branch? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Though we've been using the word "branch" to mean a kind of reference +to a particular commit, the word branch is also commonly used to +refer to the line of commits leading up to that point. In the +example above, git may think of the branch named "A" as just a +pointer to one particular commit, but we may refer informally to the +line of three commits leading up to that point as all being part of +"branch A". + +If we need to make it clear that we're just talking about the most +recent commit on the branch, we may refer to that commit as the +"head" of the branch. + +Manipulating branches +--------------------- + +Creating, deleting, and modifying branches is quick and easy; here's +a summary of the commands: + +git branch:: + list all branches +git branch <branch>:: + create a new branch named <branch>, referencing the same + point in history as the current branch +git branch <branch> <start-point>:: + create a new branch named <branch>, referencing + <start-point>, which may be specified any way you like, + including using a branch name or a tag name +git branch -d <branch>:: + delete the branch <branch>; if the branch you are deleting + points to a commit which is not reachable from this branch, + this command will fail with a warning. +git branch -D <branch>:: + even if the branch points to a commit not reachable + from the current branch, you may know that that commit + is still reachable from some other branch or tag. In that + case it is safe to use this command to force git to delete + the branch. +git checkout <branch>:: + make the current branch <branch>, updating the working + directory to reflect the version referenced by <branch> +git checkout -b <new> <start-point>:: + create a new branch <new> referencing <start-point>, and + check it out. + +It is also useful to know that the special symbol "HEAD" can always +be used to refer to the current branch. + +Examining branches from a remote repository +------------------------------------------- + +The "master" branch that was created at the time you cloned is a copy +of the HEAD in the repository that you cloned from. That repository +may also have had other branches, though, and your local repository +keeps branches which track each of those remote branches, which you +can view using the "-r" option to gitlink:git-branch[1]: + +------------------------------------------------ +$ git branch -r + origin/HEAD + origin/html + origin/maint + origin/man + origin/master + origin/next + origin/pu + origin/todo +------------------------------------------------ + +You cannot check out these remote-tracking branches, but you can +examine them on a branch of your own, just as you would a tag: + +------------------------------------------------ +$ git checkout -b my-todo-copy origin/todo +------------------------------------------------ + +Note that the name "origin" is just the name that git uses by default +to refer to the repository that you cloned from. + +[[how-git-stores-references]] +Naming branches, tags, and other references +------------------------------------------- + +Branches, remote-tracking branches, and tags are all references to +commits. All references are named with a slash-separated path name +starting with "refs"; the names we've been using so far are actually +shorthand: + + - The branch "test" is short for "refs/heads/test". + - The tag "v2.6.18" is short for "refs/tags/v2.6.18". + - "origin/master" is short for "refs/remotes/origin/master". + +The full name is occasionally useful if, for example, there ever +exists a tag and a branch with the same name. + +As another useful shortcut, if the repository "origin" posesses only +a single branch, you can refer to that branch as just "origin". + +More generally, if you have defined a remote repository named +"example", you can refer to the branch in that repository as +"example". And for a repository with multiple branches, this will +refer to the branch designated as the "HEAD" branch. + +For the complete list of paths which git checks for references, and +the order it uses to decide which to choose when there are multiple +references with the same shorthand name, see the "SPECIFYING +REVISIONS" section of gitlink:git-rev-parse[1]. + +[[Updating-a-repository-with-git-fetch]] +Updating a repository with git fetch +------------------------------------ + +Eventually the developer cloned from will do additional work in her +repository, creating new commits and advancing the branches to point +at the new commits. + +The command "git fetch", with no arguments, will update all of the +remote-tracking branches to the latest version found in her +repository. It will not touch any of your own branches--not even the +"master" branch that was created for you on clone. + +Fetching branches from other repositories +----------------------------------------- + +You can also track branches from repositories other than the one you +cloned from, using gitlink:git-remote[1]: + +------------------------------------------------- +$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git +$ git fetch +* refs/remotes/linux-nfs/master: storing branch 'master' ... + commit: bf81b46 +------------------------------------------------- + +New remote-tracking branches will be stored under the shorthand name +that you gave "git remote add", in this case linux-nfs: + +------------------------------------------------- +$ git branch -r +linux-nfs/master +origin/master +------------------------------------------------- + +If you run "git fetch <remote>" later, the tracking branches for the +named <remote> will be updated. + +If you examine the file .git/config, you will see that git has added +a new stanza: + +------------------------------------------------- +$ cat .git/config +... +[remote "linux-nfs"] + url = git://linux-nfs.org/~bfields/git.git + fetch = +refs/heads/*:refs/remotes/linux-nfs-read/* +... +------------------------------------------------- + +This is what causes git to track the remote's branches; you may modify +or delete these configuration options by editing .git/config with a +text editor. (See the "CONFIGURATION FILE" section of +gitlink:git-config[1] for details.) + +Exploring git history +===================== + +Git is best thought of as a tool for storing the history of a +collection of files. It does this by storing compressed snapshots of +the contents of a file heirarchy, together with "commits" which show +the relationships between these snapshots. + +Git provides extremely flexible and fast tools for exploring the +history of a project. + +We start with one specialized tool that is useful for finding the +commit that introduced a bug into a project. + +How to use bisect to find a regression +-------------------------------------- + +Suppose version 2.6.18 of your project worked, but the version at +"master" crashes. Sometimes the best way to find the cause of such a +regression is to perform a brute-force search through the project's +history to find the particular commit that caused the problem. The +gitlink:git-bisect[1] command can help you do this: + +------------------------------------------------- +$ git bisect start +$ git bisect good v2.6.18 +$ git bisect bad master +Bisecting: 3537 revisions left to test after this +[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6] +------------------------------------------------- + +If you run "git branch" at this point, you'll see that git has +temporarily moved you to a new branch named "bisect". This branch +points to a commit (with commit id 65934...) that is reachable from +v2.6.19 but not from v2.6.18. Compile and test it, and see whether +it crashes. Assume it does crash. Then: + +------------------------------------------------- +$ git bisect bad +Bisecting: 1769 revisions left to test after this +[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings +------------------------------------------------- + +checks out an older version. Continue like this, telling git at each +stage whether the version it gives you is good or bad, and notice +that the number of revisions left to test is cut approximately in +half each time. + +After about 13 tests (in this case), it will output the commit id of +the guilty commit. You can then examine the commit with +gitlink:git-show[1], find out who wrote it, and mail them your bug +report with the commit id. Finally, run + +------------------------------------------------- +$ git bisect reset +------------------------------------------------- + +to return you to the branch you were on before and delete the +temporary "bisect" branch. + +Note that the version which git-bisect checks out for you at each +point is just a suggestion, and you're free to try a different +version if you think it would be a good idea. For example, +occasionally you may land on a commit that broke something unrelated; +run + +------------------------------------------------- +$ git bisect-visualize +------------------------------------------------- + +which will run gitk and label the commit it chose with a marker that +says "bisect". Chose a safe-looking commit nearby, note its commit +id, and check it out with: + +------------------------------------------------- +$ git reset --hard fb47ddb2db... +------------------------------------------------- + +then test, run "bisect good" or "bisect bad" as appropriate, and +continue. + +Naming commits +-------------- + +We have seen several ways of naming commits already: + + - 40-hexdigit object name + - branch name: refers to the commit at the head of the given + branch + - tag name: refers to the commit pointed to by the given tag + (we've seen branches and tags are special cases of + <<how-git-stores-references,references>>). + - HEAD: refers to the head of the current branch + +There are many more; see the "SPECIFYING REVISIONS" section of the +gitlink:git-rev-parse[1] man page for the complete list of ways to +name revisions. Some examples: + +------------------------------------------------- +$ git show fb47ddb2 # the first few characters of the object name + # are usually enough to specify it uniquely +$ git show HEAD^ # the parent of the HEAD commit +$ git show HEAD^^ # the grandparent +$ git show HEAD~4 # the great-great-grandparent +------------------------------------------------- + +Recall that merge commits may have more than one parent; by default, +^ and ~ follow the first parent listed in the commit, but you can +also choose: + +------------------------------------------------- +$ git show HEAD^1 # show the first parent of HEAD +$ git show HEAD^2 # show the second parent of HEAD +------------------------------------------------- + +In addition to HEAD, there are several other special names for +commits: + +Merges (to be discussed later), as well as operations such as +git-reset, which change the currently checked-out commit, generally +set ORIG_HEAD to the value HEAD had before the current operation. + +The git-fetch operation always stores the head of the last fetched +branch in FETCH_HEAD. For example, if you run git fetch without +specifying a local branch as the target of the operation + +------------------------------------------------- +$ git fetch git://example.com/proj.git theirbranch +------------------------------------------------- + +the fetched commits will still be available from FETCH_HEAD. + +When we discuss merges we'll also see the special name MERGE_HEAD, +which refers to the other branch that we're merging in to the current +branch. + +The gitlink:git-rev-parse[1] command is a low-level command that is +occasionally useful for translating some name for a commit to the object +name for that commit: + +------------------------------------------------- +$ git rev-parse origin +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +Creating tags +------------- + +We can also create a tag to refer to a particular commit; after +running + +------------------------------------------------- +$ git-tag stable-1 1b2e1d63ff +------------------------------------------------- + +You can use stable-1 to refer to the commit 1b2e1d63ff. + +This creates a "lightweight" tag. If the tag is a tag you wish to +share with others, and possibly sign cryptographically, then you +should create a tag object instead; see the gitlink:git-tag[1] man +page for details. + +Browsing revisions +------------------ + +The gitlink:git-log[1] command can show lists of commits. On its +own, it shows all commits reachable from the parent commit; but you +can also make more specific requests: + +------------------------------------------------- +$ git log v2.5.. # commits since (not reachable from) v2.5 +$ git log test..master # commits reachable from master but not test +$ git log master..test # ...reachable from test but not master +$ git log master...test # ...reachable from either test or master, + # but not both +$ git log --since="2 weeks ago" # commits from the last 2 weeks +$ git log Makefile # commits which modify Makefile +$ git log fs/ # ... which modify any file under fs/ +$ git log -S'foo()' # commits which add or remove any file data + # matching the string 'foo()' +------------------------------------------------- + +And of course you can combine all of these; the following finds +commits since v2.5 which touch the Makefile or any file under fs: + +------------------------------------------------- +$ git log v2.5.. Makefile fs/ +------------------------------------------------- + +You can also ask git log to show patches: + +------------------------------------------------- +$ git log -p +------------------------------------------------- + +See the "--pretty" option in the gitlink:git-log[1] man page for more +display options. + +Note that git log starts with the most recent commit and works +backwards through the parents; however, since git history can contain +multiple independent lines of development, the particular order that +commits are listed in may be somewhat arbitrary. + +Generating diffs +---------------- + +You can generate diffs between any two versions using +gitlink:git-diff[1]: + +------------------------------------------------- +$ git diff master..test +------------------------------------------------- + +Sometimes what you want instead is a set of patches: + +------------------------------------------------- +$ git format-patch master..test +------------------------------------------------- + +will generate a file with a patch for each commit reachable from test +but not from master. Note that if master also has commits which are +not reachable from test, then the combined result of these patches +will not be the same as the diff produced by the git-diff example. + +Viewing old file versions +------------------------- + +You can always view an old version of a file by just checking out the +correct revision first. But sometimes it is more convenient to be +able to view an old version of a single file without checking +anything out; this command does that: + +------------------------------------------------- +$ git show v2.5:fs/locks.c +------------------------------------------------- + +Before the colon may be anything that names a commit, and after it +may be any path to a file tracked by git. + +Examples +-------- + +Check whether two branches point at the same history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you want to check whether two branches point at the same point +in history. + +------------------------------------------------- +$ git diff origin..master +------------------------------------------------- + +will tell you whether the contents of the project are the same at the +two branches; in theory, however, it's possible that the same project +contents could have been arrived at by two different historical +routes. You could compare the object names: + +------------------------------------------------- +$ git rev-list origin +e05db0fd4f31dde7005f075a84f96b360d05984b +$ git rev-list master +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +Or you could recall that the ... operator selects all commits +contained reachable from either one reference or the other but not +both: so + +------------------------------------------------- +$ git log origin...master +------------------------------------------------- + +will return no commits when the two branches are equal. + +Find first tagged version including a given fix +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you know that the commit e05db0fd fixed a certain problem. +You'd like to find the earliest tagged release that contains that +fix. + +Of course, there may be more than one answer--if the history branched +after commit e05db0fd, then there could be multiple "earliest" tagged +releases. + +You could just visually inspect the commits since e05db0fd: + +------------------------------------------------- +$ gitk e05db0fd.. +------------------------------------------------- + +Or you can use gitlink:git-name-rev[1], which will give the commit a +name based on any tag it finds pointing to one of the commit's +descendants: + +------------------------------------------------- +$ git name-rev e05db0fd +e05db0fd tags/v1.5.0-rc1^0~23 +------------------------------------------------- + +The gitlink:git-describe[1] command does the opposite, naming the +revision using a tag on which the given commit is based: + +------------------------------------------------- +$ git describe e05db0fd +v1.5.0-rc0-ge05db0f +------------------------------------------------- + +but that may sometimes help you guess which tags might come after the +given commit. + +If you just want to verify whether a given tagged version contains a +given commit, you could use gitlink:git-merge-base[1]: + +------------------------------------------------- +$ git merge-base e05db0fd v1.5.0-rc1 +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +The merge-base command finds a common ancestor of the given commits, +and always returns one or the other in the case where one is a +descendant of the other; so the above output shows that e05db0fd +actually is an ancestor of v1.5.0-rc1. + +Alternatively, note that + +------------------------------------------------- +$ git log v1.5.0-rc1..e05db0fd +------------------------------------------------- + +will produce empty output if and only if v1.5.0-rc1 includes e05db0fd, +because it outputs only commits that are not reachable from v1.5.0-rc1. + +As yet another alternative, the gitlink:git-show-branch[1] command lists +the commits reachable from its arguments with a display on the left-hand +side that indicates which arguments that commit is reachable from. So, +you can run something like + +------------------------------------------------- +$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 +! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if +available + ! [v1.5.0-rc0] GIT v1.5.0 preview + ! [v1.5.0-rc1] GIT v1.5.0-rc1 + ! [v1.5.0-rc2] GIT v1.5.0-rc2 +... +------------------------------------------------- + +then search for a line that looks like + +------------------------------------------------- ++ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if +available +------------------------------------------------- + +Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and +from v1.5.0-rc2, but not from v1.5.0-rc0. + + +Developing with git +=================== + +Telling git your name +--------------------- + +Before creating any commits, you should introduce yourself to git. The +easiest way to do so is: + +------------------------------------------------ +$ cat >~/.gitconfig <<\EOF +[user] + name = Your Name Comes Here + email = you@yourdomain.example.com +EOF +------------------------------------------------ + +(See the "CONFIGURATION FILE" section of gitlink:git-config[1] for +details on the configuration file.) + + +Creating a new repository +------------------------- + +Creating a new repository from scratch is very easy: + +------------------------------------------------- +$ mkdir project +$ cd project +$ git init +------------------------------------------------- + +If you have some initial content (say, a tarball): + +------------------------------------------------- +$ tar -xzvf project.tar.gz +$ cd project +$ git init +$ git add . # include everything below ./ in the first commit: +$ git commit +------------------------------------------------- + +[[how-to-make-a-commit]] +how to make a commit +-------------------- + +Creating a new commit takes three steps: + + 1. Making some changes to the working directory using your + favorite editor. + 2. Telling git about your changes. + 3. Creating the commit using the content you told git about + in step 2. + +In practice, you can interleave and repeat steps 1 and 2 as many +times as you want: in order to keep track of what you want committed +at step 3, git maintains a snapshot of the tree's contents in a +special staging area called "the index." + +At the beginning, the content of the index will be identical to +that of the HEAD. The command "git diff --cached", which shows +the difference between the HEAD and the index, should therefore +produce no output at that point. + +Modifying the index is easy: + +To update the index with the new contents of a modified file, use + +------------------------------------------------- +$ git add path/to/file +------------------------------------------------- + +To add the contents of a new file to the index, use + +------------------------------------------------- +$ git add path/to/file +------------------------------------------------- + +To remove a file from the index and from the working tree, + +------------------------------------------------- +$ git rm path/to/file +------------------------------------------------- + +After each step you can verify that + +------------------------------------------------- +$ git diff --cached +------------------------------------------------- + +always shows the difference between the HEAD and the index file--this +is what you'd commit if you created the commit now--and that + +------------------------------------------------- +$ git diff +------------------------------------------------- + +shows the difference between the working tree and the index file. + +Note that "git add" always adds just the current contents of a file +to the index; further changes to the same file will be ignored unless +you run git-add on the file again. + +When you're ready, just run + +------------------------------------------------- +$ git commit +------------------------------------------------- + +and git will prompt you for a commit message and then create the new +commit. Check to make sure it looks like what you expected with + +------------------------------------------------- +$ git show +------------------------------------------------- + +As a special shortcut, + +------------------------------------------------- +$ git commit -a +------------------------------------------------- + +will update the index with any files that you've modified or removed +and create a commit, all in one step. + +A number of commands are useful for keeping track of what you're +about to commit: + +------------------------------------------------- +$ git diff --cached # difference between HEAD and the index; what + # would be commited if you ran "commit" now. +$ git diff # difference between the index file and your + # working directory; changes that would not + # be included if you ran "commit" now. +$ git status # a brief per-file summary of the above. +------------------------------------------------- + +creating good 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. + +how to merge +------------ + +You can rejoin two diverging branches of development using +gitlink:git-merge[1]: + +------------------------------------------------- +$ git merge branchname +------------------------------------------------- + +merges the development in the branch "branchname" into the current +branch. If there are conflicts--for example, if the same file is +modified in two different ways in the remote branch and the local +branch--then you are warned; the output may look something like this: + +------------------------------------------------- +$ git pull . next +Trying really trivial in-index merge... +fatal: Merge requires file-level merging +Nope. +Merging HEAD with 77976da35a11db4580b80ae27e8d65caf5208086 +Merging: +15e2162 world +77976da goodbye +found 1 common ancestor(s): +d122ed4 initial +Auto-merging file.txt +CONFLICT (content): Merge conflict in file.txt +Automatic merge failed; fix conflicts and then commit the result. +------------------------------------------------- + +Conflict markers are left in the problematic files, and after +you resolve the conflicts manually, you can update the index +with the contents and run git commit, as you normally would when +creating a new file. + +If you examine the resulting commit using gitk, you will see that it +has two parents, one pointing to the top of the current branch, and +one to the top of the other branch. + +In more detail: + +[[resolving-a-merge]] +Resolving a merge +----------------- + +When a merge isn't resolved automatically, git leaves the index and +the working tree in a special state that gives you all the +information you need to help resolve the merge. + +Files with conflicts are marked specially in the index, so until you +resolve the problem and update the index, git commit will fail: + +------------------------------------------------- +$ git commit +file.txt: needs merge +------------------------------------------------- + +Also, git status will list those files as "unmerged". + +All of the changes that git was able to merge automatically are +already added to the index file, so gitlink:git-diff[1] shows only +the conflicts. Also, it uses a somewhat unusual syntax: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,5 @@@ +++<<<<<<< HEAD:file.txt + +Hello world +++======= ++ Goodbye +++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt +------------------------------------------------- + +Recall that the commit which will be commited after we resolve this +conflict will have two parents instead of the usual one: one parent +will be HEAD, the tip of the current branch; the other will be the +tip of the other branch, which is stored temporarily in MERGE_HEAD. + +The diff above shows the differences between the working-tree version +of file.txt and two previous version: one version from HEAD, and one +from MERGE_HEAD. So instead of preceding each line by a single "+" +or "-", it now uses two columns: the first column is used for +differences between the first parent and the working directory copy, +and the second for differences between the second parent and the +working directory copy. Thus after resolving the conflict in the +obvious way, the diff will look like: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,1 @@@ +- Hello world + -Goodbye +++Goodbye world +------------------------------------------------- + +This shows that our resolved version deleted "Hello world" from the +first parent, deleted "Goodbye" from the second parent, and added +"Goodbye world", which was previously absent from both. + +The gitlink:git-log[1] command also provides special help for merges: + +------------------------------------------------- +$ git log --merge +------------------------------------------------- + +This will list all commits which exist only on HEAD or on MERGE_HEAD, +and which touch an unmerged file. + +We can now add the resolved version to the index and commit: + +------------------------------------------------- +$ git add file.txt +$ git commit +------------------------------------------------- + +Note that the commit message will already be filled in for you with +some information about the merge. Normally you can just use this +default message unchanged, but you may add additional commentary of +your own if desired. + +[[undoing-a-merge]] +undoing a merge +--------------- + +If you get stuck and decide to just give up and throw the whole mess +away, you can always return to the pre-merge state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +Or, if you've already commited the merge that you want to throw away, + +------------------------------------------------- +$ git reset --hard HEAD^ +------------------------------------------------- + +However, this last command can be dangerous in some cases--never +throw away a commit you have already committed if that commit may +itself have been merged into another branch, as doing so may confuse +further merges. + +Fast-forward merges +------------------- + +There is one special case not mentioned above, which is treated +differently. Normally, a merge results in a merge commit, with two +parents, one pointing at each of the two lines of development that +were merged. + +However, if one of the two lines of development is completely +contained within the other--so every commit present in the one is +already contained in the other--then git just performs a +<<fast-forwards,fast forward>>; the head of the current branch is +moved forward to point at the head of the merged-in branch, without +any new commits being created. + +Fixing mistakes +--------------- + +If you've messed up the working tree, but haven't yet committed your +mistake, you can return the entire working tree to the last committed +state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +If you make a commit that you later wish you hadn't, there are two +fundamentally different ways to fix the problem: + + 1. You can create a new commit that undoes whatever was done + by the previous commit. This is the correct thing if your + mistake has already been made public. + + 2. You can go back and modify the old commit. You should + never do this if you have already made the history public; + git does not normally expect the "history" of a project to + change, and cannot correctly perform repeated merges from + a branch that has had its history changed. + +Fixing a mistake with a new commit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Creating a new commit that reverts an earlier change is very easy; +just pass the gitlink:git-revert[1] command a reference to the bad +commit; for example, to revert the most recent commit: + +------------------------------------------------- +$ git revert HEAD +------------------------------------------------- + +This will create a new commit which undoes the change in HEAD. You +will be given a chance to edit the commit message for the new commit. + +You can also revert an earlier change, for example, the next-to-last: + +------------------------------------------------- +$ git revert HEAD^ +------------------------------------------------- + +In this case git will attempt to undo the old change while leaving +intact any changes made since then. If more recent changes overlap +with the changes to be reverted, then you will be asked to fix +conflicts manually, just as in the case of <<resolving-a-merge, +resolving a merge>>. + +Fixing a mistake by editing history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If the problematic commit is the most recent commit, and you have not +yet made that commit public, then you may just +<<undoing-a-merge,destroy it using git-reset>>. + +Alternatively, you +can edit the working directory and update the index to fix your +mistake, just as if you were going to <<how-to-make-a-commit,create a +new commit>>, then run + +------------------------------------------------- +$ git commit --amend +------------------------------------------------- + +which will replace the old commit by a new commit incorporating your +changes, giving you a chance to edit the old commit message first. + +Again, you should never do this to a commit that may already have +been merged into another branch; use gitlink:git-revert[1] instead in +that case. + +It is also possible to edit commits further back in the history, but +this is an advanced topic to be left for +<<cleaning-up-history,another chapter>>. + +Checking out an old version of a file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the process of undoing a previous bad change, you may find it +useful to check out an older version of a particular file using +gitlink:git-checkout[1]. We've used git checkout before to switch +branches, but it has quite different behavior if it is given a path +name: the command + +------------------------------------------------- +$ git checkout HEAD^ path/to/file +------------------------------------------------- + +replaces path/to/file by the contents it had in the commit HEAD^, and +also updates the index to match. It does not change branches. + +If you just want to look at an old version of the file, without +modifying the working directory, you can do that with +gitlink:git-show[1]: + +------------------------------------------------- +$ git show HEAD^ path/to/file +------------------------------------------------- + +which will display the given version of the file. + +Ensuring good performance +------------------------- + +On large repositories, git depends on compression to keep the history +information from taking up to much space on disk or in memory. + +This compression is not performed automatically. Therefore you +should occasionally run gitlink:git-gc[1]: + +------------------------------------------------- +$ git gc +------------------------------------------------- + +to recompress the archive. This can be very time-consuming, so +you may prefer to run git-gc when you are not doing other work. + +Ensuring reliability +-------------------- + +Checking the repository for corruption +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The gitlink:git-fsck[1] command runs a number of self-consistency checks +on the repository, and reports on any problems. This may take some +time. The most common warning by far is about "dangling" objects: + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb +dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f +dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e +dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085 +dangling tree b24c2473f1fd3d91352a624795be026d64c8841f +... +------------------------------------------------- + +Dangling objects are objects that are harmless, but also unnecessary; +you can remove them at any time with gitlink:git-prune[1] or the --prune +option to gitlink:git-gc[1]: + +------------------------------------------------- +$ git gc --prune +------------------------------------------------- + +This may be time-consuming. Unlike most other git operations (including +git-gc when run without any options), it is not safe to prune while +other git operations are in progress in the same repository. + +For more about dangling objects, see <<dangling-objects>>. + + +Recovering lost changes +~~~~~~~~~~~~~~~~~~~~~~~ + +Reflogs +^^^^^^^ + +Say you modify a branch with gitlink:git-reset[1] --hard, and then +realize that the branch was the only reference you had to that point in +history. + +Fortunately, git also keeps a log, called a "reflog", of all the +previous values of each branch. So in this case you can still find the +old history using, for example, + +------------------------------------------------- +$ git log master@{1} +------------------------------------------------- + +This lists the commits reachable from the previous version of the head. +This syntax can be used to with any git command that accepts a commit, +not just with git log. Some other examples: + +------------------------------------------------- +$ git show master@{2} # See where the branch pointed 2, +$ git show master@{3} # 3, ... changes ago. +$ gitk master@{yesterday} # See where it pointed yesterday, +$ gitk master@{"1 week ago"} # ... or last week +------------------------------------------------- + +The reflogs are kept by default for 30 days, after which they may be +pruned. See gitlink:git-reflog[1] and gitlink:git-gc[1] to learn +how to control this pruning, and see the "SPECIFYING REVISIONS" +section of gitlink:git-rev-parse[1] for details. + +Note that the reflog history is very different from normal git history. +While normal history is shared by every repository that works on the +same project, the reflog history is not shared: it tells you only about +how the branches in your local repository have changed over time. + +Examining dangling objects +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In some situations the reflog may not be able to save you. For +example, suppose you delete a branch, then realize you need the history +it pointed you. The reflog is also deleted; however, if you have not +yet pruned the repository, then you may still be able to find +the lost commits; run git-fsck and watch for output that mentions +"dangling commits": + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +... +------------------------------------------------- + +You can examine +one of those dangling commits with, for example, + +------------------------------------------------ +$ gitk 7281251ddd --not --all +------------------------------------------------ + +which does what it sounds like: it says that you want to see the commit +history that is described by the dangling commit(s), but not the +history that is described by all your existing branches and tags. Thus +you get exactly the history reachable from that commit that is lost. +(And notice that it might not be just one commit: we only report the +"tip of the line" as being dangling, but there might be a whole deep +and complex commit history that was gotten dropped.) + +If you decide you want the history back, you can always create a new +reference pointing to it, for example, a new branch: + +------------------------------------------------ +$ git branch recovered-branch 7281251ddd +------------------------------------------------ + + +Sharing development with others +=============================== + +[[getting-updates-with-git-pull]] +Getting updates with git pull +----------------------------- + +After you clone a repository and make a few changes of your own, you +may wish to check the original repository for updates and merge them +into your own work. + +We have already seen <<Updating-a-repository-with-git-fetch,how to +keep remote tracking branches up to date>> with gitlink:git-fetch[1], +and how to merge two branches. So you can merge in changes from the +original repository's master branch with: + +------------------------------------------------- +$ git fetch +$ git merge origin/master +------------------------------------------------- + +However, the gitlink:git-pull[1] command provides a way to do this in +one step: + +------------------------------------------------- +$ git pull origin master +------------------------------------------------- + +In fact, "origin" is normally the default repository to pull from, +and the default branch is normally the HEAD of the remote repository, +so often you can accomplish the above with just + +------------------------------------------------- +$ git pull +------------------------------------------------- + +See the descriptions of the branch.<name>.remote and +branch.<name>.merge options in gitlink:git-config[1] to learn +how to control these defaults depending on the current branch. + +In addition to saving you keystrokes, "git pull" also helps you by +producing a default commit message documenting the branch and +repository that you pulled from. + +(But note that no such commit will be created in the case of a +<<fast-forwards,fast forward>>; instead, your branch will just be +updated to point to the latest commit from the upstream branch). + +The git-pull command can also be given "." as the "remote" repository, +in which case it just merges in a branch from the current repository; so +the commands + +------------------------------------------------- +$ git pull . branch +$ git merge branch +------------------------------------------------- + +are roughly equivalent. The former is actually very commonly used. + +Submitting patches to a project +------------------------------- + +If you just have a few changes, the simplest way to submit them may +just be to send them as patches in email: + +First, use gitlink:git-format-patch[1]; for example: + +------------------------------------------------- +$ git format-patch origin +------------------------------------------------- + +will produce a numbered series of files in the current directory, one +for each patch in the current branch but not in origin/HEAD. + +You can then import these into your mail client and send them by +hand. However, if you have a lot to send at once, you may prefer to +use the gitlink:git-send-email[1] script to automate the process. +Consult the mailing list for your project first to determine how they +prefer such patches be handled. + +Importing patches to a project +------------------------------ + +Git also provides a tool called gitlink:git-am[1] (am stands for +"apply mailbox"), for importing such an emailed series of patches. +Just save all of the patch-containing messages, in order, into a +single mailbox file, say "patches.mbox", then run + +------------------------------------------------- +$ git am -3 patches.mbox +------------------------------------------------- + +Git will apply each patch in order; if any conflicts are found, it +will stop, and you can fix the conflicts as described in +"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells +git to perform a merge; if you would prefer it just to abort and +leave your tree and index untouched, you may omit that option.) + +Once the index is updated with the results of the conflict +resolution, instead of creating a new commit, just run + +------------------------------------------------- +$ git am --resolved +------------------------------------------------- + +and git will create the commit for you and continue applying the +remaining patches from the mailbox. + +The final result will be a series of commits, one for each patch in +the original mailbox, with authorship and commit log message each +taken from the message containing each patch. + +[[setting-up-a-public-repository]] +Setting up a public repository +------------------------------ + +Another way to submit changes to a project is to simply tell the +maintainer of that project to pull from your repository, exactly as +you did in the section "<<getting-updates-with-git-pull, Getting +updates with git pull>>". + +If you and maintainer both have accounts on the same machine, then +then you can just pull changes from each other's repositories +directly; note that all of the command (gitlink:git-clone[1], +git-fetch[1], git-pull[1], etc.) which accept a URL as an argument +will also accept a local file patch; so, for example, you can +use + +------------------------------------------------- +$ git clone /path/to/repository +$ git pull /path/to/other/repository +------------------------------------------------- + +If this sort of setup is inconvenient or impossible, another (more +common) option is to set up a public repository on a public server. +This also allows you to cleanly separate private work in progress +from publicly visible work. + +You will continue to do your day-to-day work in your personal +repository, but periodically "push" changes from your personal +repository into your public repository, allowing other developers to +pull from that repository. So the flow of changes, in a situation +where there is one other developer with a public repository, looks +like this: + + you push + your personal repo ------------------> your public repo + ^ | + | | + | you pull | they pull + | | + | | + | they push V + their public repo <------------------- their repo + +Now, assume your personal repository is in the directory ~/proj. We +first create a new clone of the repository: + +------------------------------------------------- +$ git clone --bare proj-clone.git +------------------------------------------------- + +The resulting directory proj-clone.git will contains a "bare" git +repository--it is just the contents of the ".git" directory, without +a checked-out copy of a working directory. + +Next, copy proj-clone.git to the server where you plan to host the +public repository. You can use scp, rsync, or whatever is most +convenient. + +If somebody else maintains the public server, they may already have +set up a git service for you, and you may skip to the section +"<<pushing-changes-to-a-public-repository,Pushing changes to a public +repository>>", below. + +Otherwise, the following sections explain how to export your newly +created public repository: + +[[exporting-via-http]] +Exporting a git repository via http +----------------------------------- + +The git protocol gives better performance and reliability, but on a +host with a web server set up, http exports may be simpler to set up. + +All you need to do is place the newly created bare git repository in +a directory that is exported by the web server, and make some +adjustments to give web clients some extra information they need: + +------------------------------------------------- +$ mv proj.git /home/you/public_html/proj.git +$ cd proj.git +$ git update-server-info +$ chmod a+x hooks/post-update +------------------------------------------------- + +(For an explanation of the last two lines, see +gitlink:git-update-server-info[1], and the documentation +link:hooks.txt[Hooks used by git].) + +Advertise the url of proj.git. Anybody else should then be able to +clone or pull from that url, for example with a commandline like: + +------------------------------------------------- +$ git clone http://yourserver.com/~you/proj.git +------------------------------------------------- + +(See also +link:howto/setup-git-server-over-http.txt[setup-git-server-over-http] +for a slightly more sophisticated setup using WebDAV which also +allows pushing over http.) + +[[exporting-via-git]] +Exporting a git repository via the git protocol +----------------------------------------------- + +This is the preferred method. + +For now, we refer you to the gitlink:git-daemon[1] man page for +instructions. (See especially the examples section.) + +[[pushing-changes-to-a-public-repository]] +Pushing changes to a public repository +-------------------------------------- + +Note that the two techniques outline above (exporting via +<<exporting-via-http,http>> or <<exporting-via-git,git>>) allow other +maintainers to fetch your latest changes, but they do not allow write +access, which you will need to update the public repository with the +latest changes created in your private repository. + +The simplest way to do this is using gitlink:git-push[1] and ssh; to +update the remote branch named "master" with the latest state of your +branch named "master", run + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master:master +------------------------------------------------- + +or just + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master +------------------------------------------------- + +As with git-fetch, git-push will complain if this does not result in +a <<fast-forwards,fast forward>>. Normally this is a sign of +something wrong. However, if you are sure you know what you're +doing, you may force git-push to perform the update anyway by +proceeding the branch name by a plus sign: + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git +master +------------------------------------------------- + +As with git-fetch, you may also set up configuration options to +save typing; so, for example, after + +------------------------------------------------- +$ cat >.git/config <<EOF +[remote "public-repo"] + url = ssh://yourserver.com/~you/proj.git +EOF +------------------------------------------------- + +you should be able to perform the above push with just + +------------------------------------------------- +$ git push public-repo master +------------------------------------------------- + +See the explanations of the remote.<name>.url, branch.<name>.remote, +and remote.<name>.push options in gitlink:git-config[1] for +details. + +Setting up a shared repository +------------------------------ + +Another way to collaborate is by using a model similar to that +commonly used in CVS, where several developers with special rights +all push to and pull from a single shared repository. See +link:cvs-migration.txt[git for CVS users] for instructions on how to +set this up. + +Allow web browsing of a repository +---------------------------------- + +The gitweb cgi script provides users an easy way to browse your +project's files and history without having to install git; see the file +gitweb/README in the git source tree for instructions on setting it up. + +Examples +-------- + +TODO: topic branches, typical roles as in everyday.txt, ? + + +[[cleaning-up-history]] +Rewriting history and maintaining patch series +============================================== + +Normally commits are only added to a project, never taken away or +replaced. Git is designed with this assumption, and violating it will +cause git's merge machinery (for example) to do the wrong thing. + +However, there is a situation in which it can be useful to violate this +assumption. + +Creating the perfect patch series +--------------------------------- + +Suppose you are a contributor to a large project, and you want to add a +complicated feature, and to present it to the other developers in a way +that makes it easy for them to read your changes, verify that they are +correct, and understand why you made each change. + +If you present all of your changes as a single patch (or commit), they +may find it is too much to digest all at once. + +If you present them with the entire history of your work, complete with +mistakes, corrections, and dead ends, they may be overwhelmed. + +So the ideal is usually to produce a series of patches such that: + + 1. Each patch can be applied in order. + + 2. Each patch includes a single logical change, together with a + message explaining the change. + + 3. No patch introduces a regression: after applying any initial + part of the series, the resulting project still compiles and + works, and has no bugs that it didn't have before. + + 4. The complete series produces the same end result as your own + (probably much messier!) development process did. + +We will introduce some tools that can help you do this, explain how to +use them, and then explain some of the problems that can arise because +you are rewriting history. + +Keeping a patch series up to date using git-rebase +-------------------------------------------------- + +Suppose you have a series of commits in a branch "mywork", which +originally branched off from "origin". + +Suppose you create a branch "mywork" on a remote-tracking branch +"origin", and created some commits on top of it: + +------------------------------------------------- +$ git checkout -b mywork origin +$ vi file.txt +$ git commit +$ vi otherfile.txt +$ git commit +... +------------------------------------------------- + +You have performed no merges into mywork, so it is just a simple linear +sequence of patches on top of "origin": + + + o--o--o <-- origin + \ + o--o--o <-- mywork + +Some more interesting work has been done in the upstream project, and +"origin" has advanced: + + o--o--O--o--o--o <-- origin + \ + a--b--c <-- mywork + +At this point, you could use "pull" to merge your changes back in; +the result would create a new merge commit, like this: + + + o--o--O--o--o--o <-- origin + \ \ + a--b--c--m <-- mywork + +However, if you prefer to keep the history in mywork a simple series of +commits without any merges, you may instead choose to use +gitlink:git-rebase[1]: + +------------------------------------------------- +$ git checkout mywork +$ git rebase origin +------------------------------------------------- + +This will remove each of your commits from mywork, temporarily saving +them as patches (in a directory named ".dotest"), update mywork to +point at the latest version of origin, then apply each of the saved +patches to the new mywork. The result will look like: + + + o--o--O--o--o--o <-- origin + \ + a'--b'--c' <-- mywork + +In the process, it may discover conflicts. In that case it will stop +and allow you to fix the conflicts; after fixing conflicts, use "git +add" to update the index with those contents, and then, instead of +running git-commit, just run + +------------------------------------------------- +$ git rebase --continue +------------------------------------------------- + +and git will continue applying the rest of the patches. + +At any point you may use the --abort option to abort this process and +return mywork to the state it had before you started the rebase: + +------------------------------------------------- +$ git rebase --abort +------------------------------------------------- + +Reordering or selecting from a patch series +------------------------------------------- + +Given one existing commit, the gitlink:git-cherry-pick[1] command +allows you to apply the change introduced by that commit and create a +new commit that records it. So, for example, if "mywork" points to a +series of patches on top of "origin", you might do something like: + +------------------------------------------------- +$ git checkout -b mywork-new origin +$ gitk origin..mywork & +------------------------------------------------- + +And browse through the list of patches in the mywork branch using gitk, +applying them (possibly in a different order) to mywork-new using +cherry-pick, and possibly modifying them as you go using commit +--amend. + +Another technique is to use git-format-patch to create a series of +patches, then reset the state to before the patches: + +------------------------------------------------- +$ git format-patch origin +$ git reset --hard origin +------------------------------------------------- + +Then modify, reorder, or eliminate patches as preferred before applying +them again with gitlink:git-am[1]. + +Other tools +----------- + +There are numerous other tools, such as stgit, which exist for the +purpose of maintaining a patch series. These are out of the scope of +this manual. + +Problems with rewriting history +------------------------------- + +The primary problem with rewriting the history of a branch has to do +with merging. Suppose somebody fetches your branch and merges it into +their branch, with a result something like this: + + o--o--O--o--o--o <-- origin + \ \ + t--t--t--m <-- their branch: + +Then suppose you modify the last three commits: + + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin + +If we examined all this history together in one repository, it will +look like: + + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin + \ \ + t--t--t--m <-- their branch: + +Git has no way of knowing that the new head is an updated version of +the old head; it treats this situation exactly the same as it would if +two developers had independently done the work on the old and new heads +in parallel. At this point, if someone attempts to merge the new head +in to their branch, git will attempt to merge together the two (old and +new) lines of development, instead of trying to replace the old by the +new. The results are likely to be unexpected. + +You may still choose to publish branches whose history is rewritten, +and it may be useful for others to be able to fetch those branches in +order to examine or test them, but they should not attempt to pull such +branches into their own work. + +For true distributed development that supports proper merging, +published branches should never be rewritten. + +Advanced branch management +========================== + +Fetching individual branches +---------------------------- + +Instead of using gitlink:git-remote[1], you can also choose just +to update one branch at a time, and to store it locally under an +arbitrary name: + +------------------------------------------------- +$ git fetch origin todo:my-todo-work +------------------------------------------------- + +The first argument, "origin", just tells git to fetch from the +repository you originally cloned from. The second argument tells git +to fetch the branch named "todo" from the remote repository, and to +store it locally under the name refs/heads/my-todo-work. + +You can also fetch branches from other repositories; so + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:example-master +------------------------------------------------- + +will create a new branch named "example-master" and store in it the +branch named "master" from the repository at the given URL. If you +already have a branch named example-master, it will attempt to +"fast-forward" to the commit given by example.com's master branch. So +next we explain what a fast-forward is: + +[[fast-forwards]] +Understanding git history: fast-forwards +---------------------------------------- + +In the previous example, when updating an existing branch, "git +fetch" checks to make sure that the most recent commit on the remote +branch is a descendant of the most recent commit on your copy of the +branch before updating your copy of the branch to point at the new +commit. Git calls this process a "fast forward". + +A fast forward looks something like this: + + o--o--o--o <-- old head of the branch + \ + o--o--o <-- new head of the branch + + +In some cases it is possible that the new head will *not* actually be +a descendant of the old head. For example, the developer may have +realized she made a serious mistake, and decided to backtrack, +resulting in a situation like: + + o--o--o--o--a--b <-- old head of the branch + \ + o--o--o <-- new head of the branch + + + +In this case, "git fetch" will fail, and print out a warning. + +In that case, you can still force git to update to the new head, as +described in the following section. However, note that in the +situation above this may mean losing the commits labeled "a" and "b", +unless you've already created a reference of your own pointing to +them. + +Forcing git fetch to do non-fast-forward updates +------------------------------------------------ + +If git fetch fails because the new head of a branch is not a +descendant of the old head, you may force the update with: + +------------------------------------------------- +$ git fetch git://example.com/proj.git +master:refs/remotes/example/master +------------------------------------------------- + +Note the addition of the "+" sign. Be aware that commits which the +old version of example/master pointed at may be lost, as we saw in +the previous section. + +Configuring remote branches +--------------------------- + +We saw above that "origin" is just a shortcut to refer to the +repository which you originally cloned from. This information is +stored in git configuration variables, which you can see using +gitlink:git-config[1]: + +------------------------------------------------- +$ git config -l +core.repositoryformatversion=0 +core.filemode=true +core.logallrefupdates=true +remote.origin.url=git://git.kernel.org/pub/scm/git/git.git +remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* +branch.master.remote=origin +branch.master.merge=refs/heads/master +------------------------------------------------- + +If there are other repositories that you also use frequently, you can +create similar configuration options to save typing; for example, +after + +------------------------------------------------- +$ git config remote.example.url git://example.com/proj.git +------------------------------------------------- + +then the following two commands will do the same thing: + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:refs/remotes/example/master +$ git fetch example master:refs/remotes/example/master +------------------------------------------------- + +Even better, if you add one more option: + +------------------------------------------------- +$ git config remote.example.fetch master:refs/remotes/example/master +------------------------------------------------- + +then the following commands will all do the same thing: + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:ref/remotes/example/master +$ git fetch example master:ref/remotes/example/master +$ git fetch example example/master +$ git fetch example +------------------------------------------------- + +You can also add a "+" to force the update each time: + +------------------------------------------------- +$ git config remote.example.fetch +master:ref/remotes/example/master +------------------------------------------------- + +Don't do this unless you're sure you won't mind "git fetch" possibly +throwing away commits on mybranch. + +Also note that all of the above configuration can be performed by +directly editing the file .git/config instead of using +gitlink:git-config[1]. + +See gitlink:git-config[1] for more details on the configuration +options mentioned above. + + +Git internals +============= + +There are two object abstractions: the "object database", and the +"current directory cache" aka "index". + +The Object Database +------------------- + +The object database is literally just a content-addressable collection +of objects. All objects are named by their content, which is +approximated by the SHA1 hash of the object itself. Objects may refer +to other objects (by referencing their SHA1 hash), and so you can +build up a hierarchy of objects. + +All objects have a statically determined "type" aka "tag", which is +determined at object creation time, and which identifies the format of +the object (i.e. how it is used, and how it can refer to other +objects). There are currently four different object types: "blob", +"tree", "commit" and "tag". + +A "blob" object cannot refer to any other object, and is, like the type +implies, a pure storage object containing some user data. It is used to +actually store the file data, i.e. a blob object is associated with some +particular version of some file. + +A "tree" object is an object that ties one or more "blob" objects into a +directory structure. In addition, a tree object can refer to other tree +objects, thus creating a directory hierarchy. + +A "commit" object ties such directory hierarchies together into +a DAG of revisions - each "commit" is associated with exactly one tree +(the directory hierarchy at the time of the commit). In addition, a +"commit" refers to one or more "parent" commit objects that describe the +history of how we arrived at that directory hierarchy. + +As a special case, a commit object with no parents is called the "root" +object, and is the point of an initial project commit. Each project +must have at least one root, and while you can tie several different +root objects together into one project by creating a commit object which +has two or more separate roots as its ultimate parents, that's probably +just going to confuse people. So aim for the notion of "one root object +per project", even if git itself does not enforce that. + +A "tag" object symbolically identifies and can be used to sign other +objects. It contains the identifier and type of another object, a +symbolic name (of course!) and, optionally, a signature. + +Regardless of object type, all objects share the following +characteristics: they are all deflated with zlib, and have a header +that not only specifies their type, but also provides size information +about the data in the object. It's worth noting that the SHA1 hash +that is used to name the object is the hash of the original data +plus this header, so `sha1sum` 'file' does not match the object name +for 'file'. +(Historical note: in the dawn of the age of git the hash +was the sha1 of the 'compressed' object.) + +As a result, the general consistency of an object can always be tested +independently of the contents or the type of the object: all objects can +be validated by verifying that (a) their hashes match the content of the +file and (b) the object successfully inflates to a stream of bytes that +forms a sequence of <ascii type without space> + <space> + <ascii decimal +size> + <byte\0> + <binary object data>. + +The structured objects can further have their structure and +connectivity to other objects verified. This is generally done with +the `git-fsck` program, which generates a full dependency graph +of all objects, and verifies their internal consistency (in addition +to just verifying their superficial consistency through the hash). + +The object types in some more detail: + +Blob Object +----------- + +A "blob" object is nothing but a binary blob of data, and doesn't +refer to anything else. There is no signature or any other +verification of the data, so while the object is consistent (it 'is' +indexed by its sha1 hash, so the data itself is certainly correct), it +has absolutely no other attributes. No name associations, no +permissions. It is purely a blob of data (i.e. normally "file +contents"). + +In particular, since the blob is entirely defined by its data, if two +files in a directory tree (or in multiple different versions of the +repository) have the same contents, they will share the same blob +object. The object is totally independent of its location in the +directory tree, and renaming a file does not change the object that +file is associated with in any way. + +A blob is typically created when gitlink:git-update-index[1] +is run, and its data can be accessed by gitlink:git-cat-file[1]. + +Tree Object +----------- + +The next hierarchical object type is the "tree" object. A tree object +is a list of mode/name/blob data, sorted by name. Alternatively, the +mode data may specify a directory mode, in which case instead of +naming a blob, that name is associated with another TREE object. + +Like the "blob" object, a tree object is uniquely determined by the +set contents, and so two separate but identical trees will always +share the exact same object. This is true at all levels, i.e. it's +true for a "leaf" tree (which does not refer to any other trees, only +blobs) as well as for a whole subdirectory. + +For that reason a "tree" object is just a pure data abstraction: it +has no history, no signatures, no verification of validity, except +that since the contents are again protected by the hash itself, we can +trust that the tree is immutable and its contents never change. + +So you can trust the contents of a tree to be valid, the same way you +can trust the contents of a blob, but you don't know where those +contents 'came' from. + +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, +and your diff will look right. In other words, you can effectively +(and efficiently) tell the difference between any two random trees by +O(n) where "n" is the size of the difference, rather than the size of +the tree. + +Side note 2 on trees: since the name of a "blob" depends entirely and +exclusively on its contents (i.e. there are no names or permissions +involved), you can see trivial renames or permission changes by +noticing that the blob stayed the same. However, renames with data +changes need a smarter "diff" implementation. + +A tree is created with gitlink:git-write-tree[1] and +its data can be accessed by gitlink:git-ls-tree[1]. +Two trees can be compared with gitlink:git-diff-tree[1]. + +Commit Object +------------- + +The "commit" object is an object that introduces the notion of +history into the picture. In contrast to the other objects, it +doesn't just describe the physical state of a tree, it describes how +we got there, and why. + +A "commit" is defined by the tree-object that it results in, the +parent commits (zero, one or more) that led up to that point, and a +comment on what happened. Again, a commit is not trusted per se: +the contents are well-defined and "safe" due to the cryptographically +strong signatures at all levels, but there is no reason to believe +that the tree is "good" or that the merge information makes sense. +The parents do not have to actually have any relationship with the +result, for example. + +Note on commits: unlike real SCM's, commits do not contain +rename information or file mode change information. All of that is +implicit in the trees involved (the result tree, and the result trees +of the parents), and describing that makes no sense in this idiotic +file manager. + +A commit is created with gitlink:git-commit-tree[1] and +its data can be accessed by gitlink:git-cat-file[1]. + +Trust +----- + +An aside on the notion of "trust". Trust is really outside the scope +of "git", but it's worth noting a few things. First off, since +everything is hashed with SHA1, you 'can' trust that an object is +intact and has not been messed with by external sources. So the name +of an object uniquely identifies a known state - just not a state that +you may want to trust. + +Furthermore, since the SHA1 signature of a commit refers to the +SHA1 signatures of the tree it is associated with and the signatures +of the parent, a single named commit specifies uniquely a whole set +of history, with full contents. You can't later fake any step of the +way once you have the name of a commit. + +So to introduce some real trust in the system, the only thing you need +to do is to digitally sign just 'one' special note, which includes the +name of a top-level commit. Your digital signature shows others +that you trust that commit, and the immutability of the history of +commits tells others that they can trust the whole history. + +In other words, you can easily validate a whole archive by just +sending out a single email that tells the people the name (SHA1 hash) +of the top commit, and digitally sign that email using something +like GPG/PGP. + +To assist in this, git also provides the tag object... + +Tag Object +---------- + +Git provides the "tag" object to simplify creating, managing and +exchanging symbolic and signed tokens. The "tag" object at its +simplest simply symbolically identifies another object by containing +the sha1, type and symbolic name. + +However it can optionally contain additional signature information +(which git doesn't care about as long as there's less than 8k of +it). This can then be verified externally to git. + +Note that despite the tag features, "git" itself only handles content +integrity; the trust framework (and signature provision and +verification) has to come from outside. + +A tag is created with gitlink:git-mktag[1], +its data can be accessed by gitlink:git-cat-file[1], +and the signature can be verified by +gitlink:git-verify-tag[1]. + + +The "index" aka "Current Directory Cache" +----------------------------------------- + +The index is a simple binary file, which contains an efficient +representation of a virtual directory content at some random time. It +does so by a simple array that associates a set of names, dates, +permissions and content (aka "blob") objects together. The cache is +always kept ordered by name, and names are unique (with a few very +specific rules) at any point in time, but the cache has no long-term +meaning, and can be partially updated at any time. + +In particular, the index certainly does not need to be consistent with +the current directory contents (in fact, most operations will depend on +different ways to make the index 'not' be consistent with the directory +hierarchy), but it has three very important attributes: + +'(a) it can re-generate the full state it caches (not just the +directory structure: it contains pointers to the "blob" objects so +that it can regenerate the data too)' + +As a special case, there is a clear and unambiguous one-way mapping +from a current directory cache to a "tree object", which can be +efficiently created from just the current directory cache without +actually looking at any other data. So a directory cache at any one +time uniquely specifies one and only one "tree" object (but has +additional data to make it easy to match up that tree object with what +has happened in the directory) + +'(b) it has efficient methods for finding inconsistencies between that +cached state ("tree object waiting to be instantiated") and the +current state.' + +'(c) it can additionally efficiently represent information about merge +conflicts between different tree objects, allowing each pathname to be +associated with sufficient information about the trees involved that +you can create a three-way merge between them.' + +Those are the three ONLY things that the directory cache does. It's a +cache, and the normal operation is to re-generate it completely from a +known tree object, or update/compare it with a live tree that is being +developed. If you blow the directory cache away entirely, you generally +haven't lost any information as long as you have the name of the tree +that it described. + +At the same time, the index is at the same time also the +staging area for creating new trees, and creating a new tree always +involves a controlled modification of the index file. In particular, +the index file can have the representation of an intermediate tree that +has not yet been instantiated. So the index can be thought of as a +write-back cache, which can contain dirty information that has not yet +been written back to the backing store. + + + +The Workflow +------------ + +Generally, all "git" operations work on the index file. Some operations +work *purely* on the index file (showing the current state of the +index), but most operations move data to and from the index file. Either +from the database or from the working directory. Thus there are four +main combinations: + +working directory -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update the index with information from the working directory with +the gitlink:git-update-index[1] command. You +generally update the index information by just specifying the filename +you want to update, like so: + +------------------------------------------------- +$ git-update-index filename +------------------------------------------------- + +but to avoid common mistakes with filename globbing etc, the command +will not normally add totally new entries or remove old entries, +i.e. it will normally just update existing cache entries. + +To tell git that yes, you really do realize that certain files no +longer exist, or that new files should be added, you +should use the `--remove` and `--add` flags respectively. + +NOTE! A `--remove` flag does 'not' mean that subsequent filenames will +necessarily be removed: if the files still exist in your directory +structure, the index will be updated with their new status, not +removed. The only thing `--remove` means is that update-cache will be +considering a removed file to be a valid thing, and if the file really +does not exist any more, it will update the index accordingly. + +As a special case, you can also do `git-update-index --refresh`, which +will refresh the "stat" information of each index to match the current +stat information. It will 'not' update the object status itself, and +it will only update the fields that are used to quickly test whether +an object still matches its old backing store object. + +index -> object database +~~~~~~~~~~~~~~~~~~~~~~~~ + +You write your current index file to a "tree" object with the program + +------------------------------------------------- +$ git-write-tree +------------------------------------------------- + +that doesn't come with any options - it will just write out the +current index into the set of tree objects that describe that state, +and it will return the name of the resulting top-level tree. You can +use that tree to re-generate the index at any time by going in the +other direction: + +object database -> index +~~~~~~~~~~~~~~~~~~~~~~~~ + +You read a "tree" file from the object database, and use that to +populate (and overwrite - don't do this if your index contains any +unsaved state that you might want to restore later!) your current +index. Normal operation is just + +------------------------------------------------- +$ git-read-tree <sha1 of tree> +------------------------------------------------- + +and your index file will now be equivalent to the tree that you saved +earlier. However, that is only your 'index' file: your working +directory contents have not been modified. + +index -> working directory +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update your working directory from the index by "checking out" +files. This is not a very common operation, since normally you'd just +keep your files updated, and rather than write to your working +directory, you'd tell the index files about the changes in your +working directory (i.e. `git-update-index`). + +However, if you decide to jump to a new version, or check out somebody +else's version, or just restore a previous tree, you'd populate your +index file with read-tree, and then you need to check out the result +with + +------------------------------------------------- +$ git-checkout-index filename +------------------------------------------------- + +or, if you want to check out all of the index, use `-a`. + +NOTE! git-checkout-index normally refuses to overwrite old files, so +if you have an old version of the tree already checked out, you will +need to use the "-f" flag ('before' the "-a" flag or the filename) to +'force' the checkout. + + +Finally, there are a few odds and ends which are not purely moving +from one representation to the other: + +Tying it all together +~~~~~~~~~~~~~~~~~~~~~ + +To commit a tree you have instantiated with "git-write-tree", you'd +create a "commit" object that refers to that tree and the history +behind it - most notably the "parent" commits that preceded it in +history. + +Normally a "commit" has one parent: the previous state of the tree +before a certain change was made. However, sometimes it can have two +or more parent commits, in which case we call it a "merge", due to the +fact that such a commit brings together ("merges") two or more +previous states represented by other commits. + +In other words, while a "tree" represents a particular directory state +of a working directory, a "commit" represents that state in "time", +and explains how we got there. + +You create a commit object by giving it the tree that describes the +state at the time of the commit, and a list of parents: + +------------------------------------------------- +$ git-commit-tree <tree> -p <parent> [-p <parent2> ..] +------------------------------------------------- + +and then giving the reason for the commit on stdin (either through +redirection from a pipe or file, or by just typing it at the tty). + +git-commit-tree will return the name of the object that represents +that commit, and you should save it away for later use. Normally, +you'd commit a new `HEAD` state, and while git doesn't care where you +save the note about that state, in practice we tend to just write the +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + + +Examining the data +------------------ + +You can examine the data represented in the object database and the +index with various helper tools. For every object, you can use +gitlink:git-cat-file[1] to examine details about the +object: + +------------------------------------------------- +$ git-cat-file -t <objectname> +------------------------------------------------- + +shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use + +------------------------------------------------- +$ git-cat-file blob|tree|commit|tag <objectname> +------------------------------------------------- + +to show its contents. NOTE! Trees have binary content, and as a result +there is a special helper for showing that content, called +`git-ls-tree`, which turns the binary content into a more easily +readable form. + +It's especially instructive to look at "commit" objects, since those +tend to be small and fairly self-explanatory. In particular, if you +follow the convention of having the top commit name in `.git/HEAD`, +you can do + +------------------------------------------------- +$ git-cat-file commit HEAD +------------------------------------------------- + +to see what the top commit was. + +Merging multiple trees +---------------------- + +Git helps you do a three-way merge, which you can expand to n-way by +repeating the merge procedure arbitrary times until you finally +"commit" the state. The normal situation is that you'd only do one +three-way merge (two parents), and commit it, but if you like to, you +can do multiple parents in one go. + +To do a three-way merge, you need the two sets of "commit" objects +that you want to merge, use those to find the closest common parent (a +third "commit" object), and then use those commit objects to find the +state of the directory ("tree" object) at these points. + +To get the "base" for the merge, you first look up the common parent +of two commits with + +------------------------------------------------- +$ git-merge-base <commit1> <commit2> +------------------------------------------------- + +which will return you the commit they are both based on. You should +now look up the "tree" objects of those commits, which you can easily +do with (for example) + +------------------------------------------------- +$ git-cat-file commit <commitname> | head -1 +------------------------------------------------- + +since the tree object information is always the first line in a commit +object. + +Once you know the three trees you are going to merge (the one "original" +tree, aka the common case, and the two "result" trees, aka the branches +you want to merge), you do a "merge" read into the index. This will +complain if it has to throw away your old index contents, so you should +make sure that you've committed those - in fact you would normally +always do a merge against your last commit (which should thus match what +you have in your current index anyway). + +To do the merge, do + +------------------------------------------------- +$ git-read-tree -m -u <origtree> <yourtree> <targettree> +------------------------------------------------- + +which will do all trivial merge operations for you directly in the +index file, and you can just write the result out with +`git-write-tree`. + + +Merging multiple trees, continued +--------------------------------- + +Sadly, many merges aren't trivial. If there are files that have +been added.moved or removed, or if both branches have modified the +same file, you will be left with an index tree that contains "merge +entries" in it. Such an index tree can 'NOT' be written out to a tree +object, and you will have to resolve any such merge clashes using +other tools before you can write out the result. + +You can examine such index state with `git-ls-files --unmerged` +command. An example: + +------------------------------------------------ +$ git-read-tree -m $orig HEAD $target +$ git-ls-files --unmerged +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c +------------------------------------------------ + +Each line of the `git-ls-files --unmerged` output begins with +the blob mode bits, blob SHA1, 'stage number', and the +filename. The 'stage number' is git's way to say which tree it +came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` +tree, and stage3 `$target` tree. + +Earlier we said that trivial merges are done inside +`git-read-tree -m`. For example, if the file did not change +from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` and `$orig` to `$target` the same way, +obviously the final outcome is what is in `HEAD`. What the +above example shows is that file `hello.c` was changed from +`$orig` to `HEAD` and `$orig` to `$target` in a different way. +You could resolve this by running your favorite 3-way merge +program, e.g. `diff3` or `merge`, on the blob objects from +these three stages yourself, like this: + +------------------------------------------------ +$ git-cat-file blob 263414f... >hello.c~1 +$ git-cat-file blob 06fa6a2... >hello.c~2 +$ git-cat-file blob cc44c73... >hello.c~3 +$ merge hello.c~2 hello.c~1 hello.c~3 +------------------------------------------------ + +This would leave the merge result in `hello.c~2` file, along +with conflict markers if there are conflicts. After verifying +the merge result makes sense, you can tell git what the final +merge result for this file is by: + +------------------------------------------------- +$ mv -f hello.c~2 hello.c +$ git-update-index hello.c +------------------------------------------------- + +When a path is in unmerged state, running `git-update-index` for +that path tells git to mark the path resolved. + +The above is the description of a git merge at the lowest level, +to help you understand what conceptually happens under the hood. +In practice, nobody, not even git itself, uses three `git-cat-file` +for this. There is `git-merge-index` program that extracts the +stages to temporary files and calls a "merge" script on it: + +------------------------------------------------- +$ git-merge-index git-merge-one-file hello.c +------------------------------------------------- + +and that is what higher level `git merge -s resolve` is implemented with. + +How git stores objects efficiently: pack files +---------------------------------------------- + +We've seen how git stores each object in a file named after the +object's SHA1 hash. + +Unfortunately this system becomes inefficient once a project has a +lot of objects. Try this on an old project: + +------------------------------------------------ +$ git count-objects +6930 objects, 47620 kilobytes +------------------------------------------------ + +The first number is the number of objects which are kept in +individual files. The second is the amount of space taken up by +those "loose" objects. + +You can save space and make git faster by moving these loose objects in +to a "pack file", which stores a group of objects in an efficient +compressed format; the details of how pack files are formatted can be +found in link:technical/pack-format.txt[technical/pack-format.txt]. + +To put the loose objects into a pack, just run git repack: + +------------------------------------------------ +$ git repack +Generating pack... +Done counting 6020 objects. +Deltifying 6020 objects. + 100% (6020/6020) done +Writing 6020 objects. + 100% (6020/6020) done +Total 6020, written 6020 (delta 4070), reused 0 (delta 0) +Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created. +------------------------------------------------ + +You can then run + +------------------------------------------------ +$ git prune +------------------------------------------------ + +to remove any of the "loose" objects that are now contained in the +pack. This will also remove any unreferenced objects (which may be +created when, for example, you use "git reset" to remove a commit). +You can verify that the loose objects are gone by looking at the +.git/objects directory or by running + +------------------------------------------------ +$ git count-objects +0 objects, 0 kilobytes +------------------------------------------------ + +Although the object files are gone, any commands that refer to those +objects will work exactly as they did before. + +The gitlink:git-gc[1] command performs packing, pruning, and more for +you, so is normally the only high-level command you need. + +[[dangling-objects]] +Dangling objects +---------------- + +The gitlink:git-fsck[1] command will sometimes complain about dangling +objects. They are not a problem. + +The most common cause of dangling objects is that you've rebased a +branch, or you have pulled from somebody else who rebased a branch--see +<<cleaning-up-history>>. In that case, the old head of the original +branch still exists, as does obviously everything it pointed to. The +branch pointer itself just doesn't, since you replaced it with another +one. + +There are also other situations too that cause dangling objects. For +example, a "dangling blob" may arise because you did a "git add" of a +file, but then, before you actually committed it and made it part of the +bigger picture, you changed something else in that file and committed +that *updated* thing - the old state that you added originally ends up +not being pointed to by any commit or tree, so it's now a dangling blob +object. + +Similarly, when the "recursive" merge strategy runs, and finds that +there are criss-cross merges and thus more than one merge base (which is +fairly unusual, but it does happen), it will generate one temporary +midway tree (or possibly even more, if you had lots of criss-crossing +merges and more than two merge bases) as a temporary internal merge +base, and again, those are real objects, but the end result will not end +up pointing to them, so they end up "dangling" in your repository. + +Generally, dangling objects aren't anything to worry about. They can +even be very useful: if you screw something up, the dangling objects can +be how you recover your old tree (say, you did a rebase, and realized +that you really didn't want to - you can look at what dangling objects +you have, and decide to reset your head to some old dangling state). + +For commits, the most useful thing to do with dangling objects tends to +be to do a simple + +------------------------------------------------ +$ gitk <dangling-commit-sha-goes-here> --not --all +------------------------------------------------ + +For blobs and trees, you can't do the same, but you can examine them. +You can just do + +------------------------------------------------ +$ git show <dangling-blob/tree-sha-goes-here> +------------------------------------------------ + +to show what the contents of the blob were (or, for a tree, basically +what the "ls" for that directory was), and that may give you some idea +of what the operation was that left that dangling object. + +Usually, dangling blobs and trees aren't very interesting. They're +almost always the result of either being a half-way mergebase (the blob +will often even have the conflict markers from a merge in it, if you +have had conflicting merges that you fixed up by hand), or simply +because you interrupted a "git fetch" with ^C or something like that, +leaving _some_ of the new objects in the object database, but just +dangling and useless. + +Anyway, once you are sure that you're not interested in any dangling +state, you can just prune all unreachable objects: + +------------------------------------------------ +$ git prune +------------------------------------------------ + +and they'll be gone. But you should only run "git prune" on a quiescent +repository - it's kind of like doing a filesystem fsck recovery: you +don't want to do that while the filesystem is mounted. + +(The same is true of "git-fsck" itself, btw - but since +git-fsck never actually *changes* the repository, it just reports +on what it found, git-fsck itself is never "dangerous" to run. +Running it while somebody is actually changing the repository can cause +confusing and scary messages, but it won't actually do anything bad. In +contrast, running "git prune" while somebody is actively changing the +repository is a *BAD* idea). + +Glossary of git terms +===================== + +include::glossary.txt[] + +Notes and todo list for this manual +=================================== + +This is a work in progress. + +The basic requirements: + - It must be readable in order, from beginning to end, by + someone intelligent with a basic grasp of the unix + commandline, but without any special knowledge of git. If + necessary, any other prerequisites should be specifically + mentioned as they arise. + - Whenever possible, section headings should clearly describe + the task they explain how to do, in language that requires + no more knowledge than necessary: for example, "importing + patches into a project" rather than "the git-am command" + +Think about how to create a clear chapter dependency graph that will +allow people to get to important topics without necessarily reading +everything in between. + +Say something about .gitignore. + +Scan Documentation/ for other stuff left out; in particular: + howto's + some of technical/? + hooks + list of commands in gitlink:git[1] + +Scan email archives for other stuff left out + +Scan man pages to see if any assume more background than this manual +provides. + +Simplify beginning by suggesting disconnected head instead of +temporary branch creation? + +Explain how to refer to file stages in the "how to resolve a merge" +section: diff -1, -2, -3, --ours, --theirs :1:/path notation. The +"git ls-files --unmerged --stage" thing is sorta useful too, +actually. And note gitk --merge. + +Add more good examples. Entire sections of just cookbook examples +might be a good idea; maybe make an "advanced examples" section a +standard end-of-chapter section? + +Include cross-references to the glossary, where appropriate. + +Document shallow clones? See draft 1.5.0 release notes for some +documentation. + +Add a section on working with other version control systems, including +CVS, Subversion, and just imports of series of release tarballs. + +More details on gitweb? + +Write a chapter on using plumbing and writing scripts. |