From 26c1eea63bdb46be61381417ee7486b18d28fa33 Mon Sep 17 00:00:00 2001 From: Sven Strickroth Date: Fri, 4 Jan 2013 20:29:01 +0100 Subject: [PATCH] Updated git_doc to git 1.8 Signed-off-by: Sven Strickroth --- doc/readme.txt | 5 +- doc/source/en/TortoiseGit/git_doc.patch | 97 ++- doc/source/en/TortoiseGit/git_doc/everyday.xml | 240 +++--- doc/source/en/TortoiseGit/git_doc/git-add.xml | 30 +- doc/source/en/TortoiseGit/git_doc/git-am.xml | 27 +- doc/source/en/TortoiseGit/git_doc/git-annotate.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-apply.xml | 44 +- .../en/TortoiseGit/git_doc/git-archimport.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-archive.xml | 30 +- doc/source/en/TortoiseGit/git_doc/git-bisect.xml | 40 +- doc/source/en/TortoiseGit/git_doc/git-blame.xml | 35 +- doc/source/en/TortoiseGit/git_doc/git-branch.xml | 103 ++- doc/source/en/TortoiseGit/git_doc/git-bundle.xml | 22 +- doc/source/en/TortoiseGit/git_doc/git-cat-file.xml | 20 +- .../en/TortoiseGit/git_doc/git-check-attr.xml | 24 +- .../TortoiseGit/git_doc/git-check-ref-format.xml | 20 +- .../en/TortoiseGit/git_doc/git-checkout-index.xml | 22 +- doc/source/en/TortoiseGit/git_doc/git-checkout.xml | 118 ++- .../en/TortoiseGit/git_doc/git-cherry-pick.xml | 106 ++- doc/source/en/TortoiseGit/git_doc/git-cherry.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-citool.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-clean.xml | 22 +- doc/source/en/TortoiseGit/git_doc/git-clone.xml | 67 +- doc/source/en/TortoiseGit/git_doc/git-column.xml | 112 +++ .../en/TortoiseGit/git_doc/git-commit-tree.xml | 65 +- doc/source/en/TortoiseGit/git_doc/git-commit.xml | 116 ++- doc/source/en/TortoiseGit/git_doc/git-config.xml | 373 +++++++-- .../en/TortoiseGit/git_doc/git-count-objects.xml | 18 +- .../git_doc/git-credential-cache--daemon.xml | 18 +- .../TortoiseGit/git_doc/git-credential-cache.xml | 24 +- .../TortoiseGit/git_doc/git-credential-store.xml | 24 +- .../en/TortoiseGit/git_doc/git-credential.xml | 196 +++++ .../en/TortoiseGit/git_doc/git-cvsexportcommit.xml | 22 +- .../en/TortoiseGit/git_doc/git-cvsimport.xml | 32 +- .../en/TortoiseGit/git_doc/git-cvsserver.xml | 44 +- doc/source/en/TortoiseGit/git_doc/git-daemon.xml | 48 +- doc/source/en/TortoiseGit/git_doc/git-describe.xml | 26 +- .../en/TortoiseGit/git_doc/git-diff-files.xml | 39 +- .../en/TortoiseGit/git_doc/git-diff-index.xml | 45 +- .../en/TortoiseGit/git_doc/git-diff-tree.xml | 69 +- doc/source/en/TortoiseGit/git_doc/git-diff.xml | 114 +-- doc/source/en/TortoiseGit/git_doc/git-difftool.xml | 71 +- doc/source/en/TortoiseGit/git_doc/git-doc.xml | 2 +- .../en/TortoiseGit/git_doc/git-fast-export.xml | 22 +- .../en/TortoiseGit/git_doc/git-fast-import.xml | 183 +++-- .../en/TortoiseGit/git_doc/git-fetch-pack.xml | 23 +- doc/source/en/TortoiseGit/git_doc/git-fetch.xml | 65 +- .../en/TortoiseGit/git_doc/git-filter-branch.xml | 49 +- .../en/TortoiseGit/git_doc/git-fmt-merge-msg.xml | 22 +- .../en/TortoiseGit/git_doc/git-for-each-ref.xml | 33 +- .../en/TortoiseGit/git_doc/git-format-patch.xml | 80 +- .../en/TortoiseGit/git_doc/git-fsck-objects.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-fsck.xml | 28 +- doc/source/en/TortoiseGit/git_doc/git-gc.xml | 26 +- .../TortoiseGit/git_doc/git-get-tar-commit-id.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-grep.xml | 43 +- doc/source/en/TortoiseGit/git_doc/git-gui.xml | 24 +- .../en/TortoiseGit/git_doc/git-hash-object.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-help.xml | 34 +- .../en/TortoiseGit/git_doc/git-http-backend.xml | 28 +- .../en/TortoiseGit/git_doc/git-http-fetch.xml | 18 +- .../en/TortoiseGit/git_doc/git-http-push.xml | 20 +- .../en/TortoiseGit/git_doc/git-imap-send.xml | 28 +- .../en/TortoiseGit/git_doc/git-index-pack.xml | 37 +- doc/source/en/TortoiseGit/git_doc/git-init-db.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-init.xml | 30 +- doc/source/en/TortoiseGit/git_doc/git-instaweb.xml | 22 +- doc/source/en/TortoiseGit/git_doc/git-log.xml | 200 +++-- .../en/TortoiseGit/git_doc/git-lost-found.xml | 23 +- doc/source/en/TortoiseGit/git_doc/git-ls-files.xml | 24 +- .../en/TortoiseGit/git_doc/git-ls-remote.xml | 32 +- doc/source/en/TortoiseGit/git_doc/git-ls-tree.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-mailinfo.xml | 18 +- .../en/TortoiseGit/git_doc/git-mailsplit.xml | 18 +- .../en/TortoiseGit/git_doc/git-merge-base.xml | 52 +- .../en/TortoiseGit/git_doc/git-merge-file.xml | 20 +- .../en/TortoiseGit/git_doc/git-merge-index.xml | 18 +- .../en/TortoiseGit/git_doc/git-merge-one-file.xml | 16 +- .../en/TortoiseGit/git_doc/git-merge-tree.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-merge.xml | 47 +- .../en/TortoiseGit/git_doc/git-mergetool--lib.xml | 18 +- .../en/TortoiseGit/git_doc/git-mergetool.xml | 36 +- doc/source/en/TortoiseGit/git_doc/git-mktag.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-mktree.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-mv.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-name-rev.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-notes.xml | 37 +- doc/source/en/TortoiseGit/git_doc/git-p4.xml | 254 +++++-- .../en/TortoiseGit/git_doc/git-pack-objects.xml | 20 +- .../en/TortoiseGit/git_doc/git-pack-redundant.xml | 20 +- .../en/TortoiseGit/git_doc/git-pack-refs.xml | 34 +- .../en/TortoiseGit/git_doc/git-parse-remote.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-patch-id.xml | 18 +- .../en/TortoiseGit/git_doc/git-peek-remote.xml | 18 +- .../en/TortoiseGit/git_doc/git-prune-packed.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-prune.xml | 24 +- doc/source/en/TortoiseGit/git_doc/git-pull.xml | 66 +- doc/source/en/TortoiseGit/git_doc/git-push.xml | 94 ++- .../en/TortoiseGit/git_doc/git-quiltimport.xml | 18 +- .../en/TortoiseGit/git_doc/git-read-tree.xml | 30 +- doc/source/en/TortoiseGit/git_doc/git-rebase.xml | 113 ++- .../en/TortoiseGit/git_doc/git-receive-pack.xml | 28 +- doc/source/en/TortoiseGit/git_doc/git-reflog.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-relink.xml | 18 +- .../en/TortoiseGit/git_doc/git-remote-ext.xml | 24 +- .../en/TortoiseGit/git_doc/git-remote-fd.xml | 22 +- .../en/TortoiseGit/git_doc/git-remote-helpers.xml | 341 +++++---- .../en/TortoiseGit/git_doc/git-remote-testgit.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-remote.xml | 31 +- doc/source/en/TortoiseGit/git_doc/git-repack.xml | 22 +- doc/source/en/TortoiseGit/git_doc/git-replace.xml | 27 +- .../en/TortoiseGit/git_doc/git-repo-config.xml | 16 +- .../en/TortoiseGit/git_doc/git-request-pull.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-rerere.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-reset.xml | 134 ++-- doc/source/en/TortoiseGit/git_doc/git-rev-list.xml | 154 +++- .../en/TortoiseGit/git_doc/git-rev-parse.xml | 146 +++- doc/source/en/TortoiseGit/git_doc/git-revert.xml | 24 +- doc/source/en/TortoiseGit/git_doc/git-rm.xml | 46 +- .../en/TortoiseGit/git_doc/git-send-email.xml | 45 +- .../en/TortoiseGit/git_doc/git-send-pack.xml | 20 +- .../TortoiseGit/git_doc/git-sh-i18n--envsubst.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-sh-i18n.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-sh-setup.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git-shell.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-shortlog.xml | 25 +- .../en/TortoiseGit/git_doc/git-show-branch.xml | 22 +- .../en/TortoiseGit/git_doc/git-show-index.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-show-ref.xml | 26 +- doc/source/en/TortoiseGit/git_doc/git-show.xml | 50 +- doc/source/en/TortoiseGit/git_doc/git-stage.xml | 16 +- doc/source/en/TortoiseGit/git_doc/git-stash.xml | 26 +- doc/source/en/TortoiseGit/git_doc/git-status.xml | 54 +- .../en/TortoiseGit/git_doc/git-stripspace.xml | 20 +- .../en/TortoiseGit/git_doc/git-submodule.xml | 47 +- doc/source/en/TortoiseGit/git_doc/git-svn.xml | 177 +++-- .../en/TortoiseGit/git_doc/git-symbolic-ref.xml | 40 +- doc/source/en/TortoiseGit/git_doc/git-tag.xml | 56 +- doc/source/en/TortoiseGit/git_doc/git-tar-tree.xml | 22 +- .../en/TortoiseGit/git_doc/git-unpack-file.xml | 18 +- .../en/TortoiseGit/git_doc/git-unpack-objects.xml | 18 +- .../en/TortoiseGit/git_doc/git-update-index.xml | 83 +- .../en/TortoiseGit/git_doc/git-update-ref.xml | 18 +- .../TortoiseGit/git_doc/git-update-server-info.xml | 20 +- .../en/TortoiseGit/git_doc/git-upload-archive.xml | 18 +- .../en/TortoiseGit/git_doc/git-upload-pack.xml | 20 +- doc/source/en/TortoiseGit/git_doc/git-var.xml | 65 +- .../en/TortoiseGit/git_doc/git-verify-pack.xml | 20 +- .../en/TortoiseGit/git_doc/git-verify-tag.xml | 18 +- .../en/TortoiseGit/git_doc/git-web--browse.xml | 30 +- .../en/TortoiseGit/git_doc/git-whatchanged.xml | 48 +- .../en/TortoiseGit/git_doc/git-write-tree.xml | 18 +- doc/source/en/TortoiseGit/git_doc/git.xml | 186 +++-- .../en/TortoiseGit/git_doc/gitattributes.xml | 104 +-- doc/source/en/TortoiseGit/git_doc/gitcli.xml | 70 +- .../en/TortoiseGit/git_doc/gitcore-tutorial.xml | 63 +- .../en/TortoiseGit/git_doc/gitcredentials.xml | 26 +- .../en/TortoiseGit/git_doc/gitcvs-migration.xml | 30 +- doc/source/en/TortoiseGit/git_doc/gitdiffcore.xml | 30 +- doc/source/en/TortoiseGit/git_doc/gitglossary.xml | 486 ++++++------ doc/source/en/TortoiseGit/git_doc/githooks.xml | 60 +- doc/source/en/TortoiseGit/git_doc/gitignore.xml | 69 +- doc/source/en/TortoiseGit/git_doc/gitk.xml | 24 +- doc/source/en/TortoiseGit/git_doc/gitmodules.xml | 24 +- .../en/TortoiseGit/git_doc/gitnamespaces.xml | 16 +- .../TortoiseGit/git_doc/gitrepository-layout.xml | 31 +- doc/source/en/TortoiseGit/git_doc/gitrevisions.xml | 118 ++- .../en/TortoiseGit/git_doc/gittutorial-2.xml | 24 +- doc/source/en/TortoiseGit/git_doc/gittutorial.xml | 42 +- doc/source/en/TortoiseGit/git_doc/gitweb.conf.xml | 69 +- doc/source/en/TortoiseGit/git_doc/gitweb.xml | 52 +- doc/source/en/TortoiseGit/git_doc/gitworkflows.xml | 42 +- doc/source/en/TortoiseGit/git_doc/user-manual.xml | 832 +++++++++++---------- 173 files changed, 5691 insertions(+), 3839 deletions(-) create mode 100644 doc/source/en/TortoiseGit/git_doc/git-column.xml create mode 100644 doc/source/en/TortoiseGit/git_doc/git-credential.xml rewrite doc/source/en/TortoiseGit/git_doc/git-doc.xml (99%) diff --git a/doc/readme.txt b/doc/readme.txt index 1b12d669f..931daa687 100644 --- a/doc/readme.txt +++ b/doc/readme.txt @@ -12,7 +12,7 @@ Scripts and dtd are included, but the executables (formatting processor, microso help compiler, translation tools) have to be installed separately. You will also need to have a Java Runtime Environment version 1.3.x or above. -tools\fop\ - the fop processor +tools\fop\ - the fop processor (for PDF generation) tools\xsl\ - the docbook xsl files from sourceforge tools\ - xsl processor, hhc.exe, ... @@ -20,7 +20,6 @@ you can download all the required tools as a zip package from our website: http://code.google.com/p/tortoisesvn/downloads/list tools-*.7z. Use 7-zip extract to \TortotiseGit\Tools - Please note that having spaces in your directory path will (for the time being) cause the documentation build process to fail. @@ -30,6 +29,8 @@ For Chm docs you need: - Microsofts makehm.exe, Part of visual studio, sources available on msdn - Microsofts html workshop, Binaries available on msdn +If you want to update the git-man pages see source\en\TortoiseGit\git_doc.patch. + Structure: ========== diff --git a/doc/source/en/TortoiseGit/git_doc.patch b/doc/source/en/TortoiseGit/git_doc.patch index bdca43079..2188f8a91 100644 --- a/doc/source/en/TortoiseGit/git_doc.patch +++ b/doc/source/en/TortoiseGit/git_doc.patch @@ -1,4 +1,4 @@ -Generating git docbook documentation: +Generating git docbook documentation: (done on Debian SID) - Clone git - apply patch - change (system/global) asciidoc.conf @@ -13,7 +13,7 @@ Generating git docbook documentation: (\w)--(\w)=\1—\2 (\w)'(\w)=\1’\2 - make xml -- take *.xml files +- take *.xml files (skip git-tools.xml) - after generation change everyday.xml: article-id to everyday diff --git a/Documentation/Makefile b/Documentation/Makefile @@ -46,7 +46,7 @@ index 9ad6a6a..adfe07a 100644 technical/api-index.txt: technical/api-index-skel.txt \ diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf -index aea8627..5a920b6 100644 +index 1273a85..5223c99 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -9,6 +9,7 @@ @@ -57,25 +57,52 @@ index aea8627..5a920b6 100644 [attributes] asterisk=* -@@ -31,6 +32,49 @@ ifdef::backend-docbook[] +@@ -31,12 +32,94 @@ ifdef::backend-docbook[] endif::backend-docbook[] ifdef::backend-docbook[] +[header-declarations] + -+ ++ + +ifdef::doctype-article[] +[header] +template::[header-declarations] + -+
-+ ++ +template::[docinfo] + +{doctitle} + -+ ++ ++[footer] ++ ++ ++[callout-inlinemacro] ++# Callout. ++ ++ ++[listtags-callout] ++list={title?{title}}| ++item=| ++text=| ++ ++# [[id,text]] ++[anchor2-inlinemacro] ++ ++# [[[id]]] ++[anchor3-inlinemacro] ++[{1}] ++# <> ++[xref2-inlinemacro] ++{2} ++{2%} ++ ++[appendix] ++ ++{title} ++| ++ + +[linkgit-inlinemacro] +{0%{target}} @@ -86,11 +113,23 @@ index aea8627..5a920b6 100644 +{0} + +[sect1] -+ ++ +{title} +| + + ++[sect2] ++ ++{title} ++| ++ ++ ++[sect3] ++ ++{title} ++| ++ ++ +[literal-inlinemacro] +# Inline literal. +{passtext} @@ -107,28 +146,53 @@ index aea8627..5a920b6 100644 ifndef::git-asciidoc-no-roff[] # "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. # v1.72 breaks with this because it replaces dots not in roff requests. + [listingblock] + {title} +- ++ + ifdef::doctype-manpage[] + .ft C + endif::doctype-manpage[] +@@ -53,7 +136,7 @@ ifdef::doctype-manpage[] + # The following two small workarounds insert a simple paragraph after screen + [listingblock] + {title} +- ++ + | + + {title#} diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf -index 339b309..d422ae4 100644 +index d87294d..704f2cc --- a/Documentation/user-manual.conf +++ b/Documentation/user-manual.conf -@@ -7,15 +7,44 @@ startsb=[ +@@ -7,15 +7,53 @@ startsb=[ endsb=] tilde=~ +[header] +template::[header-declarations] + -+
-+ ++ +template::[docinfo] -+ + [linkgit-inlinemacro] -{target}{0?({0})} + + ++# [[id,text]] ++[anchor2-inlinemacro] ++ ++# [[[id]]] ++[anchor3-inlinemacro] ++[{1}] ++# <> ++[xref2-inlinemacro] ++{2} ++{2%} ++ +[sect1] -+ ++ +{title} +| + @@ -137,7 +201,8 @@ index 339b309..d422ae4 100644 -# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. [listingblock] {title} - +- ++ +ifdef::doctype-manpage[] + .ft C +endif::doctype-manpage[] diff --git a/doc/source/en/TortoiseGit/git_doc/everyday.xml b/doc/source/en/TortoiseGit/git_doc/everyday.xml index 68cb6b51f..9fd54228e 100644 --- a/doc/source/en/TortoiseGit/git_doc/everyday.xml +++ b/doc/source/en/TortoiseGit/git_doc/everyday.xml @@ -1,24 +1,22 @@ - + -
- + Everyday GIT With 20 Commands Or So Everyday GIT With 20 Commands Or So - - commands are essential for + commands are essential for anybody who makes a commit, even for somebody who works alone. If you work with other people, you will need commands listed in -the section as well. -People who play the role need to learn some more +the section as well. +People who play the role need to learn some more commands in addition to the above. - commands are for system + commands are for system administrators who are responsible for the care and feeding of git repositories. - -Individual Developer (Standalone)<anchor id="Individual Developer (Standalone)" xreflabel="[Individual Developer (Standalone)]"/> + +Individual Developer (Standalone)<anchor id="Everyday GIT With 20 Commands Or So_Individual Developer (Standalone)" xreflabel="[Individual Developer (Standalone)]"/> A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands. @@ -82,7 +80,7 @@ following commands. -
+
Examples @@ -93,16 +91,16 @@ Use a tarball as a starting point for a new repository. $ tar zxf frotz.tar.gz $ cd frotz $ git init -$ git add . +$ git add . $ git commit -m "import of frotz source tree." -$ git tag v2.43 +$ git tag v2.43 - + add everything under the current directory. - + make a lightweight, unannotated tag. @@ -115,83 +113,83 @@ make a lightweight, unannotated tag. Create a topic branch and develop. -$ git checkout -b alsa-audio +$ git checkout -b alsa-audio $ edit/compile/test -$ git checkout -- curses/ux_audio_oss.c -$ git add curses/ux_audio_alsa.c +$ git checkout -- curses/ux_audio_oss.c +$ git add curses/ux_audio_alsa.c $ edit/compile/test -$ git diff HEAD -$ git commit -a -s +$ git diff HEAD +$ git commit -a -s $ edit/compile/test -$ git reset --soft HEAD^ +$ git reset --soft HEAD^ $ edit/compile/test -$ git diff ORIG_HEAD -$ git commit -a -c ORIG_HEAD -$ git checkout master -$ git merge alsa-audio -$ git log --since='3 days ago' -$ git log v2.43.. curses/ +$ git diff ORIG_HEAD +$ git commit -a -c ORIG_HEAD +$ git checkout master +$ git merge alsa-audio +$ git log --since='3 days ago' +$ git log v2.43.. curses/ - + create a new topic branch. - + revert your botched changes in curses/ux_audio_oss.c. - + you need to tell git if you added a new file; removal and modification will be caught if you do git commit -a later. - + to see what changes you are committing. - + commit everything as you have tested, with your sign-off. - + take the last commit back, keeping what is in the working tree. - + look at the changes since the premature commit we took back. - + redo the commit undone in the previous step, using the message you originally wrote. - + switch to the master branch. - + merge a topic branch into your master branch. - + review commit logs; other forms to limit output can be combined and include --max-count=10 (show 10 commits), --until=2005-12-10, etc. - + view only the changes that touch what's in curses/ directory, since v2.43 tag. @@ -203,8 +201,8 @@ directory, since v2.43 tag.
- -Individual Developer (Participant)<anchor id="Individual Developer (Participant)" xreflabel="[Individual Developer (Participant)]"/> + +Individual Developer (Participant)<anchor id="Everyday GIT With 20 Commands Or So_Individual Developer (Participant)" xreflabel="[Individual Developer (Participant)]"/> A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer. @@ -234,7 +232,7 @@ addition to the ones needed by a standalone developer. -
+
Examples @@ -244,54 +242,54 @@ Clone the upstream and work on it. Feed changes to upstream. $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 -$ edit/compile/test; git commit -a -s -$ git format-patch origin -$ git pull -$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL -$ git reset --hard ORIG_HEAD -$ git gc -$ git fetch --tags +$ edit/compile/test; git commit -a -s +$ git format-patch origin +$ git pull +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL +$ git reset --hard ORIG_HEAD +$ git gc +$ git fetch --tags - + repeat as needed. - + extract patches from your branch for e-mail submission. - + git pull fetches from origin by default and merges into the current branch. - + immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in. - + fetch from a specific branch from a specific repository and merge. - + revert the pull. - + garbage collect leftover objects from reverted pull. - + from time to time, obtain official tags from the origin and store them under .git/refs/tags/. @@ -305,50 +303,50 @@ and store them under .git/refs/tags/. Push into another repository. -satellite$ git clone mothership:frotz frotz +satellite$ git clone mothership:frotz frotz satellite$ cd frotz -satellite$ git config --get-regexp '^(remote|branch)\.' +satellite$ git config --get-regexp '^(remote|branch)\.' 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 config remote.origin.push \ - master:refs/remotes/satellite/master + master:refs/remotes/satellite/master satellite$ edit/compile/test/commit -satellite$ git push origin +satellite$ git push origin mothership$ cd frotz mothership$ git checkout master -mothership$ git merge satellite/master +mothership$ git merge satellite/master - + mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine. - + clone sets these configuration variables by default. It arranges git pull to fetch and store the branches of mothership machine to local remotes/origin/* remote-tracking branches. - + arrange git push to push local master branch to remotes/satellite/master branch of the mothership machine. - + push will stash our work away on remotes/satellite/master remote-tracking branch on the mothership machine. You could use this as a back-up method. - + on mothership machine, merge the work done on the satellite machine into the master branch. @@ -362,19 +360,19 @@ machine into the master branch. Branch off of a specific tag. -$ git checkout -b private2.6.14 v2.6.14 +$ git checkout -b private2.6.14 v2.6.14 $ edit/compile/test; git commit -a $ git checkout master $ git format-patch -k -m --stdout v2.6.14..private2.6.14 | - git am -3 -k + git am -3 -k - + create a private branch based on a well known (but somewhat behind) tag. - + forward port all changes in private2.6.14 branch to master branch without a formal "merging". @@ -386,8 +384,8 @@ without a formal "merging".
- -Integrator<anchor id="Integrator" xreflabel="[Integrator]"/> + +Integrator<anchor id="Everyday GIT With 20 Commands Or So_Integrator" xreflabel="[Integrator]"/> A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these @@ -421,7 +419,7 @@ commands in addition to the ones needed by participants. -
+
Examples @@ -429,82 +427,82 @@ commands in addition to the ones needed by participants. My typical GIT day. -$ git status -$ git show-branch -$ mailx +$ git status +$ git show-branch +$ mailx & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q $ git checkout -b topic/one master -$ git am -3 -i -s -u ./+to-apply +$ git am -3 -i -s -u ./+to-apply $ compile/test -$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus -$ git checkout topic/one && git rebase master -$ git checkout pu && git reset --hard next -$ git merge topic/one topic/two && git merge hold/linus +$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus +$ git checkout topic/one && git rebase master +$ git checkout pu && git reset --hard next +$ git merge topic/one topic/two && git merge hold/linus $ git checkout maint -$ git cherry-pick master~4 +$ git cherry-pick master~4 $ compile/test -$ git tag -s -m "GIT 0.99.9x" v0.99.9x -$ git fetch ko && git show-branch master maint 'tags/ko-*' -$ git push ko -$ git push ko v0.99.9x +$ git tag -s -m "GIT 0.99.9x" v0.99.9x +$ git fetch ko && git show-branch master maint 'tags/ko-*' +$ git push ko +$ git push ko v0.99.9x - + see what I was in the middle of doing, if any. - + see what topic branches I have and think about how ready they are. - + read mails, save ones that are applicable, and save others that are not quite ready. - + apply them, interactively, with my sign-offs. - + create topic branch as needed and apply, again with my sign-offs. - + rebase internal topic branch that has not been merged to the master, nor exposed as a part of a stable branch. - + restart pu every time from the next. - + and bundle topic branches still cooking. - + backport a critical fix. - + create a signed tag. - + make sure I did not accidentally rewind master beyond what I already pushed out. ko shorthand points at the repository I have @@ -523,12 +521,12 @@ Push: maint everything ko-master has, and next should have everything ko-next has. - + push out the bleeding edge. - + push the tag out, too. @@ -539,8 +537,8 @@ push the tag out, too.
- -Repository Administration<anchor id="Repository Administration" xreflabel="[Repository Administration]"/> + +Repository Administration<anchor id="Everyday GIT With 20 Commands Or So_Repository Administration" xreflabel="[Repository Administration]"/> A repository administrator uses the following tools to set up and maintain access to the repository by developers. @@ -559,7 +557,7 @@ and maintain access to the repository by developers. link:howto/update-hook-example.txt[update hook howto] has a good example of managing a shared central repository. -
+
Examples @@ -611,22 +609,22 @@ Others might be different. Give push/pull only access to developers. -$ grep git /etc/passwd +$ grep git /etc/passwd alice:x:1000:1000::/home/alice:/usr/bin/git-shell bob:x:1001:1001::/home/bob:/usr/bin/git-shell cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell david:x:1003:1003::/home/david:/usr/bin/git-shell -$ grep git /etc/shells +$ grep git /etc/shells /usr/bin/git-shell - + log-in shell is set to /usr/bin/git-shell, which does not allow anything but git push and git pull. The users should get an ssh access to the machine. - + in many distributions /etc/shells needs to list what is used as the login shell. @@ -640,10 +638,10 @@ as the login shell. CVS-style shared repository. -$ grep git /etc/group +$ grep git /etc/group git:x:9418:alice,bob,cindy,david $ cd /home/devo.git -$ ls -l +$ ls -l lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches -rw-rw-r-- 1 david git 84 Dec 4 22:40 config @@ -654,30 +652,30 @@ $ ls -l drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes -$ ls -l hooks/update +$ ls -l hooks/update -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update -$ cat info/allowed-users +$ cat info/allowed-users refs/heads/master alice\|cindy refs/heads/doc-update bob refs/tags/v[0-9]* david - + place the developers into the same git group. - + and make the shared repository writable by the group. - + use update-hook example by Carl from Documentation/howto/ for branch policy control. - + alice and cindy can push into master, only bob can push into doc-update. david is the release manager and is the only person who can @@ -692,16 +690,16 @@ create and push version tags. HTTP server to support dumb protocol transfer. -dev$ git update-server-info -dev$ ftp user@isp.example.com +dev$ git update-server-info +dev$ ftp user@isp.example.com ftp> cp -r .git /home/user/myproject.git - + make sure your info/refs and objects/info/packs are up-to-date - + upload to public HTTP server hosted by your ISP. @@ -712,4 +710,4 @@ upload to public HTTP server hosted by your ISP.
-
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-add.xml b/doc/source/en/TortoiseGit/git_doc/git-add.xml index 10adbd83c..28ea2f18a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-add.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-add.xml @@ -1,18 +1,16 @@ - + -
- + git-add(1) git-add(1) - - + NAME git-add - Add file contents to the index - + SYNOPSIS
git add [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] @@ -21,7 +19,7 @@ [<filepattern>…]
- + DESCRIPTION This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. @@ -49,7 +47,7 @@ be used to add ignored files with the -f (force) option.Please see for alternative ways to add content to a commit. - + OPTIONS @@ -264,14 +262,14 @@ subdirectories. - + Configuration The optional configuration variable core.excludesfile indicates a path to a file containing patterns of file names to exclude from git-add, similar to $GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to -those in info/exclude. See . +those in info/exclude. See . - + EXAMPLES @@ -295,7 +293,7 @@ listing the files explicitly), it does not consider - + Interactive mode When the command enters the interactive mode, it shows the output of the status subcommand, and then goes into its @@ -432,7 +430,7 @@ diff - + EDITING PATCHES Invoking git add -e or selecting e from the interactive hunk selector will open a patch in your editor; after the editor exits, the @@ -548,7 +546,7 @@ modifying the contents of context or removal lines - + SEE ALSO @@ -557,8 +555,8 @@ modifying the contents of context or removal lines - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-am.xml b/doc/source/en/TortoiseGit/git_doc/git-am.xml index 2265b6717..8ce12c26a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-am.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-am.xml @@ -1,37 +1,35 @@ - + -
- + git-am(1) git-am(1) - - + NAME git-am - Apply a series of patches from a mailbox - + SYNOPSIS
git am [--signoff] [--keep] [--keep-cr | --no-keep-cr] [--utf8 | --no-utf8] [--3way] [--interactive] [--committer-date-is-author-date] [--ignore-date] [--ignore-space-change | --ignore-whitespace] [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>] - [--exclude=<path>] [--reject] [-q | --quiet] + [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet] [--scissors | --no-scissors] [(<mbox> | <Maildir>)…] git am (--continue | --skip | --abort)
- + DESCRIPTION Splits mail messages in a mailbox into commit log message, authorship information and patches, and applies them to the current branch. - + OPTIONS @@ -208,6 +206,9 @@ default. You can use --no-utf8 to override this. +--include=<path> + + --reject @@ -317,7 +318,7 @@ default. You can use --no-utf8 to override this. - + DISCUSSION The commit author name is taken from the "From: " line of the message, and commit author date is taken from the "Date: " line @@ -380,12 +381,12 @@ commits, like running git am on the wrong branch or an erro commits that is more easily fixed by changing the mailbox (e.g. errors in the "From:" lines). - + SEE ALSO . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-annotate.xml b/doc/source/en/TortoiseGit/git_doc/git-annotate.xml index 07bb48161..2d9a54631 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-annotate.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-annotate.xml @@ -1,24 +1,22 @@ - + -
- + git-annotate(1) git-annotate(1) - - + NAME git-annotate - Annotate file lines with commit information - + SYNOPSIS
git annotate [options] file [revision]
- + DESCRIPTION Annotates each line in the given file with information from the commit which introduced the line. Optionally annotates from a given revision. @@ -27,7 +25,7 @@ they use slightly different output formats, and this command exists only for backward compatibility to support existing scripts, and provide a more familiar command name for people coming from other SCM systems. - + OPTIONS @@ -277,12 +275,12 @@ take effect. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-apply.xml b/doc/source/en/TortoiseGit/git_doc/git-apply.xml index 7bbf3e73c..537f29007 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-apply.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-apply.xml @@ -1,21 +1,19 @@ - + -
- + git-apply(1) git-apply(1) - - + NAME git-apply - Apply a patch to files and/or to the index - + SYNOPSIS
-git apply [--stat] [--numstat] [--summary] [--check] [--index] +git apply [--stat] [--numstat] [--summary] [--check] [--index] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] @@ -25,7 +23,7 @@ [--verbose] [<patch>…]
- + DESCRIPTION Reads the supplied diff output (i.e. "a patch") and applies it to files. With the --index option the patch is also applied to the index, and @@ -36,7 +34,7 @@ and does not require them to be in a git repository. to create commits from patches generated by and/or received by email. - + OPTIONS @@ -130,6 +128,24 @@ and does not require them to be in a git repository. +-3 + + +--3way + + + + When the patch does not apply cleanly, fall back on 3-way merge if + the patch records the identity of blobs it is supposed to apply to, + and we have those blobs available locally, possibly leaving the + conflict markers in the files in the working tree for the user to + resolve. This option implies the --index option, and is incompatible + with the --reject and the --cached options. + + + + + --build-fake-ancestor=<file> @@ -426,7 +442,7 @@ running git apply --directory=modules/git-gui. - + Configuration @@ -454,7 +470,7 @@ apply.whitespace - + Submodules If the patch contains any changes to submodules then git apply treats these changes as follows. @@ -467,12 +483,12 @@ are not updated. are ignored and only the absence or presence of the corresponding subdirectory is checked and (if possible) updated. - + SEE ALSO . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-archimport.xml b/doc/source/en/TortoiseGit/git_doc/git-archimport.xml index a80e6e482..63fbb61eb 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-archimport.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-archimport.xml @@ -1,25 +1,23 @@ - + -
- + git-archimport(1) git-archimport(1) - - + NAME git-archimport - Import an Arch repository into git - + SYNOPSIS
git archimport [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] <archive/branch>[:<git-branch>] …
- + DESCRIPTION Imports a project from one or more Arch repositories. It will follow branches and repositories within the namespaces defined by the <archive/branch> @@ -52,7 +50,7 @@ result will make the most sense only if no commits are made to the first branch, after the second branch is created. Still, this is useful to convert Arch repositories that had been rotated periodically. - + MERGES Patch merge data from Arch is used to mark merges in git as well. git does not care much about tracking patches, and only considers a merge when a @@ -63,7 +61,7 @@ import process does lose some patch-trading metadata. git will find a good merge base, and it has a good chance of identifying patches that have been traded out-of-sequence between the branches. - + OPTIONS @@ -169,8 +167,8 @@ patches that have been traded out-of-sequence between the branches. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-archive.xml b/doc/source/en/TortoiseGit/git_doc/git-archive.xml index 41244b231..6ea0cc3dd 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-archive.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-archive.xml @@ -1,18 +1,16 @@ - + -
- + git-archive(1) git-archive(1) - - + NAME git-archive - Create an archive of files from a named tree - + SYNOPSIS
git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] @@ -21,7 +19,7 @@ [<path>…]
- + DESCRIPTION Creates an archive of the specified format containing the tree structure for the named tree, and writes it out to the standard @@ -36,7 +34,7 @@ extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment. - + OPTIONS @@ -169,9 +167,9 @@ comment. - + BACKEND EXTRA OPTIONS -
+
zip @@ -198,7 +196,7 @@ comment.
- + CONFIGURATION @@ -250,7 +248,7 @@ tar.<format>.remote - + ATTRIBUTES @@ -285,7 +283,7 @@ appropriate export-ignore in its .gitattributes), adjust th option. Alternatively you can keep necessary attributes that should apply while archiving any tree in your $GIT_DIR/info/attributes file. - + EXAMPLES @@ -378,12 +376,12 @@ while archiving any tree in your $GIT_DIR/info/attributes f - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-bisect.xml b/doc/source/en/TortoiseGit/git_doc/git-bisect.xml index a423fa7c9..75671c4df 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-bisect.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-bisect.xml @@ -1,24 +1,22 @@ - + -
- + git-bisect(1) git-bisect(1) - - + NAME git-bisect - Find by binary search the change that introduced a bug - + SYNOPSIS
git bisect <subcommand> <options>
- + DESCRIPTION The command takes various subcommands, and different options depending on the subcommand: @@ -35,12 +33,12 @@ git bisect run <cmd>... This command uses git rev-list --bisect to help drive the binary search process to find which change introduced a bug, given an old "good" commit object name and a later "bad" commit object name. -
+
Getting help Use "git bisect" to get a short usage description, and "git bisect help" or "git bisect -h" to get a long usage description.
-
+
Basic bisect commands: start, bad, good Using the Linux kernel tree as an example, basic use of the bisect command is as follows: @@ -64,7 +62,7 @@ or "git bisect bad" to ask for the next bisection. Eventually there will be no more revisions left to bisect, and you will have been left with the first bad kernel revision in "refs/bisect/bad".
-
+
Bisect reset After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command: @@ -79,7 +77,7 @@ instead: bisection commit and avoid switching commits at all, while git bisect reset bisect/bad will check out the first bad revision.
-
+
Bisect visualize To see the currently remaining suspects in gitk, issue the following command during the bisection process: @@ -90,7 +88,7 @@ instead. You can also give command line options such as -p --stat. $ git bisect view --stat
-
+
Bisect log and bisect replay After having marked revisions as good or bad, issue the following command to show what has been done so far: @@ -102,7 +100,7 @@ return to a corrected state: $ git bisect reset $ git bisect replay that-file
-
+
Avoiding testing a commit If, in the middle of a bisect session, you know that the next suggested revision is not a good one to test (e.g. the change the commit @@ -118,7 +116,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what Then compile and test the chosen revision, and afterwards mark the revision as good or bad in the usual manner.
-
+
Bisect skip Instead of choosing by yourself a nearby commit, you can ask git to do it for you by issuing the command: @@ -136,7 +134,7 @@ would issue the command: This tells the bisect process that the commits between v2.5 included and v2.6 included should be skipped.
-
+
Cutting down bisection by giving more parameters to bisect start You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying @@ -149,7 +147,7 @@ the bad commit when issuing the bisect start command:
-
+
Bisect run If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command: @@ -183,7 +181,7 @@ with the status of the real test to let the "git bisect run" command loop determine the eventual outcome of the bisect session.
- + OPTIONS @@ -201,7 +199,7 @@ does not require a checked out tree. - + EXAMPLES @@ -295,13 +293,13 @@ required by git pack objects. - + SEE ALSO link:git-bisect-lk2009.html[Fighting regressions with git bisect], . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-blame.xml b/doc/source/en/TortoiseGit/git_doc/git-blame.xml index 1a0822086..c0244f756 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-blame.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-blame.xml @@ -1,18 +1,16 @@ - + -
- + git-blame(1) git-blame(1) - - + NAME git-blame - Show what revision and author last modified each line of a file - + SYNOPSIS
git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L n,m] @@ -20,11 +18,16 @@ [<rev> | --contents <file> | --reverse <rev>] [--] <file>
- + DESCRIPTION Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision. The command can also limit the range of lines annotated. +The origin of lines is automatically followed across whole-file +renames (currently there is no option to turn the rename-following +off). To follow lines moved from one file to another, or to follow +lines that were copied and pasted from another file, etc., see the +-C and -M options. The report does not tell you anything about lines which have been deleted or replaced; you need to use a tool such as git diff or the "pickaxe" interface briefly mentioned in the following paragraph. @@ -37,7 +40,7 @@ a text string in the diff. A small example: 5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file> ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output - + OPTIONS @@ -387,7 +390,7 @@ take effect. - + THE PORCELAIN FORMAT In this format, each line is output after a header; the header at the minimum has the first line which has: @@ -451,7 +454,7 @@ git blame --line-porcelain file | sed -n 's/^author //p' | sort | uniq -c | sort -rn - + SPECIFYING RANGES Unlike git blame and git annotate in older versions of git, the extent of the annotation can be limited to both line ranges and revision @@ -484,7 +487,7 @@ introduced the file with: parents, using commit^! 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 @@ -527,7 +530,7 @@ commit commentary), a blame viewer will not care. - + MAPPING AUTHORS If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file configuration option, it @@ -558,7 +561,7 @@ prefers her family name fully spelled out. A proper .mailmap Jane Doe <jane@desktop.(none)> Joe R. Developer <joe@example.com> -Note how there is no need for an entry for <jane@laptop.(none)>, because the +Note how there is no need for an entry for <jane@laptop.(none)>, because the real name of that author is already correct. Example 2: Your repository contains commits from the following authors: @@ -577,12 +580,12 @@ Santa Claus <santa.claus@northpole.xx> <me@company.xx> Use hash # for comments that are either on their own line, or after the email address. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-branch.xml b/doc/source/en/TortoiseGit/git_doc/git-branch.xml index d097d6989..1142714c2 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-branch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-branch.xml @@ -1,30 +1,31 @@ - + -
- + git-branch(1) git-branch(1) - - + NAME git-branch - List, create, or delete branches - + SYNOPSIS
git branch [--color[=<when>] | --no-color] [-r | -a] [--list] [-v [--abbrev=<length> | --no-abbrev]] + [--column[=<options>] | --no-column] [(--merged | --no-merged | --contains) [<commit>]] [<pattern>…] git branch [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>] +git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] +git branch --unset-upstream [<branchname>] git branch (-m | -M) [<oldbranch>] <newbranch> git branch (-d | -D) [-r] <branchname>… git branch --edit-description [<branchname>]
- + DESCRIPTION With no arguments, existing branches are listed and the current branch will be highlighted with an asterisk. Option -r causes the remote-tracking @@ -50,7 +51,7 @@ branch so that git pull will appropriately merge from the remote-tracking branch. This behavior may be changed via the global branch.autosetupmerge configuration flag. That setting can be overridden by using the --track and --no-track options, and -changed later using git branch --set-upstream. +changed later using git branch --set-upstream-to. With a -m or -M option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch @@ -65,7 +66,7 @@ in the remote repository or if git fetch was configured not them again. See also the prune subcommand of for a way to clean up all obsolete remote-tracking branches. - + OPTIONS @@ -173,6 +174,22 @@ way to clean up all obsolete remote-tracking branches. +--column[=<options>] + + +--no-column + + + + Display branch listing in columns. See configuration variable + column.branch for option syntax.--column and --no-column + without options are equivalent to always and never respectively. + +This option is only applicable in non-verbose mode. + + + + -r @@ -213,6 +230,9 @@ way to clean up all obsolete remote-tracking branches. -v +-vv + + --verbose @@ -220,7 +240,22 @@ way to clean up all obsolete remote-tracking branches. When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print - the name of the upstream branch, as well. + the name of the upstream branch, as well (see also git remote + show <remote>). + + + + + +-q + + +--quiet + + + + Be more quiet when creating or deleting a branch, suppressing + non-error messages. @@ -295,6 +330,32 @@ start-point is either a local or remote-tracking branch. +-u <upstream> + + +--set-upstream-to=<upstream> + + + + Set up <branchname>'s tracking information so <upstream> is + considered <branchname>'s upstream branch. If no <branchname> + is specified, then it defaults to the current branch. + + + + + +--unset-upstream + + + + Remove the upstream information for <branchname>. If no branch + is specified it defaults to the current branch. + + + + + --edit-description @@ -385,7 +446,7 @@ start-point is either a local or remote-tracking branch. - + Examples @@ -395,10 +456,10 @@ Start development from a known tag $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 -$ git branch my2.6.14 v2.6.14 +$ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14 - + This step and the next one could be combined into a single step with "checkout -b my2.6.14 v2.6.14". @@ -414,17 +475,17 @@ Delete an unneeded branch $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git -$ git branch -d -r origin/todo origin/html origin/man -$ git branch -D test +$ git branch -d -r origin/todo origin/html origin/man +$ git branch -D test - + Delete the remote-tracking branches "todo", "html" and "man". The next fetch or pull will create them again unless you configure them not to. See . - + Delete the "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from the test branch. @@ -435,7 +496,7 @@ is currently checked out) does not have all commits from the test branch. - + Notes If you are creating a branch that you want to checkout immediately, it is easier to use the git checkout command with its -b option to create @@ -464,7 +525,7 @@ but different purposes: - + SEE ALSO , , @@ -472,8 +533,8 @@ but different purposes: Understanding history: What is a branch? in the Git User's Manual. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-bundle.xml b/doc/source/en/TortoiseGit/git_doc/git-bundle.xml index c81ced2b9..1944f50c0 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-bundle.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-bundle.xml @@ -1,18 +1,16 @@ - + -
- + git-bundle(1) git-bundle(1) - - + NAME git-bundle - Move objects and refs by archive - + SYNOPSIS
git bundle create <file> <git-rev-list-args> @@ -21,7 +19,7 @@ git bundle unbundle <file> [<refname>…]
- + DESCRIPTION Some workflows require that one or more branches of development on one machine be replicated on another machine, but the two machines cannot @@ -36,7 +34,7 @@ basis for the bundle that is held by the destination repository: the bundle assumes that all objects in the basis are already in the destination repository. - + OPTIONS @@ -124,7 +122,7 @@ unbundle <file> - + SPECIFYING REFERENCES git bundle will only package references that are shown by git show-ref: this includes heads, tags, and remote heads. References @@ -139,7 +137,7 @@ It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination. - + EXAMPLE Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B. @@ -200,8 +198,8 @@ references when fetching: You can also see what references it offers: $ git ls-remote mybundle - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-cat-file.xml b/doc/source/en/TortoiseGit/git_doc/git-cat-file.xml index 395d7b01d..9b97f846a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cat-file.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cat-file.xml @@ -1,25 +1,23 @@ - + -
- + git-cat-file(1) git-cat-file(1) - - + NAME git-cat-file - Provide content or type and size information for repository objects - + SYNOPSIS
git cat-file (-t | -s | -e | -p | <type> | --textconv ) <object> git cat-file (--batch | --batch-check) < <list-of-objects>
- + DESCRIPTION In its first form, the command provides the content or the type of an object in the repository. The type is required unless -t or -p is used to find the @@ -28,7 +26,7 @@ object type, or -s is used to find the object size, or In the second form, a list of objects (separated by linefeeds) is provided on stdin, and the SHA1, type, and size of each object is printed on stdout. - + OPTIONS @@ -137,7 +135,7 @@ stdin, and the SHA1, type, and size of each object is printed on stdout. - + OUTPUT If -t is specified, one of the <type>. If -s is specified, the size of the <object> in bytes. @@ -156,8 +154,8 @@ each object specified on stdin: for each object specified on stdin that does not exist in the repository: <object> SP missing LF - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-check-attr.xml b/doc/source/en/TortoiseGit/git_doc/git-check-attr.xml index 59361d096..5446509e8 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-check-attr.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-check-attr.xml @@ -1,30 +1,28 @@ - + -
- + git-check-attr(1) git-check-attr(1) - - + NAME git-check-attr - Display gitattributes information - + SYNOPSIS
git check-attr [-a | --all | attr…] [--] pathname… git check-attr --stdin [-z] [-a | --all | attr…] < <list-of-paths>
- + DESCRIPTION For every pathname, this command will list if each attribute is unspecified, set, or unset as a gitattribute on that pathname. - + OPTIONS @@ -86,7 +84,7 @@ will be treated as an attribute and the rest of the arguments as pathnames. - + OUTPUT The output is of the form: <path> COLON SP <attribute> COLON SP <info> LF @@ -135,7 +133,7 @@ when a value has been assigned to the attribute. - + EXAMPLES In the examples, the following .gitattributes file is used: *.java diff=java -crlf myAttr @@ -191,12 +189,12 @@ Not all values are equally unambiguous: $ git check-attr caveat README README: caveat: unspecified - + SEE ALSO . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.xml b/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.xml index 5f9fa0304..afab5f69d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.xml @@ -1,18 +1,16 @@ - + -
- + git-check-ref-format(1) git-check-ref-format(1) - - + NAME git-check-ref-format - Ensures that a reference name is well formed - + SYNOPSIS
git check-ref-format [--normalize] @@ -21,7 +19,7 @@ git check-ref-format --branch <branchname-shorthand>
- + DESCRIPTION Checks if a given refname is acceptable, and exits with a non-zero status if it is not. @@ -128,7 +126,7 @@ were on. This option should be used by porcelains to accept this syntax anywhere a branch name is expected, so they can act as if you typed the branch name. - + OPTIONS @@ -177,7 +175,7 @@ typed the branch name. - + EXAMPLES @@ -195,8 +193,8 @@ die "we do not like '$newbranch' as a branch name." - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-checkout-index.xml b/doc/source/en/TortoiseGit/git_doc/git-checkout-index.xml index 1359cd1fc..efa572ad0 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-checkout-index.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-checkout-index.xml @@ -1,18 +1,16 @@ - + -
- + git-checkout-index(1) git-checkout-index(1) - - + NAME git-checkout-index - Copy files from the index to the working tree - + SYNOPSIS
git checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] @@ -22,12 +20,12 @@ [--] [<file>…]
- + DESCRIPTION Will copy all files listed from the index to the working directory (not overwriting existing files). - + OPTIONS @@ -184,7 +182,7 @@ since git checkout-index accepts --stdin it would be faster it will prevent problems with a filename of, for example, -a. Using -- is probably a good policy in scripts. - + Using --temp or --stage=all When --temp is used (or implied by --stage=all) git checkout-index will create a temporary file for each index @@ -226,7 +224,7 @@ file names are always relative to the top level directory. link the content of the link will be written to a normal file. It is up to the end-user or the Porcelain to make use of this information. - + EXAMPLES @@ -267,8 +265,8 @@ into the file .merged-Makefile. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-checkout.xml b/doc/source/en/TortoiseGit/git_doc/git-checkout.xml index 64cc1b087..c6b3ce50d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-checkout.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-checkout.xml @@ -1,18 +1,16 @@ - + -
- + git-checkout(1) git-checkout(1) - - + NAME git-checkout - Checkout a branch or paths to the working tree - + SYNOPSIS
git checkout [-q] [-f] [-m] [<branch>] @@ -22,7 +20,7 @@ git checkout [-p|--patch] [<tree-ish>] [--] [<paths>…]
- + DESCRIPTION Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will @@ -31,24 +29,39 @@ branch. -git checkout [<branch>] +git checkout <branch> + + + To prepare for working on <branch>, switch to it by updating + the index and the files in the working tree, and by pointing + HEAD at the branch. Local modifications to the files in the + working tree are kept, so that they can be committed to the + <branch>. + +If <branch> is not found but there does exist a tracking branch in +exactly one remote (call it <remote>) with a matching name, treat as +equivalent to +$ git checkout -b <branch> --track <remote>/<branch> +You could omit <branch>, in which case the command degenerates to +"check out the current branch", which is a glorified no-op with a +rather expensive side-effects to show only the tracking information, +if exists, for the current branch. + + + git checkout -b|-B <new_branch> [<start point>] - -git checkout [--detach] [<commit>] - - This form switches branches by updating the index, working - tree, and HEAD to reflect the specified branch or commit. + Specifying -b causes a new branch to be created as if + were called and then checked out. In + this case you can use the --track or --no-track options, + which will be passed to git branch. As a convenience, + --track without -b implies branch creation; see the + description of --track below. -If -b is given, a new branch is created as if -were called and then checked out; in this case you can -use the --track or --no-track options, which will be passed to -git branch. As a convenience, --track without -b implies branch -creation; see the description of --track below. If -B is given, <new_branch> is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of $ git branch -f <branch> [<start point>] @@ -59,6 +72,28 @@ successful. +git checkout --detach [<branch>] + + +git checkout <commit> + + + + Prepare to work on top of <commit>, by detaching HEAD at it + (see "DETACHED HEAD" section), and updating the index and the + files in the working tree. Local modifications to the files + in the working tree are kept, so that the resulting working + tree will be the state recorded in the commit plus the local + modifications. + +Passing --detach forces this behavior in the case of a <branch> (without +the option, giving a branch name to the command would check out the branch, +instead of detaching HEAD at it), or the current commit, +if no <branch> is specified. + + + + git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>… @@ -83,7 +118,7 @@ file can be discarded to re-create the original conflicted merge result. - + OPTIONS @@ -132,7 +167,7 @@ entries; instead, unmerged entries are ignored. --b +-b <new_branch> @@ -143,7 +178,7 @@ entries; instead, unmerged entries are ignored. --B +-B <new_branch> @@ -215,7 +250,7 @@ explicitly give a name with -b in such a case. ---orphan +--orphan <new_branch> @@ -355,7 +390,7 @@ leave out at most one of A and B, in w - + DETACHED HEAD HEAD normally refers to a named branch (e.g. master). Meanwhile, each branch refers to a specific commit. Let's look at a repo with three @@ -439,24 +474,24 @@ a---b---c---d branch 'master' (refers to commit 'd') by the routine git garbage collection process, unless we create a reference before that happens. If we have not yet moved away from commit f, any of these will create a reference to it: -$ git checkout -b foo -$ git branch foo -$ git tag foo +$ git checkout -b foo +$ git branch foo +$ git tag foo - + creates a new branch foo, which refers to commit f, and then updates HEAD to refer to branch foo. In other words, we'll no longer be in detached HEAD state after this command. - + similarly creates a new branch foo, which refers to commit f, but leaves HEAD detached. - + creates a new tag foo, which refers to commit f, leaving HEAD detached. @@ -470,7 +505,7 @@ can use either of these commands: $ git reflog -2 HEAD # or $ git log -g -2 HEAD - + EXAMPLES @@ -479,25 +514,32 @@ The following sequence checks out the master branch, revert the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index. -$ git checkout master -$ git checkout master~2 Makefile +$ git checkout master +$ git checkout master~2 Makefile $ rm -f hello.c -$ git checkout hello.c +$ git checkout hello.c - + switch branch - + take a file out of another commit - + restore hello.c from the index +If you want to check out all C source files out of the index, +you can say +$ git checkout -- '*.c' +Note the quotes around *.c. The file hello.c will also be +checked out, even though it is no longer in the working tree, +because the file globbing is used to match entries in the index +(not in the working tree by the shell). If you have an unfortunate branch that is named hello.c, this step would be confused as an instruction to switch to that branch. You should instead write: @@ -542,8 +584,8 @@ $ git add frotz - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.xml b/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.xml index ee43c3605..f2f71d084 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.xml @@ -1,18 +1,16 @@ - + -
- + git-cherry-pick(1) git-cherry-pick(1) - - + NAME git-cherry-pick - Apply the changes introduced by some existing commits - + SYNOPSIS
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>… @@ -21,7 +19,7 @@ git cherry-pick --abort
- + DESCRIPTION Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your @@ -65,7 +63,7 @@ No other modifications are made. See for some hints on resolving such conflicts. - + OPTIONS @@ -79,7 +77,9 @@ conflicts. . Sets of commits can be passed but no traversal is done by default, as if the --no-walk option was specified, see - . + . Note that specifying a range will + feed all <commit>… arguments to a single revision walk + (see a later example that uses maint master..next). @@ -195,6 +195,51 @@ effect to your index in a row. +--allow-empty + + + + By default, cherry-picking an empty commit will fail, + indicating that an explicit invocation of git commit + --allow-empty is required. This option overrides that + behavior, allowing empty commits to be preserved automatically + in a cherry-pick. Note that when "--ff" is in effect, empty + commits that meet the "fast-forward" requirement will be kept + even without this option. Note also, that use of this option only + keeps commits that were initially empty (i.e. the commit recorded the + same tree as its parent). Commits which are made empty due to a + previous commit are dropped. To force the inclusion of those commits + use --keep-redundant-commits. + + + + + +--allow-empty-message + + + + By default, cherry-picking a commit with an empty message will fail. + This option overrides that behaviour, allowing commits with empty + messages to be cherry picked. + + + + + +--keep-redundant-commits + + + + If a commit being cherry picked duplicates a commit already in the + current history, it will become empty. By default these + redundant commits are ignored. This option overrides that behavior and + creates an empty commit object. Implies --allow-empty. + + + + + --strategy=<strategy> @@ -221,7 +266,7 @@ effect to your index in a row. - + SEQUENCER SUBCOMMANDS @@ -260,7 +305,7 @@ effect to your index in a row. - + EXAMPLES @@ -290,6 +335,23 @@ effect to your index in a row. +git cherry-pick maint next ^master + + +git cherry-pick maint master..next + + + + Apply the changes introduced by all commits that are + ancestors of maint or next, but not master or any of its + ancestors. Note that the latter does not mean maint and + everything between master and next; specifically, + maint will not be used if it is included in master. + + + + + git cherry-pick master~4 master~2 @@ -344,12 +406,12 @@ effect to your index in a row. The following sequence attempts to backport a patch, bails out because the code the patch applies to has changed too much, and then tries again, this time exercising more care about matching up context lines. -$ git cherry-pick topic^ -$ git diff -$ git reset --merge ORIG_HEAD -$ git cherry-pick -Xpatience topic^ +$ git cherry-pick topic^ +$ git diff +$ git reset --merge ORIG_HEAD +$ git cherry-pick -Xpatience topic^ - + apply the change that would be shown by git show topic^. In this example, the patch does not apply cleanly, so @@ -357,19 +419,19 @@ information about the conflict is written to the index and working tree and no new commit results. - + summarize changes to be reconciled - + cancel the cherry-pick. In other words, return to the pre-cherry-pick state, preserving any local modifications you had in the working tree. - + try to apply the change introduced by topic^ again, spending extra time to avoid mistakes based on incorrectly matching @@ -378,12 +440,12 @@ context lines. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-cherry.xml b/doc/source/en/TortoiseGit/git_doc/git-cherry.xml index 18b17fa77..83af0ba1c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cherry.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cherry.xml @@ -1,24 +1,22 @@ - + -
- + git-cherry(1) git-cherry(1) - - + NAME git-cherry - Find commits not merged upstream - + SYNOPSIS
git cherry [-v] [<upstream> [<head> [<limit>]]]
- + DESCRIPTION The changeset (or "diff") of each commit between the fork-point and <head> is compared against each commit between the fork-point and <upstream>. @@ -45,7 +43,7 @@ has been applied <upstream> under a different commit id. For example, this will happen if you're feeding patches <upstream> via email rather than pushing or pulling commits directly. - + OPTIONS @@ -91,12 +89,12 @@ than pushing or pulling commits directly. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-citool.xml b/doc/source/en/TortoiseGit/git_doc/git-citool.xml index 7dc38b4fa..bbe38cd9d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-citool.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-citool.xml @@ -1,24 +1,22 @@ - + -
- + git-citool(1) git-citool(1) - - + NAME git-citool - Graphical alternative to git-commit - + SYNOPSIS
git citool
- + DESCRIPTION A Tcl/Tk based graphical interface to review modified files, stage them into the index, enter a commit message and record the new @@ -27,8 +25,8 @@ to the less interactive git commit program. git citool is actually a standard alias for git gui citool. See for more details. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-clean.xml b/doc/source/en/TortoiseGit/git_doc/git-clean.xml index ae9d35e83..c6fe8a159 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-clean.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-clean.xml @@ -1,24 +1,22 @@ - + -
- + git-clean(1) git-clean(1) - - + NAME git-clean - Remove untracked files from the working tree - + SYNOPSIS
git clean [-d] [-f] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>…
- + DESCRIPTION Cleans the working tree by recursively removing files that are not under version control, starting from the current directory. @@ -28,7 +26,7 @@ example, be useful to remove all build products. If any optional <path>... arguments are given, only those paths are affected. - + OPTIONS @@ -128,8 +126,12 @@ are affected. - + +SEE ALSO + + + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-clone.xml b/doc/source/en/TortoiseGit/git_doc/git-clone.xml index c65b4793a..9de1dcbe5 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-clone.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-clone.xml @@ -1,18 +1,16 @@ - + -
- + git-clone(1) git-clone(1) - - + NAME git-clone - Clone a repository into a new directory - + SYNOPSIS
git clone [--template=<template_directory>] @@ -24,7 +22,7 @@ [<directory>]
- + DESCRIPTION Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository @@ -34,13 +32,14 @@ currently active branch. After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the -current master branch, if any. +current master branch, if any (this is untrue when "--single-branch" +is given; see below). This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables. - + OPTIONS @@ -57,14 +56,17 @@ configuration variables. mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked - to save space when possible. This is now the default when - the source repository is specified with /path/to/repo - syntax, so it essentially is a no-op option. To force - copying instead of hardlinking (which may be desirable - if you are trying to make a back-up of your repository), - but still avoid the usual "git aware" transport - mechanism, --no-hardlinks can be used. - + to save space when possible. + +If the repository is specified as a local path (e.g., /path/to/repo), +this is the default, and --local is essentially a no-op. If the +repository is specified as a URL, then this flag is ignored (and we +never use the local optimizations). Specifying --no-local will +override the default when /path/to/repo is given, using the regular +git transport instead. +To force copying instead of hardlinking (which may be desirable if you +are trying to make a back-up of your repository), but still avoid the +usual "git aware" transport mechanism, --no-hardlinks can be used. @@ -243,9 +245,10 @@ objects from the source repository into a pack in the cloned repository. Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to <name> branch - instead. --branch can also take tags and treat them like - detached HEAD. In a non-bare repository, this is the branch - that will be checked out. + instead. In a non-bare repository, this is the branch that will + be checked out. + --branch can also take tags and detaches the HEAD at that commit + in the resulting repository. @@ -323,6 +326,11 @@ objects from the source repository into a pack in the cloned repository.--depth option, this is the default, unless --no-single-branch is given to fetch the histories near the tips of all branches. + Further fetches into the resulting repository will only update the + remote-tracking branch for the branch this option was used for the + initial cloning. If the HEAD at the remote did not point at any + branch when --single-branch clone was made, no remote-tracking + branch is created. @@ -365,7 +373,7 @@ objects from the source repository into a pack in the cloned repository. The (possibly remote) repository to clone from. See the - URLS section below for more information on specifying + URLS section below for more information on specifying repositories. @@ -386,14 +394,17 @@ objects from the source repository into a pack in the cloned repository. - -GIT URLS<anchor id="URLS" xreflabel="[URLS]"/> + +GIT URLS<anchor id="git-clone(1)_URLS" xreflabel="[URLS]"/> In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git supports ssh, git, http, and https protocols (in addition, ftp, +and ftps can be used for fetching and rsync can be used for fetching +and pushing, but these are inefficient and deprecated; do not use +them). +The following syntaxes may be used with them: @@ -500,7 +511,7 @@ configuration section of the form: "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL. - + Examples @@ -543,8 +554,8 @@ Create a repository on the kernel.org machine that borrows from Linus: - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-column.xml b/doc/source/en/TortoiseGit/git_doc/git-column.xml new file mode 100644 index 000000000..6f8618e79 --- /dev/null +++ b/doc/source/en/TortoiseGit/git_doc/git-column.xml @@ -0,0 +1,112 @@ + + + + + git-column(1) + +git-column(1) + + +NAME +git-column - Display data in columns + + +SYNOPSIS +
+git column [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>] + [--indent=<string>] [--nl=<string>] [--padding=<n>] +
+ + +DESCRIPTION +This command formats its input into multiple columns. + + +OPTIONS + + + +--command=<name> + + + + Look up layout mode using configuration variable column.<name> and + column.ui. + + + + + +--mode=<mode> + + + + Specify layout mode. See configuration variable column.ui for option + syntax. + + + + + +--raw-mode=<n> + + + + Same as --mode but take mode encoded as a number. This is mainly used + by other commands that have already parsed layout mode. + + + + + +--width=<width> + + + + Specify the terminal width. By default git column will detect the + terminal width, or fall back to 80 if it is unable to do so. + + + + + +--indent=<string> + + + + String to be printed at the beginning of each line. + + + + + +--nl=<N> + + + + String to be printed at the end of each line, + including newline character. + + + + + +--padding=<N> + + + + The number of spaces between columns. One space by default. + + + + + + +Author +Written by Nguyen Thai Ngoc Duy <pclouds@gmail.com> + + +GIT +Part of the suite + + diff --git a/doc/source/en/TortoiseGit/git_doc/git-commit-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-commit-tree.xml index fbe6be994..5a54123eb 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-commit-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-commit-tree.xml @@ -1,25 +1,23 @@ - + -
- + git-commit-tree(1) git-commit-tree(1) - - + NAME git-commit-tree - Create a new commit object - + SYNOPSIS
git commit-tree <tree> [(-p <parent>)…] < changelog git commit-tree [(-p <parent>)…] [(-m <message>)…] [(-F <file>)…] <tree>
- + DESCRIPTION This is usually not what an end user wants to run directly. See instead. @@ -39,7 +37,7 @@ tend to just write the result to the file that is pointed at by .git/HEAD, so that we can always see what the last committed state was. - + OPTIONS @@ -68,7 +66,7 @@ state was. - A paragraph in the commig log message. This can be given more than + A paragraph in the commit log message. This can be given more than once and each <message> becomes its own paragraph. @@ -86,7 +84,7 @@ state was. - + Commit Information A commit encapsulates: @@ -126,7 +124,7 @@ that file does not exist). entry is not provided via "<" redirection, git commit-tree will just wait for one to be entered and terminated with ^D. - + DATE FORMATS The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats: @@ -171,42 +169,7 @@ ISO 8601 - -Diagnostics - - - -You don't exist. Go away! - - - - The passwd(5) gecos field couldn't be read - - - - - -Your parents must have hated you! - - - - The passwd(5) gecos field is longer than a giant static buffer. - - - - - -Your sysadmin must hate you! - - - - The passwd(5) name field is longer than a giant static buffer. - - - - - - + Discussion At the core level, git is character encoding agnostic. @@ -275,16 +238,16 @@ message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation. - + FILES /etc/mailname - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-commit.xml b/doc/source/en/TortoiseGit/git_doc/git-commit.xml index 89d3d7868..f796a61f3 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-commit.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-commit.xml @@ -1,18 +1,16 @@ - + -
- + git-commit(1) git-commit(1) - - + NAME git-commit - Record changes to the repository - + SYNOPSIS
git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] @@ -20,10 +18,10 @@ [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--status | --no-status] - [-i | -o] [--] [<file>…] + [-i | -o] [-S[<keyid>]] [--] [<file>…]
- + DESCRIPTION Stores the current contents of the index in a new commit along with a log message from the user describing the changes. @@ -74,7 +72,7 @@ commit by giving the same set of parameters (options and paths). If you make a commit and then find a mistake immediately after that, you can recover from it with git reset. - + OPTIONS @@ -189,6 +187,16 @@ that, you can recover from it with git reset. +--branch + + + + Show the branch and tracking info even in short-format. + + + + + --porcelain @@ -201,8 +209,22 @@ that, you can recover from it with git reset. +--long + + + + When doing a dry-run, give the output in a the long-format. + Implies --dry-run. + + + + + -z + +--null + When showing short or porcelain status output, terminate @@ -371,6 +393,18 @@ that, you can recover from it with git reset. +--no-edit + + + + Use the selected commit message without launching an editor. + For example, git commit --amend --no-edit amends a commit + without changing its commit message. + + + + + --amend @@ -396,6 +430,16 @@ FROM UPSTREAM REBASE" section in .) +--no-post-rewrite + + + + Bypass the post-rewrite hook. + + + + + -i @@ -535,6 +579,19 @@ configuration variable documented in . +-S[<keyid>] + + +--gpg-sign[=<keyid>] + + + + GPG-sign commit. + + + + + -- @@ -559,7 +616,7 @@ configuration variable documented in . - + DATE FORMATS The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables and the --date option @@ -605,7 +662,7 @@ ISO 8601 - + EXAMPLES When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area @@ -672,13 +729,15 @@ alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command 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. +The text up to the first blank line in a commit message is treated +as the commit title, and that title is used throughout git. +For example, turns a commit into email, and it uses +the title on the Subject line and the rest of the commit in the body. At the core level, git is character encoding agnostic. @@ -746,20 +805,39 @@ message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation. - + ENVIRONMENT AND CONFIGURATION VARIABLES The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order). See for details. - + HOOKS This command can run commit-msg, prepare-commit-msg, pre-commit, and post-commit hooks. See for more information. - + +FILES + + + +$GIT_DIR/COMMIT_EDITMSG + + + + This file contains the commit message of a commit in progress. + If git commit exits due to an error before creating a commit, + any commit message that has been provided by the user (e.g., in + an editor session) will be available in this file, but will be + overwritten by the next invocation of git commit. + + + + + + SEE ALSO , , @@ -767,8 +845,8 @@ information. , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-config.xml b/doc/source/en/TortoiseGit/git_doc/git-config.xml index 8065a8139..aeb50ded9 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-config.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-config.xml @@ -1,18 +1,16 @@ - + -
- + git-config(1) git-config(1) - - + NAME git-config - Get and set repository or global options - + SYNOPSIS
git config [<file-option>] [type] [-z|--null] name [value [value_regex]] @@ -31,7 +29,7 @@ git config [<file-option>] -e | --edit
- + 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 @@ -41,7 +39,7 @@ 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 also ). +prepend a single exclamation mark in front (see also ). The type specifier can be either --int or --bool, to 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, @@ -51,12 +49,13 @@ checks or transformations are performed on the value. When reading, the values are read from the system, global and repository local configuration files by default, and options --system, --global, --local and --file <filename> can be -used to tell the command to read from only that location (see ). +used to tell the command to read from only that location (see ). When writing, the new value is written to the repository local configuration file by default, and options --system, --global, --file <filename> can be used to tell the command to write to that location (you can say --local but that is the default). -This command will fail (with exit code ret) if: +This command will fail with non-zero status upon error. Some exit +codes are: @@ -85,23 +84,18 @@ you try to unset an option which does not exist (ret=5), -you try to unset/set an option for which multiple lines match (ret=5), +you try to unset/set an option for which multiple lines match (ret=5), or -you try to use an invalid regexp (ret=6), or - - - - -you use --global option without $HOME being properly set (ret=128). +you try to use an invalid regexp (ret=6). On success, the command returns the exit code 0. - + OPTIONS @@ -170,12 +164,13 @@ you use --global option without $HOME being properly set (r - For writing options: write to global ~/.gitconfig file rather than - the repository .git/config. + For writing options: write to global /.gitconfig file rather than + the repository .git/config, write to $XDG_CONFIG_HOME/git/config file + if this file exists and the /.gitconfig file doesn't. -For reading options: read only from global ~/.gitconfig rather than -from all available files. -See also . +For reading options: read only from global ~/.gitconfig and from +$XDG_CONFIG_HOME/git/config rather than from all available files. +See also . @@ -189,7 +184,7 @@ from all available files. For reading options: read only from system-wide $(prefix)/etc/gitconfig rather than from all available files. -See also . +See also . @@ -384,9 +379,9 @@ rather than from all available files. - + FILES -If not set explicitly with --file, there are three files where +If not set explicitly with --file, there are four files where git config will search for configuration options: @@ -412,6 +407,21 @@ $GIT_DIR/config +$XDG_CONFIG_HOME/git/config + + + + Second user-specific configuration file. If $XDG_CONFIG_HOME is not set + or empty, $HOME/.config/git/config will be used. Any single-valued + variable set in this file will be overwritten by whatever is in + ~/.gitconfig. It is a good idea not to create this file if + you sometimes use older versions of Git, as support for this + file was added fairly recently. + + + + + $(prefix)/etc/gitconfig @@ -434,7 +444,7 @@ variables. The --global and the --system - + ENVIRONMENT @@ -450,9 +460,9 @@ GIT_CONFIG -See also . +See also . - + EXAMPLES Given a .git/config like this: # @@ -470,7 +480,7 @@ GIT_CONFIG renames = true ; Proxy settings [core] - gitproxy="proxy-command" for kernel.org + gitproxy=proxy-command for kernel.org gitproxy=default-proxy ; for all the rest you can set the filemode to true with % git config core.filemode true @@ -500,7 +510,7 @@ i.e. the one without a "for …" postfix, do something like this: 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-command" for example.com' +% git config --add core.gitproxy '"proxy-command" for example.com' An example to use customized color from the configuration in your script: #!/bin/sh @@ -508,7 +518,7 @@ WS=$(git config --get-color color.diff.whitespace "blue reverse") RESET=$(git config --get-color "" "reset") echo "${WS}your whitespace color or blue reverse${RESET}" - + CONFIGURATION FILE The git configuration file contains a number of variables that affect the git command's behavior. The .git/config file in each repository @@ -523,7 +533,7 @@ dot-separated segment and the section name is everything before the last dot. The variable names are case-insensitive, allow only alphanumeric characters and -, and must start with an alphabetic character. 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, @@ -577,7 +587,7 @@ char sequences are valid. customary UNIX fashion. Some variables may require a special value format.
-
+
Includes You can include one config file from another by setting the special include.path variable to the name of the file to be included. The @@ -585,11 +595,11 @@ included file is expanded immediately, as if its contents had been found at the location of the include directive. If the value of the include.path variable is a relative path, the path is considered to be relative to the configuration file in which the include directive was -found. The value of include.path is subject to tilde expansion: {tilde}/ -is expanded to the value of $HOME, and {tilde}user/ to the specified +found. The value of include.path is subject to tilde expansion: ~/ +is expanded to the value of $HOME, and ~user/ to the specified user's home directory. See below for examples.
-
+
Example # Core variables [core] @@ -611,7 +621,7 @@ user's home directory. See below for examples. path = foo ; expand "foo" relative to the current file path = ~/foo ; expand "foo" in your $HOME directory
-
+
Variables Note that this list is non-comprehensive and not necessarily complete. For command-specific variables, you will find a more detailed description @@ -685,9 +695,11 @@ statusHints - Directions on how to stage/unstage/add shown in the - output of and the template shown - when writing commit messages. + Show directions on how to proceed from the current + state in the output of , in + the template shown when writing commit messages in + , and in the help message shown + by when switching branch. @@ -737,6 +749,17 @@ detachedHead + + +amWorkDir + + + + Advice that shows the location of the patch file when + fails to apply it. + + + @@ -793,6 +816,22 @@ is created. +core.precomposeunicode + + + + This option is only used by Mac OS implementation of git. + When core.precomposeunicode=true, git reverts the unicode decomposition + of filenames done by Mac OS. This is useful when sharing a repository + between Mac OS and Linux or Windows. + (Git for Windows 1.7.10 or higher is needed, or git under cygwin 1.7). + When false, file names are handled fully transparent by git, + which is backward compatible with older versions of git. + + + + + core.trustctime @@ -1197,7 +1236,9 @@ core.excludesfile .git/info/exclude, git looks into this file for patterns of files which are not meant to be tracked. "~/" is expanded to the value of $HOME and "~user/" to the specified user's - home directory. See . + home directory. Its default value is $XDG_CONFIG_HOME/git/ignore. + If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore + is used instead. See . @@ -1226,7 +1267,9 @@ core.attributesfile In addition to .gitattributes (per-directory) and .git/info/attributes, git looks into this file for attributes (see ). Path expansions are made the same - way as for core.excludesfile. + way as for core.excludesfile. Its default value is + $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not + set or empty, $HOME/.config/git/attributes is used instead. @@ -1270,14 +1313,14 @@ core.pager LESS variable to some other value. Alternately, these settings can be overridden on a project or global basis by setting the core.pager option. - Setting core.pager has no affect on the LESS + Setting core.pager has no effect on the LESS environment variable behaviour above, so if you want to override git's default settings this way, you need to be explicit. For example, to disable the S option in a backward compatible manner, set core.pager - to less -+$LESS -FRX. This will be passed to the - shell by git, which will translate the final command to - LESS=FRSX less -+FRSX -FRX. + to less -+S. This will be passed to the shell by + git, which will translate the final command to + LESS=FRSX less -+S. @@ -1309,8 +1352,9 @@ core.whitespace -indent-with-non-tab treats a line that is indented with 8 or more - space characters as an error (not enabled by default). +indent-with-non-tab treats a line that is indented with space + characters instead of the equivalent tabs as an error (not enabled by + default). @@ -1935,6 +1979,134 @@ color.ui +column.ui + + + + Specify whether supported commands should output in columns. + This variable consists of a list of tokens separated by spaces + or commas: + + + + +always + + + + always show in columns + + + + + +never + + + + never show in columns + + + + + +auto + + + + show in columns if the output is to the terminal + + + + + +column + + + + fill columns before rows (default) + + + + + +row + + + + fill rows before columns + + + + + +plain + + + + show in one column + + + + + +dense + + + + make unequal size columns to utilize more space + + + + + +nodense + + + + make equal size columns + + + + +This option defaults to never. + + + + +column.branch + + + + Specify whether to output branch listing in git branch in columns. + See column.ui for details. + + + + + +column.status + + + + Specify whether to output untracked files in git status in columns. + See column.ui for details. + + + + + +column.tag + + + + Specify whether to output tag listing in git tag in columns. + See column.ui for details. + + + + + commit.status @@ -2121,7 +2293,18 @@ diff.statGraphWidth Limit the width of the graph part in --stat output. If set, applies - to all commands generating --stat outuput except format-patch. + to all commands generating --stat output except format-patch. + + + + + +diff.context + + + + Generate diffs with <n> lines of context instead of the default + of 3. This value is overridden by the -U option. @@ -2265,6 +2448,33 @@ diff.suppressBlankEmpty +diff.submodule + + + + Specify the format in which differences in submodules are + shown. The "log" format lists the commits in the range like + summary does. The "short" format + format just shows the names of the commits at the beginning + and end of the range. Defaults to short. + + + + + +diff.wordRegex + + + + A POSIX Extended Regular Expression used to determine what is a "word" + when performing word-by-word difference calculations. Character + sequences that match the regular expression are "words", all other + characters are ignorable whitespace. + + + + + diff.<driver>.command @@ -2386,19 +2596,6 @@ difftool.prompt -diff.wordRegex - - - - A POSIX Extended Regular Expression used to determine what is a "word" - when performing word-by-word difference calculations. Character - sequences that match the regular expression are "words", all other - characters are ignorable whitespace. - - - - - fetch.recurseSubmodules @@ -2923,11 +3120,26 @@ grep.lineNumber +grep.patternType + + + + Set the default matching behavior. Using a value of basic, extended, + fixed, or perl will enable the --basic-regexp, --extended-regexp, + --fixed-strings, or --perl-regexp option accordingly, while the + value default will return to the default matching behavior. + + + + + grep.extendedRegexp - If set to true, enable --extended-regexp option by default. + If set to true, enable --extended-regexp option by default. This + option is ignored when the grep.patternType option is set to a value + other than default. @@ -3666,11 +3878,11 @@ merge.defaultToUpstream If merge is called without any commit argument, merge the upstream branches configured for the current branch by using their last - observed values stored in their remote tracking branches. + observed values stored in their remote-tracking branches. The values of the branch.<current branch>.merge that name the branches at the remote named by branch.<current branch>.remote are consulted, and then they are mapped via remote.<remote>.fetch - to their corresponding remote tracking branches, and the tips of + to their corresponding remote-tracking branches, and the tips of these tracking branches are merged. @@ -4191,19 +4403,31 @@ push.default -matching - push all matching branches. - All branches having the same name in both ends are considered to be - matching. This is the default. +matching - push all branches having the same name in both ends. + This is for those who prepare all the branches into a publishable + shape and then push them out with a single command. It is not + appropriate for pushing into a repository shared by multiple users, + since locally stalled branches will attempt a non-fast forward push + if other users updated the branch. + + This is currently the default, but Git 2.0 will change the default + to simple. upstream - push the current branch to its upstream branch. + With this, git push will update the same remote ref as the one which + is merged by git pull, making push and pull symmetrical. + See "branch.<name>.merge" for how to configure the upstream branch. -tracking - deprecated synonym for upstream. +simple - like upstream, but refuses to push if the upstream + branch's name is different from the local one. This is the safest + option and is well-suited for beginners. It will become the default + in Git 2.0. @@ -4212,6 +4436,11 @@ push.default +The simple, current and upstream modes are for those who want to +push out a single branch after finishing work, even when the other +branches are not yet ready to be pushed out. If you are working with +other people to push into the same shared repository, you would want +to use one of these. @@ -4918,8 +5147,8 @@ web.browser
- + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-count-objects.xml b/doc/source/en/TortoiseGit/git_doc/git-count-objects.xml index a410165ac..04f2c3fbe 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-count-objects.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-count-objects.xml @@ -1,29 +1,27 @@ - + -
- + git-count-objects(1) git-count-objects(1) - - + NAME git-count-objects - Count unpacked number of objects and their disk consumption - + SYNOPSIS
git count-objects [-v]
- + DESCRIPTION This counts the number of unpacked object files and disk space consumed by them, to help you decide when it is a good time to repack. - + OPTIONS @@ -45,8 +43,8 @@ them, to help you decide when it is a good time to repack. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-credential-cache--daemon.xml b/doc/source/en/TortoiseGit/git_doc/git-credential-cache--daemon.xml index 47e867c69..1c93fd31a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-credential-cache--daemon.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-credential-cache--daemon.xml @@ -1,24 +1,22 @@ - + -
- + git-credential-cache--daemon(1) git-credential-cache--daemon(1) - - + NAME -git-credential-cache--daemon - temporarily store user credentials in memory +git-credential-cache--daemon - Temporarily store user credentials in memory - + SYNOPSIS
git credential-cache--daemon <socket>
- + DESCRIPTION You probably don't want to invoke this command yourself; it is started automatically when you use . @@ -27,8 +25,8 @@ for git-credential-cache clients. Clients may store and ret credentials. Each credential is held for a timeout specified by the client; once no credentials are held, the daemon exits. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-credential-cache.xml b/doc/source/en/TortoiseGit/git_doc/git-credential-cache.xml index 60cb6d43f..08f15300d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-credential-cache.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-credential-cache.xml @@ -1,22 +1,20 @@ - + -
- + git-credential-cache(1) git-credential-cache(1) - - + NAME -git-credential-cache - helper to temporarily store passwords in memory +git-credential-cache - Helper to temporarily store passwords in memory - + SYNOPSIS git config credential.helper 'cache [options]' - + DESCRIPTION This command caches credentials in memory for use by future git programs. The stored credentials never touch the disk, and are forgotten @@ -26,7 +24,7 @@ domain socket, restricted to the current user by filesystem permissions. or EXAMPLES below. - + OPTIONS @@ -55,13 +53,13 @@ be used as a credential helper by other parts of git. See - + CONTROLLING THE DAEMON If you would like the daemon to exit early, forgetting all cached credentials before their timeout, you can issue an exit action: git credential-cache exit - + EXAMPLES The point of this helper is to reduce the number of times you must type your username or password. For example: @@ -77,8 +75,8 @@ $ git push http://example.com/repo.git variable (this example drops the cache time to 5 minutes): $ git config credential.helper 'cache --timeout=300' - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-credential-store.xml b/doc/source/en/TortoiseGit/git_doc/git-credential-store.xml index f6d7f9313..cff85d897 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-credential-store.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-credential-store.xml @@ -1,22 +1,20 @@ - + -
- + git-credential-store(1) git-credential-store(1) - - + NAME -git-credential-store - helper to store credentials on disk +git-credential-store - Helper to store credentials on disk - + SYNOPSIS git config credential.helper 'store [options]' - + DESCRIPTION Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions. If this is not an acceptable @@ -28,7 +26,7 @@ git programs. be used as a credential helper by other parts of git. See or EXAMPLES below. - + OPTIONS @@ -46,7 +44,7 @@ be used as a credential helper by other parts of git. See - + EXAMPLES The point of this helper is to reduce the number of times you must type your username or password. For example: @@ -59,7 +57,7 @@ Password: <type your password> $ git push http://example.com/repo.git [your credentials are used automatically] - + STORAGE FORMAT The .git-credentials file is stored in plaintext. Each credential is stored on its own line as a URL like: @@ -71,8 +69,8 @@ username (if we already have one) match, then the password is returned to git. See the discussion of configuration in for more information. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-credential.xml b/doc/source/en/TortoiseGit/git_doc/git-credential.xml new file mode 100644 index 000000000..e7688835b --- /dev/null +++ b/doc/source/en/TortoiseGit/git_doc/git-credential.xml @@ -0,0 +1,196 @@ + + + + + git-credential(1) + +git-credential(1) + + +NAME +git-credential - Retrieve and store user credentials + + +SYNOPSIS +git credential <fill|approve|reject> + + +DESCRIPTION +Git has an internal interface for storing and retrieving credentials +from system-specific helpers, as well as prompting the user for +usernames and passwords. The git-credential command exposes this +interface to scripts which may want to retrieve, store, or prompt for +credentials in the same manner as git. The design of this scriptable +interface models the internal C API; see +link:technical/api-credentials.txt[the git credential API] for more +background on the concepts. +git-credential takes an "action" option on the command-line (one of +fill, approve, or reject) and reads a credential description +on stdin (see INPUT/OUTPUT FORMAT). +If the action is fill, git-credential will attempt to add "username" +and "password" attributes to the description by reading config files, +by contacting any configured credential helpers, or by prompting the +user. The username and password attributes of the credential +description are then printed to stdout together with the attributes +already provided. +If the action is approve, git-credential will send the description +to any configured credential helpers, which may store the credential +for later use. +If the action is reject, git-credential will send the description to +any configured credential helpers, which may erase any stored +credential matching the description. +If the action is approve or reject, no output should be emitted. + + +TYPICAL USE OF GIT CREDENTIAL +An application using git-credential will typically use git +credential following these steps: + + + +Generate a credential description based on the context. + +For example, if we want a password for +https://example.com/foo.git, we might generate the following +credential description (don't forget the blank line at the end; it +tells git credential that the application finished feeding all the +infomation it has): +protocol=https +host=example.com +path=foo.git + + + +Ask git-credential to give us a username and password for this + description. This is done by running git credential fill, + feeding the description from step (1) to its standard input. The complete + credential description (including the credential per se, i.e. the + login and password) will be produced on standard output, like: + +protocol=https +host=example.com +username=bob +password=secr3t +In most cases, this means the attributes given in the input will be +repeated in the output, but git may also modify the credential +description, for example by removing the path attribute when the +protocol is HTTP(s) and credential.useHttpPath is false. +If the git credential knew about the password, this step may +not have involved the user actually typing this password (the +user may have typed a password to unlock the keychain instead, +or no user interaction was done if the keychain was already +unlocked) before it returned password=secr3t. + + + +Use the credential (e.g., access the URL with the username and + password from step (2)), and see if it's accepted. + + + + +Report on the success or failure of the password. If the + credential allowed the operation to complete successfully, then + it can be marked with an "approve" action to tell git + credential to reuse it in its next invocation. If the credential + was rejected during the operation, use the "reject" action so + that git credential will ask for a new password in its next + invocation. In either case, git credential should be fed with + the credential description obtained from step (2) (which also + contain the ones provided in step (1)). + + + + + +INPUT/OUTPUT FORMAT +git credential reads and/or writes (depending on the action used) +credential information in its standard input/output. This information +can correspond either to keys for which git credential will obtain +the login/password information (e.g. host, protocol, path), or to the +actual credential data to be obtained (login/password). +The credential is split into a set of named attributes, with one +attribute per line. Each attribute is +specified by a key-value pair, separated by an = (equals) sign, +followed by a newline. The key may contain any bytes except =, +newline, or NUL. The value may contain any bytes except newline or NUL. +In both cases, all bytes are treated as-is (i.e., there is no quoting, +and one cannot transmit a value with newline or NUL in it). The list of +attributes is terminated by a blank line or end-of-file. +Git understands the following attributes: + + + +protocol + + + + The protocol over which the credential will be used (e.g., + https). + + + + + +host + + + + The remote hostname for a network credential. + + + + + +path + + + + The path with which the credential will be used. E.g., for + accessing a remote https repository, this will be the + repository's path on the server. + + + + + +username + + + + The credential's username, if we already have one (e.g., from a + URL, from the user, or from a previously run helper). + + + + + +password + + + + The credential's password, if we are asking it to be stored. + + + + + +url + + + + When this special attribute is read by git credential, the + value is parsed as a URL and treated as if its constituent parts + were read (e.g., url=https://example.com would behave as if + protocol=https and host=example.com had been provided). This + can help callers avoid parsing URLs themselves. Note that any + components which are missing from the URL (e.g., there is no + username in the example above) will be set to empty; if you want + to provide a URL and override some attributes, provide the URL + attribute first, followed by any overrides. + + + + + + diff --git a/doc/source/en/TortoiseGit/git_doc/git-cvsexportcommit.xml b/doc/source/en/TortoiseGit/git_doc/git-cvsexportcommit.xml index 208a848f4..06e21919a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cvsexportcommit.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cvsexportcommit.xml @@ -1,25 +1,23 @@ - + -
- + git-cvsexportcommit(1) git-cvsexportcommit(1) - - + NAME git-cvsexportcommit - Export a single commit to a CVS checkout - + SYNOPSIS
git cvsexportcommit [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
- + DESCRIPTION Exports a commit from GIT to a CVS checkout, making it easier to merge patches from a git repository into a CVS repository. @@ -33,7 +31,7 @@ by default. If the commit is a merge commit, you must tell git cvsexportcommit what parent the changeset should be done against. - + OPTIONS @@ -170,7 +168,7 @@ parent the changeset should be done against. - + CONFIGURATION @@ -185,7 +183,7 @@ cvsexportcommit.cvsdir - + EXAMPLES @@ -219,8 +217,8 @@ $ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-cvsimport.xml b/doc/source/en/TortoiseGit/git_doc/git-cvsimport.xml index 42fc6a6ec..3efa5c3e8 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cvsimport.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cvsimport.xml @@ -1,18 +1,16 @@ - + -
- + git-cvsimport(1) git-cvsimport(1) - - + NAME git-cvsimport - Salvage your data out of another SCM people love to hate - + SYNOPSIS
git cvsimport [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>] @@ -22,14 +20,14 @@ [-r <remote>] [-R] [<CVS_module>]
- + DESCRIPTION Imports a CVS repository into git. It will either create a new repository, or incrementally import into an existing one. Splitting the CVS log into patch sets is done by cvsps. At least version 2.1 is required. WARNING: for certain situations the import leads to incorrect results. -Please see the section ISSUES for further reference. +Please see the section ISSUES for further reference. You should never do any work of your own on the branches that are created by git cvsimport. By default initial import will create and populate a "master" branch from the CVS repository's main branch which you're free @@ -42,7 +40,7 @@ probably want to make a bare clone of the imported repository, and use the clone as the shared repository. See . - + OPTIONS @@ -266,13 +264,15 @@ the old cvs2git tool. CVS by default uses the Unix username when writing its commit logs. Using this option and an author-conv-file - in this format + maps the name recorded in CVS to author name, e-mail and + optional timezone: exon=Andreas Ericsson <ae@op5.se> - spawn=Simon Pawn <spawn@frog-pond.org> + spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago git cvsimport will make it appear as those authors had their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly -all along. +all along. If a timezone is specified, GIT_AUTHOR_DATE will +have the corresponding offset applied. For convenience, this data is saved to $GIT_DIR/cvs-authors each time the -A option is provided and read from that same file each time git cvsimport is run. @@ -311,13 +311,13 @@ messages, bug-tracking systems, email archives, and the like. - + OUTPUT If -v is specified, the script reports what it is doing. Otherwise, success is indicated the Unix way, i.e. by simply exiting with a zero exit status. - + ISSUES Problems related to timestamps: @@ -387,8 +387,8 @@ parsecvs, http://cgit.freedesktop.org/~keithp/parsecvs - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-cvsserver.xml b/doc/source/en/TortoiseGit/git_doc/git-cvsserver.xml index cb92a1283..35f8adc4e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-cvsserver.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-cvsserver.xml @@ -1,18 +1,16 @@ - + -
- + git-cvsserver(1) git-cvsserver(1) - - + NAME git-cvsserver - A CVS server emulator for git - + SYNOPSIS SSH:
@@ -28,7 +26,7 @@ git-cvsserver [options] [pserver|server] [<directory> …]
- + OPTIONS All these options obviously only make sense if enforced by the server side. They have been implemented to resemble the options as @@ -109,7 +107,7 @@ unless --export-all was given, too. - + DESCRIPTION This application is a CVS emulation layer for git. It is highly functional. However, not all methods are implemented, @@ -118,14 +116,14 @@ not all switches are implemented. Testing has been done using both the CLI CVS client, and the Eclipse CVS plugin. Most functionality works fine with both of these clients. - + LIMITATIONS CVS clients cannot tag, branch or perform GIT merges. git-cvsserver maps GIT branches to CVS modules. This is very different from what most CVS users would expect since in CVS modules usually represent one or more directories. - + INSTALLATION @@ -179,7 +177,7 @@ For each repo that you want accessible from CVS you need to edit config in logfile=/path/to/logfile Note: you need to ensure each user that is going to invoke git-cvsserver has write access to the log file and to the database (see -Database Backend. If you want to offer write access over +Database Backend. If you want to offer write access over SSH, the users of course also need write access to the git repository itself. You also need to ensure that each repository is "bare" (without a git index file) for cvs commit to work. See . @@ -225,7 +223,7 @@ Clients should now be able to check out the project. Use the CVS modul - + Database Backend git-cvsserver uses one database per git head (i.e. CVS module) to store information about the repository to maintain consistent @@ -258,7 +256,7 @@ backup) regenerate the database, you should be suspicious of pre-existing CVS sandboxes. You can configure the database backend with the following configuration variables: -
+
Configuring database backend git-cvsserver uses the Perl DBI module. Please also read its documentation if changing these variables, especially @@ -330,8 +328,8 @@ gitcvs.dbTableNamePrefix -All variables can also be set per access method, see above. -
+All variables can also be set per access method, see above. +
Variable substitution In dbdriver and dbuser you can use the following variables: @@ -394,7 +392,7 @@ gitcvs.dbTableNamePrefix
- + ENVIRONMENT These variables obviate the need for command-line options in some circumstances, allowing easier restricted usage through git-shell. @@ -405,7 +403,7 @@ git-cvsserver, as described above. When these environment variables are set, the corresponding command-line arguments may not be used. - + Eclipse CVS Client Notes To get a checkout with the Eclipse CVS client: @@ -444,7 +442,7 @@ offer. In that case CVS_SERVER is ignored, and you will have to replace the cvs utility on the server with git-cvsserver or manipulate your .bashrc so that calling cvs effectively calls git-cvsserver. - + Clients known to work @@ -469,13 +467,13 @@ TortoiseCVS - + Operations supported All the operations required for normal use are supported, including checkout, diff, status, update, log, add, remove, commit. Legacy monitoring operations are not supported (edit, watch and related). Exports and tagging (tags and branches) are not supported at this stage. -
+
CRLF Line Ending Conversions By default the server leaves the -k mode blank for all files, which causes the CVS client to treat them as a text files, subject @@ -497,12 +495,12 @@ defaults by setting gitcvs.usecrlfattr to true, and gitcvs.allbinary to "guess".
- + Dependencies git-cvsserver depends on DBD::SQLite. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-daemon.xml b/doc/source/en/TortoiseGit/git_doc/git-daemon.xml index eaecd9677..820cdda3b 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-daemon.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-daemon.xml @@ -1,18 +1,16 @@ - + -
- + git-daemon(1) git-daemon(1) - - + NAME git-daemon - A really simple server for git repositories - + SYNOPSIS
git daemon [--verbose] [--syslog] [--export-all] @@ -23,11 +21,12 @@ [--reuseaddr] [--detach] [--pid-file=<file>] [--enable=<service>] [--disable=<service>] [--allow-override=<service>] [--forbid-override=<service>] + [--access-hook=<path>] [--inetd | [--listen=<host_or_ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]] [<directory>…]
- + DESCRIPTION A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection asking for a service, and will serve @@ -44,7 +43,7 @@ from git fetch, git pull, and An upload-archive also exists to serve git archive. - + OPTIONS @@ -334,6 +333,27 @@ the facility of inet daemon to achieve the same before spawning +--access-hook=<path> + + + + Every time a client connects, first run an external command + specified by the <path> with service name (e.g. "upload-pack"), + path to the repository, hostname (%H), canonical hostname + (%CH), ip address (%IP), and tcp port (%P) as its command line + arguments. The external command can decide to decline the + service by exiting with a non-zero status (or to allow it by + exiting with a zero status). It can also look at the $REMOTE_ADDR + and $REMOTE_PORT environment variables to learn about the + requestor when making this decision. + +The external command can optionally write a single line to its +standard output to be sent to the requestor as an error message when +it declines the service. + + + + <directory> @@ -346,7 +366,7 @@ the facility of inet daemon to achieve the same before spawning - + SERVICES These services can be globally enabled/disabled using the command line options of this command. If a finer-grained @@ -392,14 +412,14 @@ receive-pack can push anything into the repository, including removal of refs). This is solely meant for a closed LAN setting where everybody is friendly. This service can be - enabled by daemon.receivepack configuration item to + enabled by setting daemon.receivepack configuration item to true. - + EXAMPLES @@ -490,15 +510,15 @@ selectively enable/disable services per repository - + ENVIRONMENT git daemon will set REMOTE_ADDR to the IP address of the client that connected to it, if the IP address is available. REMOTE_ADDR will be available in the environment of hooks called when services are performed. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-describe.xml b/doc/source/en/TortoiseGit/git_doc/git-describe.xml index 4b9cea498..d09f9ecf6 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-describe.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-describe.xml @@ -1,25 +1,23 @@ - + -
- + git-describe(1) git-describe(1) - - + NAME git-describe - Show the most recent tag that is reachable from a commit - + SYNOPSIS
git describe [--all] [--tags] [--contains] [--abbrev=<n>] <committish>… git describe [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
- + DESCRIPTION The command finds the most recent tag that is reachable from a commit. If the tag points to the commit, then only the tag is @@ -30,7 +28,7 @@ abbreviated object name of the most recent commit. annotated tags. For more information about creating annotated tags see the -a and -s options to . - + OPTIONS @@ -62,7 +60,7 @@ see the -a and -s options to . Instead of using only the annotated tags, use any ref - found in .git/refs/. This option enables matching + found in refs/ namespace. This option enables matching any known branch, remote-tracking branch, or lightweight tag. @@ -74,7 +72,7 @@ see the -a and -s options to . Instead of using only the annotated tags, use any tag - found in .git/refs/tags. This option enables matching + found in refs/tags namespace. This option enables matching a lightweight (non-annotated) tag. @@ -180,7 +178,7 @@ see the -a and -s options to . - + EXAMPLES With something like git.git current tree, I get: [torvalds@g5 git]$ git describe parent @@ -216,7 +214,7 @@ git repository may have new commits whose object names begin with 975b that did not exist back then, and "-g975b" suffix alone may not be sufficient to disambiguate these commits. - + SEARCH STRATEGY For each committish supplied, git describe will first look for a tag which tags exactly that commit. Annotated tags will always @@ -233,8 +231,8 @@ 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. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-diff-files.xml b/doc/source/en/TortoiseGit/git_doc/git-diff-files.xml index 4b859940c..2ed00ef1d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-diff-files.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-diff-files.xml @@ -1,31 +1,29 @@ - + -
- + git-diff-files(1) git-diff-files(1) - - + NAME git-diff-files - Compares files in the working tree and the index - + SYNOPSIS
git diff-files [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>…]
- + DESCRIPTION Compares the files in the working tree and the index. When paths are specified, compares only those named paths. Otherwise all entries in the index are compared. The output format is the same as for git diff-index and git diff-tree. - + OPTIONS @@ -121,7 +119,7 @@ same as for git diff-index and git diff-tree<width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -319,7 +317,8 @@ any of those replacements occurred. the commits in the range like summary does. Omitting the --submodule option or specifying --submodule=short, uses the short format. This format just shows the names of the commits - at the beginning and end of the range. + at the beginning and end of the range. Can be tweaked via the + diff.submodule configuration variable. @@ -554,7 +553,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -973,7 +976,7 @@ omit diff output for unmerged entries and just show "Unmerged". - + Raw output format The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar. @@ -1164,7 +1167,7 @@ and it is out of sync with the index. in pathnames are represented as \t, \n, and \\, respectively. - + diff format for merges "git-diff-tree", "git-diff-files" and "git-diff --raw" can take -c or --cc option @@ -1202,7 +1205,7 @@ single path, only for "dst" Note that combined diff lists only files which were modified from all parents. - + Generating patches with -p When "git-diff-index", "git-diff-tree", or "git-diff-files" are run with a -p option, "git diff" without the --raw option, or @@ -1277,7 +1280,7 @@ rename to a - + combined diff format Any diff-generating command can take the -c` or --cc option to produce a combined diff when showing a merge. This is the default @@ -1386,7 +1389,7 @@ two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version"). - + other diff formats The --summary option describes newly added, deleted, renamed and copied files. The --stat option adds diffstat(1) graph to the @@ -1492,8 +1495,8 @@ a single-path record or a rename/copy record without reading ahead. After reading added and deleted lines, reading up to NUL would yield the pathname, but if that is NUL, the record will show two paths. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-diff-index.xml b/doc/source/en/TortoiseGit/git_doc/git-diff-index.xml index a9c7df2b8..6446f992a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-diff-index.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-diff-index.xml @@ -1,24 +1,22 @@ - + -
- + git-diff-index(1) git-diff-index(1) - - + NAME git-diff-index - Compares content and mode of blobs between the index and repository - + SYNOPSIS
git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>…]
- + DESCRIPTION Compares the content and mode of the blobs found via a tree object with the content of the current index and, optionally @@ -26,7 +24,7 @@ ignoring the stat state of the file on disk. When paths are specified, compares only those named paths. Otherwise all entries in the index are compared. - + OPTIONS @@ -122,7 +120,7 @@ entries in the index are compared. Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overriden by + if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -320,7 +318,8 @@ any of those replacements occurred. the commits in the range like summary does. Omitting the --submodule option or specifying --submodule=short, uses the short format. This format just shows the names of the commits - at the beginning and end of the range. + at the beginning and end of the range. Can be tweaked via the + diff.submodule configuration variable. @@ -555,7 +554,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -957,7 +960,7 @@ of a delete/create pair. - + Raw output format The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar. @@ -1148,7 +1151,7 @@ and it is out of sync with the index. in pathnames are represented as \t, \n, and \\, respectively. - + diff format for merges "git-diff-tree", "git-diff-files" and "git-diff --raw" can take -c or --cc option @@ -1186,7 +1189,7 @@ single path, only for "dst" Note that combined diff lists only files which were modified from all parents. - + Generating patches with -p When "git-diff-index", "git-diff-tree", or "git-diff-files" are run with a -p option, "git diff" without the --raw option, or @@ -1261,7 +1264,7 @@ rename to a - + combined diff format Any diff-generating command can take the -c` or --cc option to produce a combined diff when showing a merge. This is the default @@ -1370,7 +1373,7 @@ two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version"). - + other diff formats The --summary option describes newly added, deleted, renamed and copied files. The --stat option adds diffstat(1) graph to the @@ -1476,14 +1479,14 @@ a single-path record or a rename/copy record without reading ahead. After reading added and deleted lines, reading up to NUL would yield the pathname, but if that is NUL, the record will show two paths. - + Operating Modes You can choose whether you want to trust the index file entirely (using the --cached flag) or ask the diff logic to show any files that don't match the stat state as being "tentatively changed". Both of these operations are very useful indeed. - + Cached Mode If --cached is specified, it allows you to ask: show me the differences between HEAD and the current index @@ -1508,7 +1511,7 @@ nicer for the case where you just want to check where you are. asking yourself "what have I already marked for being committed, and what's the difference to a previous tree". - + Non-cached Mode The "non-cached" mode takes a different approach, and is potentially the more useful of the two in that what it does can't be emulated with @@ -1541,8 +1544,8 @@ tell which file is in which state, since the "has been updated" ones show a valid sha1, and the "not in sync with the index" ones will always have the special all-zero sha1. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-diff-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-diff-tree.xml index 8758a47c4..31a797357 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-diff-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-diff-tree.xml @@ -1,18 +1,16 @@ - + -
- + git-diff-tree(1) git-diff-tree(1) - - + NAME git-diff-tree - Compares the content and mode of blobs found via two tree objects - + SYNOPSIS
git diff-tree [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] @@ -20,14 +18,14 @@ <tree-ish> [<tree-ish>] [<path>…]
- + DESCRIPTION Compares the content and mode of the blobs found via two tree objects. If there is only one <tree-ish> given, the commit is compared with its parents (see --stdin below). Note that git diff-tree can use the tree encapsulated in a commit object. - + OPTIONS @@ -123,7 +121,7 @@ Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overriden by + if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -321,7 +319,8 @@ any of those replacements occurred. the commits in the range like summary does. Omitting the --submodule option or specifying --submodule=short, uses the short format. This format just shows the names of the commits - at the beginning and end of the range. + at the beginning and end of the range. Can be tweaked via the + diff.submodule configuration variable. @@ -556,7 +555,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -1164,6 +1167,17 @@ being displayed. Examples: "--notes=foo" will show only notes from +--show-signature + + + + Check the validity of a signed commit object by passing the signature + to gpg --verify and show the output. + + + + + --no-commit-id @@ -1220,7 +1234,7 @@ being displayed. Examples: "--notes=foo" will show only notes from - + PRETTY FORMATS If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is @@ -1477,6 +1491,21 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +%GG: raw verification message from GPG for a signed commit + + + + +%G?: show either "G" for Good or "B" for Bad for a signed commit + + + + +%GS: show the name of the signer for a signed commit + + + + %gD: reflog selector, e.g., refs/stash@{1} @@ -1607,7 +1636,7 @@ $ git log -2 --pretty=%h 4da45bef - + Limiting Output If you're only interested in differences in a subset of files, for example some architecture-specific files, you might do: @@ -1637,7 +1666,7 @@ Once I do the reference tracking, I'll also make it print out all the HEAD commits it finds, which is even more interesting. in case you care). - + Raw output format The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar. @@ -1828,7 +1857,7 @@ and it is out of sync with the index. in pathnames are represented as \t, \n, and \\, respectively. - + diff format for merges "git-diff-tree", "git-diff-files" and "git-diff --raw" can take -c or --cc option @@ -1866,7 +1895,7 @@ single path, only for "dst" Note that combined diff lists only files which were modified from all parents. - + Generating patches with -p When "git-diff-index", "git-diff-tree", or "git-diff-files" are run with a -p option, "git diff" without the --raw option, or @@ -1941,7 +1970,7 @@ rename to a - + combined diff format Any diff-generating command can take the -c` or --cc option to produce a combined diff when showing a merge. This is the default @@ -2050,7 +2079,7 @@ two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version"). - + other diff formats The --summary option describes newly added, deleted, renamed and copied files. The --stat option adds diffstat(1) graph to the @@ -2156,8 +2185,8 @@ a single-path record or a rename/copy record without reading ahead. After reading added and deleted lines, reading up to NUL would yield the pathname, but if that is NUL, the record will show two paths. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-diff.xml b/doc/source/en/TortoiseGit/git_doc/git-diff.xml index 0108d002d..a42a6ac8d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-diff.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-diff.xml @@ -1,27 +1,26 @@ - + -
- + git-diff(1) git-diff(1) - - + NAME git-diff - Show changes between commits, commit and working tree, etc - + SYNOPSIS
git diff [options] [<commit>] [--] [<path>…] git diff [options] --cached [<commit>] [--] [<path>…] git diff [options] <commit> <commit> [--] [<path>…] +git diff [options] <blob> <blob> git diff [options] [--no-index] [--] <path> <path>
- + DESCRIPTION Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, or changes @@ -87,6 +86,17 @@ directories. This behavior can be forced by --no-index. +git diff [options] <blob> <blob> + + + + This form is to view the differences between the raw + contents of two blob objects. + + + + + git diff [--options] <commit>..<commit> [--] [<path>…] @@ -115,8 +125,7 @@ directories. This behavior can be forced by --no-index. Just in case if you are doing something exotic, it should be noted that all of the <commit> in the above description, except in the last two forms that use ".." notations, can be any -<tree>. The third form (git diff <commit> <commit>) can also -be used to compare two <blob> objects. +<tree>. For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in . However, "diff" is about comparing two endpoints, not ranges, @@ -124,7 +133,7 @@ and the range notations ("<commit>..<commit>" and "<commit>...<commit>") do not mean a range as defined in the "SPECIFYING RANGES" section in . - + OPTIONS @@ -220,7 +229,7 @@ and the range notations ("<commit>..<commit>" and Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overriden by + if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -418,7 +427,8 @@ any of those replacements occurred. the commits in the range like summary does. Omitting the --submodule option or specifying --submodule=short, uses the short format. This format just shows the names of the commits - at the beginning and end of the range. + at the beginning and end of the range. Can be tweaked via the + diff.submodule configuration variable. @@ -656,7 +666,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -1037,7 +1051,7 @@ of a delete/create pair. - + Raw output format The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar. @@ -1228,7 +1242,7 @@ and it is out of sync with the index. in pathnames are represented as \t, \n, and \\, respectively. - + diff format for merges "git-diff-tree", "git-diff-files" and "git-diff --raw" can take -c or --cc option @@ -1266,7 +1280,7 @@ single path, only for "dst" Note that combined diff lists only files which were modified from all parents. - + Generating patches with -p When "git-diff-index", "git-diff-tree", or "git-diff-files" are run with a -p option, "git diff" without the --raw option, or @@ -1341,7 +1355,7 @@ rename to a - + combined diff format Any diff-generating command can take the -c` or --cc option to produce a combined diff when showing a merge. This is the default @@ -1450,7 +1464,7 @@ two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version"). - + other diff formats The --summary option describes newly added, deleted, renamed and copied files. The --stat option adds diffstat(1) graph to the @@ -1556,7 +1570,7 @@ a single-path record or a rename/copy record without reading ahead. After reading added and deleted lines, reading up to NUL would yield the pathname, but if that is NUL, the record will show two paths. - + EXAMPLES @@ -1564,22 +1578,22 @@ the pathname, but if that is NUL, the record will show two Various ways to check your working tree -$ git diff -$ git diff --cached -$ git diff HEAD +$ git diff +$ git diff --cached +$ git diff HEAD - + Changes in the working tree not yet staged for the next commit. - + Changes between the index and your last commit; what you would be committing if you run "git commit" without "-a" option. - + Changes in the working tree since your last commit; what you would be committing if you run "git commit -a" @@ -1593,24 +1607,24 @@ would be committing if you run "git commit -a" Comparing with arbitrary commits -$ git diff test -$ git diff HEAD -- ./test -$ git diff HEAD^ HEAD +$ git diff test +$ git diff HEAD -- ./test +$ git diff HEAD^ HEAD - + Instead of using the tip of the current branch, compare with the tip of "test" branch. - + Instead of comparing with the tip of "test" branch, compare with the tip of the current branch, but limit the comparison to the file "test". - + Compare the version before the last commit and the last commit. @@ -1623,21 +1637,21 @@ Compare the version before the last commit and the last commit. Comparing branches -$ git diff topic master -$ git diff topic..master -$ git diff topic...master +$ git diff topic master +$ git diff topic..master +$ git diff topic...master - + Changes between the tips of the topic and the master branches. - + Same as above. - + Changes that occurred on the master branch since when the topic branch was started off it. @@ -1651,23 +1665,23 @@ branch was started off it. Limiting the diff output -$ git diff --diff-filter=MRC -$ git diff --name-status -$ git diff arch/i386 include/asm-i386 +$ git diff --diff-filter=MRC +$ git diff --name-status +$ git diff arch/i386 include/asm-i386 - + Show only modification, rename and copy, but not addition nor deletion. - + Show only names and the nature of change, but not actual diff output. - + Limit diff output to named subtrees. @@ -1680,16 +1694,16 @@ Limit diff output to named subtrees. Munging the diff output -$ git diff --find-copies-harder -B -C -$ git diff -R +$ git diff --find-copies-harder -B -C +$ git diff -R - + Spend extra cycles to find renames, copies and complete rewrites (very expensive). - + Output diff in reverse. @@ -1699,7 +1713,7 @@ Output diff in reverse. - + SEE ALSO diff(1), , @@ -1708,8 +1722,8 @@ Output diff in reverse. , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-difftool.xml b/doc/source/en/TortoiseGit/git_doc/git-difftool.xml index 5d602dbe6..3a902a4be 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-difftool.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-difftool.xml @@ -1,35 +1,48 @@ - + -
- + git-difftool(1) git-difftool(1) - - + NAME git-difftool - Show changes using common diff tools - + SYNOPSIS
git difftool [<options>] [<commit> [<commit>]] [--] [<path>…]
- + DESCRIPTION git difftool is a git command that allows you to compare and edit files between revisions using common diff tools. git difftool is a frontend to git diff and accepts the same options and arguments. See . - + OPTIONS +-d + + +--dir-diff + + + + Copy the modified files to a temporary location and perform + a directory diff on them. This mode never prompts before + launching the diff tool. + + + + + -y @@ -62,11 +75,9 @@ to git diff and accepts the same options and arguments. See - Use the diff tool specified by <tool>. - Valid diff tools are: - araxis, bc3, deltawalker, diffuse, emerge, ecmerge, gvimdiff, - kdiff3, kompare, meld, opendiff, p4merge, tkdiff, vimdiff and - xxdiff. + Use the diff tool specified by <tool>. Valid values include + emerge, kompare, meld, and vimdiff. Run git difftool --tool-help + for the list of valid <tool> settings. If a diff tool is not specified, git difftool will use the configuration variable diff.tool. If the @@ -94,6 +105,32 @@ with custom merge tool commands and has the same value as $MERGED +--tool-help + + + + Print a list of diff tools that may be used with --tool. + + + + + +--symlinks + + +--no-symlinks + + + + git difftool's default behavior is create symlinks to the + working tree when run in --dir-diff mode. + +Specifying `--no-symlinks` instructs 'git difftool' to create +copies instead. `--no-symlinks` is the default on Windows. + + + + -x <command> @@ -126,7 +163,7 @@ with custom merge tool commands and has the same value as $MERGED See for the full list of supported options. - + CONFIG VARIABLES git difftool falls back to git mergetool config variables when the difftool equivalents have not been defined. @@ -185,7 +222,7 @@ difftool.prompt - + SEE ALSO @@ -220,8 +257,8 @@ difftool.prompt - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-doc.xml b/doc/source/en/TortoiseGit/git_doc/git-doc.xml dissimilarity index 99% index 67557f19a..fa70f4a52 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-doc.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-doc.xml @@ -1 +1 @@ - Git Offical Documentation Git User Manual Git Tutorial Git Command Reference Misc \ No newline at end of file + Git Offical Documentation Git User Manual Git Tutorial Git Command Reference Misc \ No newline at end of file diff --git a/doc/source/en/TortoiseGit/git_doc/git-fast-export.xml b/doc/source/en/TortoiseGit/git_doc/git-fast-export.xml index cc8c8a659..b62b30aad 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fast-export.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fast-export.xml @@ -1,24 +1,22 @@ - + -
- + git-fast-export(1) git-fast-export(1) - - + NAME git-fast-export - Git data exporter - + SYNOPSIS
git fast-export [options] | git fast-import
- + DESCRIPTION This program dumps the given revisions in a form suitable to be piped into git fast-import. @@ -26,7 +24,7 @@ into git fast-import. ), or as a kind of an interactive git filter-branch. - + OPTIONS @@ -191,7 +189,7 @@ marks the same across runs. - + EXAMPLES $ git fast-export --all | (cd /empty/repository && git fast-import) This will export the whole repository and import it into the existing @@ -206,14 +204,14 @@ UTF-8, it would be a one-to-one mirror. referenced by that revision range contains the string refs/heads/master. - + Limitations Since git fast-import cannot tag trees, you will not be able to export the linux-2.6.git repository completely, as it contains a tag referencing a tree instead of a commit. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fast-import.xml b/doc/source/en/TortoiseGit/git_doc/git-fast-import.xml index f1800d0c4..2efce1f12 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fast-import.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fast-import.xml @@ -1,24 +1,22 @@ - + -
- + git-fast-import(1) 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, @@ -35,7 +33,7 @@ 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 @@ -53,6 +51,17 @@ the frontend program in use. +-- done + + + + Terminate with error if there is no done command at the + end of the stream. + + + + + --force @@ -185,9 +194,10 @@ the frontend program in use. - Specify the file descriptor that will be written to - when the cat-blob command is encountered in the stream. - The default behaviour is to write to stdout. + Write responses to cat-blob and ls queries to the + file descriptor <fd> instead of stdout. Allows progress + output intended for the end-user to be separated from other + output. @@ -247,7 +257,7 @@ the frontend program in use. - + 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 @@ -261,7 +271,7 @@ 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 @@ -270,7 +280,7 @@ 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, @@ -288,7 +298,7 @@ branch refs, and does not stop on the first failure. 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 @@ -305,7 +315,7 @@ 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 @@ -319,7 +329,7 @@ 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. -
+
Stream Comments To aid in debugging frontends fast-import ignores any line that begins with # (ASCII pound/hash) up to and including the line @@ -328,7 +338,7 @@ that does not contain an LF and therefore may be used to include any detailed debugging information that might be specific to the frontend and useful when inspecting a fast-import data stream.
-
+
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 @@ -419,7 +429,7 @@ 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 @@ -560,7 +570,7 @@ and control the current import process. More detailed discussion
-
+
<emphasis>commit</emphasis> Create or update a branch with a new commit, recording one logical change to the project. @@ -597,7 +607,7 @@ However it is recommended that a filedeleteall command prec all filemodify, filecopy, filerename and notemodify commands in the same commit, as filedeleteall wipes the branch clean (see below). The LF after the command is optional (it used to be required). -
+
<emphasis>author</emphasis> An author command may optionally appear, if the author information might differ from the committer information. If author is omitted @@ -605,13 +615,13 @@ 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.
-
+
<emphasis>committer</emphasis> 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) +(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> and <email> are free-form and may contain any sequence @@ -621,11 +631,13 @@ that was selected by the --date-format=<fmt> command line option. See Date Formats above for the set of supported formats, and their syntax.
-
+
<emphasis>from</emphasis> 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. +new commit. The state of the tree built at this commit will begin +with the state at the from commit, and be altered by the content +modifications in this 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. @@ -679,9 +691,11 @@ 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.
-
+
<emphasis>merge</emphasis> -Includes one additional ancestor commit. If the from command is +Includes one additional ancestor commit. The additional ancestry +link does not change the way the tree state is built at this commit. +If the from command is omitted when creating a new branch, the first merge commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of merge commands per @@ -693,7 +707,7 @@ commands per commit; 16, if starting a new, empty branch. Here <committish> is any of the commit specification expressions also accepted by from (see above).
-
+
<emphasis>filemodify</emphasis> Included in a commit command to add a new file or change the content of an existing file. This command has two different means @@ -771,8 +785,12 @@ in octal. Git only supports the following modes: A <path> string must use UNIX-style directory separators (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". +A path can use C-style string quoting; this is accepted in all cases +and mandatory if the filename starts with double quote or contains +LF. In C-style quoting, the complete name should be surrounded with +double quotes, and any LF, backslash, or double quote characters +must be escaped by preceding them with a backslash (e.g., +"path/with\n, \\ and \" in it"). The value of <path> must be in canonical form. That is it must not: @@ -800,7 +818,7 @@ contain the special component . or .. The root of the tree can be represented by an empty string as <path>. It is recommended that <path> always be encoded using UTF-8.
-
+
<emphasis>filedelete</emphasis> Included in a commit command to remove a file or recursively delete an entire directory from the branch. If the file or directory @@ -812,7 +830,7 @@ first non-empty directory or the root is reached. be removed from the branch. See filemodify above for a detailed description of <path>.
-
+
<emphasis>filecopy</emphasis> Recursively copies an existing file or subdirectory to a different location within the branch. The existing file or directory must @@ -828,7 +846,7 @@ location has been copied to the destination any future commands applied to the source location will not impact the destination of the copy.
-
+
<emphasis>filerename</emphasis> Renames an existing file or subdirectory to a different location within the branch. The existing file or directory must exist. If @@ -851,7 +869,7 @@ command is provided just to simplify frontends that already have rename information and don't want bother with decomposing it into a filecopy followed by a filedelete.
-
+
<emphasis>filedeleteall</emphasis> Included in a commit command to remove all files (and also all directories) from the branch. This command resets the internal @@ -870,7 +888,7 @@ 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.
-
+
<emphasis>notemodify</emphasis> Included in a commit <notes_ref> command to add a new note annotating a <committish> or change this annotation contents. @@ -917,7 +935,7 @@ Inline data format expressions also accepted by from (see above).
-
+
<emphasis>mark</emphasis> 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 @@ -933,7 +951,7 @@ a mark. Only values greater than or equal to 1 may be used as marks. to another object simply by reusing the same <idnum> in another mark command.
-
+
<emphasis>tag</emphasis> Creates an annotated tag referring to a specific commit. To create lightweight (non-annotated) tags see the reset command below. @@ -966,7 +984,7 @@ 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 git tag process.
-
+
<emphasis>reset</emphasis> Creates (or recreates) the named branch, optionally starting from a specific revision. The reset command allows a frontend to issue @@ -987,7 +1005,7 @@ from :938 would create the lightweight tag refs/tags/938 referring to whatever commit mark :938 references.
-
+
<emphasis>blob</emphasis> Requests writing one file revision to the packfile. The revision is not connected to any commit; this connection must be formed in @@ -1001,7 +1019,7 @@ to generate the Git SHA-1 for the blob on their own, and feed that directly to commit. This is typically more work than it's worth however, as marks are inexpensive to store and easy to use.
-
+
<emphasis>data</emphasis> 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 @@ -1060,7 +1078,7 @@ a data chunk which does not have an LF as its last byte.
-
+
<emphasis>checkpoint</emphasis> Forces fast-import to close the current packfile, start a new one, and to save out all current branch refs, tags and marks. @@ -1081,7 +1099,7 @@ repository can be loaded into Git through fast-import in about 3 hours, explicit checkpointing may not be necessary. The LF after the command is optional (it used to be required).
-
+
<emphasis>progress</emphasis> Causes fast-import to print the entire progress line unmodified to its standard output channel (file descriptor 1) when the command is @@ -1100,7 +1118,7 @@ remove the leading part of the line, for example: inform the reader when the checkpoint has been completed and it can safely access the refs that fast-import updated.
-
+
<emphasis>cat-blob</emphasis> Causes fast-import to print a blob to a file descriptor previously arranged with the --cat-blob-fd argument. The command otherwise @@ -1119,8 +1137,10 @@ ready to be written. This command can be used anywhere in the stream that comments are accepted. In particular, the cat-blob command can be used in the middle of a commit but not in the middle of a data command. +See Responses To Commands below for details about how to read +this output safely.
-
+
<emphasis>ls</emphasis> Prints information about the object at a path to a file descriptor previously arranged with the --cat-blob-fd argument. This allows @@ -1171,8 +1191,10 @@ instead report missing SP <path> LF +See Responses To Commands below for details about how to read +this output safely.
-
+
<emphasis>feature</emphasis> Require that fast-import supports the specified feature, or abort if it does not. @@ -1262,13 +1284,15 @@ done Error out if the stream ends without a done command. Without this feature, errors causing the frontend to end abruptly at a convenient point in the stream can go - undetected. + undetected. This may occur, for example, if an import + front end dies in mid-operation without emitting SIGTERM + or SIGKILL at its subordinate git fast-import instance.
-
+
<emphasis>option</emphasis> Processes the specified option so that git fast-import behaves in a way that suits the frontend's needs. @@ -1311,7 +1335,7 @@ force
-
+
<emphasis>done</emphasis> If the done feature is not in use, treated as if EOF was read. This can be used to tell fast-import to finish early. @@ -1320,7 +1344,32 @@ in use, the done command is mandatory and marks the end of stream.
- + +Responses To Commands +New objects written by fast-import are not available immediately. +Most fast-import commands have no visible effect until the next +checkpoint (or completion). The frontend can send commands to +fill fast-import's input pipe without worrying about how quickly +they will take effect, which improves performance by simplifying +scheduling. +For some frontends, though, it is useful to be able to read back +data from the current repository as it is being updated (for +example when the source material describes objects in terms of +patches to be applied to previously imported objects). This can +be accomplished by connecting the frontend and fast-import via +bidirectional pipes: + +mkfifo fast-import-output +frontend <fast-import-output | +git fast-import >fast-import-output + +A frontend set up this way can use progress, ls, and cat-blob +commands to read information from the import in progress. +To avoid deadlock, such frontends must completely consume any +pending output from progress, ls, and cat-blob before +performing writes to fast-import that might block. + + Crash Reports If fast-import is supplied invalid input it will terminate with a non-zero exit status and create a crash report in the top level of @@ -1394,11 +1443,11 @@ refs/heads/master: END OF CRASH REPORT - + 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 @@ -1411,7 +1460,7 @@ commit to the corresponding source revision. 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 @@ -1421,14 +1470,14 @@ code considerably. 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 @@ -1452,7 +1501,7 @@ 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. Typically this takes only a very short time, @@ -1468,7 +1517,7 @@ 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 @@ -1477,7 +1526,7 @@ 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.
-
+
Include Some Progress Messages Every once in a while have your frontend emit a progress message to fast-import. The contents of the messages are entirely free-form, @@ -1487,7 +1536,7 @@ Your users will feel better knowing how much of the data stream has been processed.
- + Packfile Optimization When packing a blob fast-import always attempts to deltify against the last blob written. Unless specifically arranged for by the frontend, @@ -1514,14 +1563,14 @@ deltas are suboptimal (see above) then also adding the -f o 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 amortize any overheads associated with malloc. In practice fast-import tends to amortize 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, @@ -1535,7 +1584,7 @@ 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 @@ -1543,7 +1592,7 @@ 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. @@ -1566,14 +1615,14 @@ 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 amortizes 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 @@ -1586,7 +1635,7 @@ projects with 2,000+ branches and 45,114+ files in a very limited memory footprint (less than 2.7 MiB per active branch).
- + Signals Sending SIGUSR1 to the git fast-import process ends the current packfile early, simulating a checkpoint command. The impatient @@ -1594,8 +1643,8 @@ operator can use this facility to peek at the objects and refs from an import in progress, at the cost of some added running time and worse compression. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fetch-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-fetch-pack.xml index 4b432059f..b50e6fe07 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fetch-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fetch-pack.xml @@ -1,24 +1,25 @@ - + -
- + git-fetch-pack(1) git-fetch-pack(1) - - + NAME git-fetch-pack - Receive missing objects from another repository - + SYNOPSIS
-git fetch-pack [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>…] +git fetch-pack [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=<git-upload-pack>] + [--depth=<n>] [--no-progress] + [-v] [<host>:]<directory> [<refs>…]
- + DESCRIPTION Usually you would want to use git fetch, which is a higher level wrapper of this command, instead. @@ -31,7 +32,7 @@ is found out by scanning the local refs/ hierarchy and sent to asked refs from the remote side when the local side does not have a common ancestor commit. - + OPTIONS @@ -209,8 +210,8 @@ be in a separate packet, and the list must end with a flush packet. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fetch.xml b/doc/source/en/TortoiseGit/git_doc/git-fetch.xml index efe1531f3..06cd6bf3c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fetch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fetch.xml @@ -1,18 +1,16 @@ - + -
- + git-fetch(1) git-fetch(1) - - + NAME git-fetch - Download objects and refs from another repository - + SYNOPSIS
git fetch [<options>] [<repository> [<refspec>…]] @@ -21,7 +19,7 @@ git fetch --all [<options>]
- + DESCRIPTION Fetches named heads or tags from one or more other repositories, along with the objects necessary to complete them. @@ -40,7 +38,7 @@ or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See ). - + OPTIONS @@ -76,7 +74,8 @@ there is a remotes.<group> entry in the configuration file. Deepen the history of a shallow repository created by git clone with --depth=<depth> option (see ) - by the specified number of commits. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. @@ -171,14 +170,11 @@ there is a remotes.<group> entry in the configuration file. - Most of the tags are fetched automatically as branch - heads are downloaded, but tags that do not point at - objects reachable from the branch heads that are being - tracked will not be fetched by this mechanism. This - flag lets all tags and their associated objects be - downloaded. The default behavior for a remote may be - specified with the remote.<name>.tagopt setting. See - . + This is a short-hand for giving "refs/tags/:refs/tags/" + refspec from the command line, to ask all tags to be fetched + and stored locally. Because this acts as an explicit + refspec, the default refspecs (configured with the + remote.$name.fetch variable) are overridden and not used. @@ -318,8 +314,8 @@ there is a remotes.<group> entry in the configuration file. The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL - (see the section GIT URLS below) or the name - of a remote (see the section REMOTES below). + (see the section GIT URLS below) or the name + of a remote (see the section REMOTES below). @@ -406,14 +402,17 @@ A parameter <ref> without a colon is equivalent to - -GIT URLS<anchor id="URLS" xreflabel="[URLS]"/> + +GIT URLS<anchor id="git-fetch(1)_URLS" xreflabel="[URLS]"/> In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git supports ssh, git, http, and https protocols (in addition, ftp, +and ftps can be used for fetching and rsync can be used for fetching +and pushing, but these are inefficient and deprecated; do not use +them). +The following syntaxes may be used with them: @@ -521,8 +520,8 @@ configuration section of the form: "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL. - -REMOTES<anchor id="REMOTES" xreflabel="[REMOTES]"/> + +REMOTES<anchor id="git-fetch(1)_REMOTES" xreflabel="[REMOTES]"/> The name of one of the following can be used instead of a URL as <repository> argument: @@ -544,7 +543,7 @@ a file in the $GIT_DIR/branches directory. All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default. -
+
Named remote in configuration file You can choose to provide the name of a remote which you had previously configured using , @@ -561,7 +560,7 @@ config file would appear like this: The <pushurl> is used for pushes only. It is optional and defaults to <url>.
-
+
Named file in <emphasis>$GIT_DIR/remotes</emphasis> You can choose to provide the name of a file in $GIT_DIR/remotes. The URL @@ -577,7 +576,7 @@ following format: Multiple Push: and Pull: lines may be specified for additional branch mappings.
-
+
Named file in <emphasis>$GIT_DIR/branches</emphasis> You can choose to provide the name of a file in $GIT_DIR/branches. @@ -595,7 +594,7 @@ refspecs, if you don't provide one on the command line. HEAD:refs/heads/<head>
- + EXAMPLES @@ -621,7 +620,7 @@ because it is prefixed with a plus sign; tmp will not be. - + BUGS Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the @@ -630,12 +629,12 @@ fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future git version. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-filter-branch.xml b/doc/source/en/TortoiseGit/git_doc/git-filter-branch.xml index b027fe27f..d47bae676 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-filter-branch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-filter-branch.xml @@ -1,18 +1,16 @@ - + -
- + git-filter-branch(1) git-filter-branch(1) - - + NAME git-filter-branch - Rewrite branches - + SYNOPSIS
git filter-branch [--env-filter <command>] [--tree-filter <command>] @@ -24,7 +22,7 @@ [--] [<rev-list options>…]
- + DESCRIPTION Lets you rewrite git revision history by rewriting the branches mentioned in the <rev-list options>, applying custom filters on each revision. @@ -38,7 +36,8 @@ If you specify no filters, the commits will be recommitted without any changes, which would normally have no effect. Nevertheless, this may be useful in the future for compensating for some git bugs or such, therefore such a usage is permitted. -NOTE: This command honors .git/info/grafts and .git/refs/replace/. +NOTE: This command honors .git/info/grafts file and refs in +the refs/replace/ namespace. If you have any grafts or replacement refs defined, running this command will make them permanent. WARNING! The rewritten history will have different object names for all @@ -55,7 +54,7 @@ if different from the rewritten ones, will be stored in the namespace Note that since this operation is very I/O expensive, it might be a good idea to redirect the temporary directory off-disk with the -d option, e.g. on tmpfs. Reportedly the speedup is very noticeable. -
+
Filters The filters are applied in the order as listed below. The <command> argument is always evaluated in the shell context using the eval command @@ -74,7 +73,7 @@ return several ids on separate lines if your commit filter emitted multiple commits.
- + OPTIONS @@ -208,7 +207,7 @@ to other tags will be rewritten to point to the underlying commit. Only look at the history which touches the given subdirectory. The result will contain that directory (and only that) as its - project root. Implies . + project root. Implies . @@ -279,12 +278,12 @@ to other tags will be rewritten to point to the underlying commit. Arguments for git rev-list. All positive refs included by these options are rewritten. You may also specify options such as --all, but you must use -- to separate them from - the git filter-branch options. Implies . + the git filter-branch options. Implies . -
+
Remap to ancestor By using arguments, e.g., path limiters, you can limit the set of revisions which get rewritten. However, positive refs on the command @@ -293,7 +292,7 @@ this purpose, they are instead rewritten to point at the nearest ancestor that was not excluded.
- + Examples Suppose you want to remove a file (containing confidential information or copyright violation) from all commits: @@ -351,26 +350,26 @@ parameters. Note that this handles merges properly! In case Darl committed a merge between P1 and P2, it will be propagated properly and all children of the merge will become merge commits with P1,P2 as their parents instead of the merge commit. +NOTE the changes introduced by the commits, and which are not reverted +by subsequent commits, will still be in the rewritten branch. If you want +to throw out changes together with the commits, you should use the +interactive mode of git rebase. You can rewrite the commit log messages using --msg-filter. For example, git svn-id strings in a repository created by git svn can be removed this way: git filter-branch --msg-filter ' sed -e "/^git-svn-id:/d" ' -To restrict rewriting to only part of the history, specify a revision -range in addition to the new branch name. The new branch name will -point to the top-most revision that a git rev-list of this range -will print. If you need to add Acked-by lines to, say, the last 10 commits (none of which is a merge), use this command: git filter-branch --msg-filter ' cat && echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>" ' HEAD~10..HEAD -NOTE the changes introduced by the commits, and which are not reverted -by subsequent commits, will still be in the rewritten branch. If you want -to throw out changes together with the commits, you should use the -interactive mode of git rebase. +To restrict rewriting to only part of the history, specify a revision +range in addition to the new branch name. The new branch name will +point to the top-most revision that a git rev-list of this range +will print. Consider this history: D--E--F--G--H / / @@ -387,7 +386,7 @@ git filter-branch ... D..H --not C git update-index --index-info && mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD - + Checklist for Shrinking a Repository git-filter-branch is often used to get rid of a subset of files, usually with some combination of --index-filter and @@ -447,8 +446,8 @@ Garbage collect all unreferenced objects with git gc --prune=now - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fmt-merge-msg.xml b/doc/source/en/TortoiseGit/git_doc/git-fmt-merge-msg.xml index 41260077f..28654fbd4 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fmt-merge-msg.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fmt-merge-msg.xml @@ -1,25 +1,23 @@ - + -
- + git-fmt-merge-msg(1) git-fmt-merge-msg(1) - - + NAME git-fmt-merge-msg - Produce a merge commit message - + SYNOPSIS
git fmt-merge-msg [-m <message>] [--log[=<n>] | --no-log] <$GIT_DIR/FETCH_HEAD git fmt-merge-msg [-m <message>] [--log[=<n>] | --no-log] -F <file>
- + DESCRIPTION Takes the list of merged objects on stdin and produces a suitable commit message to be used for the merge commit, usually to be @@ -27,7 +25,7 @@ passed as the <merge-message> argument of g This command is intended mostly for internal use by scripts automatically invoking git merge. - + OPTIONS @@ -99,7 +97,7 @@ automatically invoking git merge. - + CONFIGURATION @@ -140,12 +138,12 @@ merge.summary - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-for-each-ref.xml b/doc/source/en/TortoiseGit/git_doc/git-for-each-ref.xml index 4989add29..cacd5abe8 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-for-each-ref.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-for-each-ref.xml @@ -1,25 +1,23 @@ - + -
- + git-for-each-ref(1) git-for-each-ref(1) - - + NAME git-for-each-ref - Output information on each ref - + SYNOPSIS
git for-each-ref [--count=<count>] [--shell|--perl|--python|--tcl] [(--sort=<key>)…] [--format=<format>] [<pattern>…]
- + DESCRIPTION Iterate over all refs that match <pattern> and show them according to the given <format>, after sorting them according @@ -28,7 +26,7 @@ showing that many refs. The interpolated values in <format> - + OPTIONS @@ -113,7 +111,7 @@ host language allowing their direct evaluation in that language. - + FIELD NAMES Various values from structured fields in referenced objects can be used to interpolate into the resulting output, or as sort @@ -184,9 +182,10 @@ be used to specify the value in the header field. committer, and tagger) can be suffixed with name, email, and date to extract the named component. The complete message in a commit and tag object is contents. -Its first line is contents:subject, the remaining lines -are contents:body and the optional GPG signature -is contents:signature. +Its first line is contents:subject, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is contents:body, where body is all of the lines after the first +blank line. Finally, the optional GPG signature is contents:signature. For sorting purposes, fields with numeric values sort in numeric order (objectsize, authordate, committerdate, taggerdate). All other fields are used to sort in their byte-value order. @@ -198,7 +197,7 @@ the date by adding one of :default, :relative:iso8601 or :rfc2822 to the end of the fieldname; e.g. %(taggerdate:relative). - + EXAMPLES An example directly producing formatted text. Show the most recent 3 tagged commits: @@ -272,16 +271,16 @@ eval=`git for-each-ref --shell --format="$fmt" \ refs/tags` eval "$eval" - + Author Written by Junio C Hamano <gitster@pobox.com>. - + Documentation Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-format-patch.xml b/doc/source/en/TortoiseGit/git_doc/git-format-patch.xml index e86a30bb9..0d07e5c7e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-format-patch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-format-patch.xml @@ -1,18 +1,16 @@ - + -
- + git-format-patch(1) git-format-patch(1) - - + NAME git-format-patch - Prepare patches for e-mail submission - + SYNOPSIS
git format-patch [-k] [(-o|--output-directory) <dir> | --stdout] @@ -26,12 +24,12 @@ [--ignore-if-in-upstream] [--subject-prefix=Subject-Prefix] [--to=<email>] [--cc=<email>] - [--cover-letter] [--quiet] + [--cover-letter] [--quiet] [--notes[=<ref>]] [<common diff options>] [ <since> | <revision range> ]
- + DESCRIPTION Prepare each commit with its patch in one file per commit, formatted to resemble UNIX mailbox format. @@ -67,16 +65,18 @@ The names of the output files are printed to standard output, unless the --stdout option is specified. If -o is specified, output files are created in <dir>. Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and -the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use -n. To omit -patch numbers from the subject, use -N. +By default, the subject of a single patch is "[PATCH] " followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of ). +When multiple patches are output, the subject prefix will instead be +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use -n. +To omit patch numbers from the subject, use -N. If given --thread, git-format-patch will generate In-Reply-To and References headers to make the second and subsequent patch mails appear as replies to the first mail; this also generates a Message-Id header to reference. - + OPTIONS @@ -146,7 +146,7 @@ reference. Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overriden by + if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -380,7 +380,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -899,6 +903,24 @@ will want to ensure that threading is disabled for git send-email +--notes[=<ref>] + + + + Append the notes (see ) for the commit + after the three-dash line. + +The expected use case of this is to write supporting explanation for +the commit that does not belong to the commit log message proper, +and include it with the patch submission. While one can simply write +these explanations after format-patch has run but before sending, +keeping them as git notes allows them to be maintained between versions +of the patch series (but see the discussion of the notes.rewrite +configuration options in to use this workflow). + + + + --[no]-signature=<signature> @@ -964,7 +986,7 @@ you can use --suffix=-patch to get 0001-descripti - + CONFIGURATION You can specify extra mail header lines to be added to each message, defaults for the subject prefix and file suffix, number patches when @@ -980,7 +1002,7 @@ attachments, and sign off patches with configuration variables. attach [ = mime-boundary-string ] signoff = true - + DISCUSSION The patch produced by git format-patch is in UNIX mailbox format, with a fixed "magic" time stamp to indicate that the file is output @@ -1026,7 +1048,7 @@ should omit From: and Date: lines from title is likely to be different from the subject of the discussion the patch is in response to, so it is likely that you would want to keep the Subject: line, like the example above. -
+
Checking for patch corruption Many mailers if not set up properly will corrupt whitespace. Here are two common types of corruption: @@ -1100,11 +1122,11 @@ While at it, check the info and final-commit
- + MUA-SPECIFIC HINTS Here are some hints on how to successfully submit patches inline using various mailers. -
+
GMail GMail does not have any way to turn off line wrapping in the web interface, so it will mangle any emails that you send. You can however @@ -1116,7 +1138,7 @@ GMail SMTP server, see the EXAMPLE section of For hints on submission using the IMAP interface, see the EXAMPLE section of .
-
+
Thunderbird By default, Thunderbird will both wrap emails as well as flag them as being format=flowed, both of which will make the @@ -1124,7 +1146,7 @@ resulting email unusable by git. There are three different approaches: use an add-on to turn off line wraps, configure Thunderbird to not mangle patches, or use an external editor to keep Thunderbird from mangling the patches. -
+
Approach #1 (add-on) Install the Toggle Word Wrap add-on that is available from https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ @@ -1133,7 +1155,7 @@ that you can tick off. Now you can compose the message as you otherwise do (cut + paste, git format-patch | git imap-send, etc), but you have to insert line breaks manually in any text that you type.
-
+
Approach #2 (configuration) Three steps: @@ -1168,7 +1190,7 @@ Toggle it to make sure it is set to false. otherwise would (cut + paste, git format-patch | git imap-send, etc), and the patches will not be mangled.
-
+
Approach #3 (external editor) The following Thunderbird extensions are needed: AboutConfig from http://aboutconfig.mozdev.org/ and @@ -1218,7 +1240,7 @@ you include patches with Thunderbird in an easy way. To use it, do the steps above and then use the script as the external editor.
-
+
KMail This should help you to submit patches inline using KMail. @@ -1252,7 +1274,7 @@ Back in the compose window: add whatever other text you wish to the
- + EXAMPLES @@ -1297,12 +1319,12 @@ as e-mailable patches: - + SEE ALSO , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fsck-objects.xml b/doc/source/en/TortoiseGit/git_doc/git-fsck-objects.xml index e77d0cec0..108eb80f2 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fsck-objects.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fsck-objects.xml @@ -1,30 +1,28 @@ - + -
- + git-fsck-objects(1) git-fsck-objects(1) - - + NAME git-fsck-objects - Verifies the connectivity and validity of the objects in the database - + SYNOPSIS
git fsck-objects …
- + DESCRIPTION This is a synonym for . Please refer to the documentation of that command. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-fsck.xml b/doc/source/en/TortoiseGit/git_doc/git-fsck.xml index f8b4b31fe..fc6dff915 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-fsck.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-fsck.xml @@ -1,18 +1,16 @@ - + -
- + git-fsck(1) git-fsck(1) - - + NAME git-fsck - Verifies the connectivity and validity of the objects in the database - + SYNOPSIS
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] @@ -20,11 +18,11 @@ [--[no-]dangling] [--[no-]progress] [<object>*]
- + DESCRIPTION Verifies the connectivity and validity of the objects in the database. - + OPTIONS @@ -36,8 +34,8 @@ An object to treat as the head of an unreachability trace. If no objects are given, git fsck defaults to using the -index file, all SHA1 references in .git/refs/*, and all reflogs (unless ---no-reflogs is given) as heads. +index file, all SHA1 references in refs namespace, and all reflogs +(unless --no-reflogs is given) as heads. @@ -183,7 +181,7 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless - + DISCUSSION git-fsck tests SHA1 and general object sanity, and it does full tracking of the resulting reachability and everything else. It prints out any @@ -195,7 +193,7 @@ set, as mentioned above). (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). - + Extracted Diagnostics @@ -271,7 +269,7 @@ sha1 mismatch <object> - + Environment Variables @@ -306,8 +304,8 @@ GIT_ALTERNATE_OBJECT_DIRECTORIES - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-gc.xml b/doc/source/en/TortoiseGit/git_doc/git-gc.xml index 6972a6796..79ddf8dbd 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-gc.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-gc.xml @@ -1,24 +1,22 @@ - + -
- + git-gc(1) git-gc(1) - - + NAME git-gc - Cleanup unnecessary files and optimize the local repository - + SYNOPSIS
git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]
- + DESCRIPTION Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase @@ -32,7 +30,7 @@ below for details. If you know what you're doing and all you want is to disable this behavior permanently without further considerations, just do: $ git config --global gc.auto 0 - + OPTIONS @@ -108,7 +106,7 @@ automatic consolidation of packs. - + Configuration The optional configuration variable gc.reflogExpire can be set to indicate how long historical entries within each branch's @@ -149,7 +147,7 @@ more details. This defaults to 250. the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago". - + Notes git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set @@ -161,20 +159,20 @@ that were later amended or rewound). all of those locations and decide whether it makes sense in your case to remove those references. - + HOOKS The git gc --auto command will run the pre-auto-gc hook. See for more information. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-get-tar-commit-id.xml b/doc/source/en/TortoiseGit/git_doc/git-get-tar-commit-id.xml index 6ae713b66..7afd9db49 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-get-tar-commit-id.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-get-tar-commit-id.xml @@ -1,24 +1,22 @@ - + -
- + git-get-tar-commit-id(1) git-get-tar-commit-id(1) - - + NAME git-get-tar-commit-id - Extract commit ID from an archive created using git-archive - + SYNOPSIS
git get-tar-commit-id < <tarfile>
- + DESCRIPTION Acts as a filter, extracting the commit ID stored in archives created by git archive. It reads only the first 1024 bytes of input, thus its @@ -28,8 +26,8 @@ return code of 1. This can happen if <tarfile> had not been created using git archive or if the first parameter of git archive had been a tree ID instead of a commit ID or tag. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-grep.xml b/doc/source/en/TortoiseGit/git_doc/git-grep.xml index 367956032..54bbd678c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-grep.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-grep.xml @@ -1,18 +1,16 @@ - + -
- + git-grep(1) git-grep(1) - - + NAME git-grep - Print lines matching a pattern - + SYNOPSIS
git grep [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp] @@ -35,12 +33,14 @@ [--] [<pathspec>…]
- + DESCRIPTION Look for specified patterns in the tracked files in the work tree, blobs -registered in the index file, or blobs in given tree objects. +registered in the index file, or blobs in given tree objects. Patterns +are lists of one or more search expressions separated by newline +characters. An empty string as search expression matches all lines. - + CONFIGURATION @@ -55,17 +55,32 @@ grep.lineNumber +grep.patternType + + + + Set the default matching behavior. Using a value of basic, extended, + fixed, or perl will enable the --basic-regexp, --extended-regexp, + --fixed-strings, or --perl-regexp option accordingly, while the + value default will return to the default matching behavior. + + + + + grep.extendedRegexp - If set to true, enable --extended-regexp option by default. + If set to true, enable --extended-regexp option by default. This + option is ignored when the grep.patternType option is set to a value + other than default. - + OPTIONS @@ -590,7 +605,7 @@ grep.extendedRegexp - + Examples @@ -628,8 +643,8 @@ grep.extendedRegexp - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-gui.xml b/doc/source/en/TortoiseGit/git_doc/git-gui.xml index 5ee64b120..2ecaeb3c4 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-gui.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-gui.xml @@ -1,24 +1,22 @@ - + -
- + git-gui(1) git-gui(1) - - + NAME git-gui - A portable graphical interface to Git - + SYNOPSIS
git gui [<command>] [arguments]
- + DESCRIPTION A Tcl/Tk based graphical user interface to Git. git gui focuses on allowing users to make changes to their repository by making @@ -33,7 +31,7 @@ and Windows (under both Cygwin and MSYS). To the extent possible OS specific user interface guidelines are followed, making git gui a fairly native interface for users. - + COMMANDS @@ -84,7 +82,7 @@ version - + Examples @@ -186,7 +184,7 @@ version - + SEE ALSO @@ -203,7 +201,7 @@ version - + Other git gui is actually maintained as an independent project, but stable versions are distributed as part of the Git suite for the convenience @@ -214,8 +212,8 @@ of end users. git clone http://repo.or.cz/r/git-gui.git or browsed online at http://repo.or.cz/w/git-gui.git/[]. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-hash-object.xml b/doc/source/en/TortoiseGit/git_doc/git-hash-object.xml index aa6209394..750616497 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-hash-object.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-hash-object.xml @@ -1,25 +1,23 @@ - + -
- + git-hash-object(1) git-hash-object(1) - - + NAME git-hash-object - Compute object ID and optionally creates a blob from a file - + SYNOPSIS
git hash-object [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>… git hash-object [-t <type>] [-w] --stdin-paths [--no-filters] < <list-of-paths>
- + DESCRIPTION Computes the object ID value for an object with specified type with the contents of the named file (which can be outside of the @@ -29,7 +27,7 @@ This is used by git cvsimport to update the index without modifying files in the work tree. When <type> is not specified, it defaults to "blob". - + OPTIONS @@ -104,8 +102,8 @@ specified, it defaults to "blob". - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-help.xml b/doc/source/en/TortoiseGit/git_doc/git-help.xml index 0e6f190b3..a670f3683 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-help.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-help.xml @@ -1,24 +1,22 @@ - + -
- + git-help(1) git-help(1) - - + NAME git-help - display help information about git - + SYNOPSIS
git help [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
- + DESCRIPTION With no options and no COMMAND given, the synopsis of the git command and a list of the most commonly used git commands are printed @@ -31,7 +29,7 @@ can be overridden by other options or configuration variables. Note that git --help ... is identical to git help ... because the former is internally converted into the latter. - + OPTIONS @@ -101,9 +99,9 @@ these config variables is set, the git web--browse - + CONFIGURATION VARIABLES -
+
help.format If no command line option is passed, the help.format configuration variable will be checked. The following values are supported for this @@ -127,14 +125,14 @@ line option:
-
+
help.browser, web.browser and browser.<tool>.path The help.browser, web.browser and browser.<tool>.path will also be checked if the web format is chosen (either by command line option or configuration variable). See -w|--web in the OPTIONS section above and .
-
+
man.viewer The man.viewer config variable will be checked if the man format is chosen. The following values are currently supported: @@ -172,7 +170,7 @@ DISPLAY is not set) and in that case emacs' woman mode will be tried. in the GIT_MAN_VIEWER environment variable will be tried. If that fails too, the man program will be tried anyway.
-
+
man.<tool>.path You can explicitly provide a full path to your preferred man viewer by setting the configuration variable man.<tool>.path. For example, you @@ -180,7 +178,7 @@ can configure the absolute path to konqueror by setting man.konqueror.path. Otherwise, git help assumes the tool is available in PATH.
-
+
man.<tool>.cmd When the man viewer, specified by the man.viewer configuration variables, is not among the supported ones, then the corresponding @@ -189,7 +187,7 @@ variable exists then the specified tool will be treated as a custom command and a shell eval will be used to run the command with the man page passed as arguments.
-
+
Note about konqueror When konqueror is specified in the man.viewer configuration variable, we launch kfmclient to try to open the man page on an @@ -205,7 +203,7 @@ the following: [man "konq"] cmd = A_PATH_TO/konqueror
-
+
Note about git config --global Note that all these configuration variables should probably be set using the --global flag, for example like this: @@ -215,8 +213,8 @@ $ git config --global web.browser firefox See for more information about this.
- + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-http-backend.xml b/doc/source/en/TortoiseGit/git_doc/git-http-backend.xml index 921c967f6..66fdd8bbf 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-http-backend.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-http-backend.xml @@ -1,24 +1,22 @@ - + -
- + git-http-backend(1) git-http-backend(1) - - + NAME git-http-backend - Server side implementation of Git over HTTP - + SYNOPSIS
git http-backend
- + DESCRIPTION A simple CGI program to serve the contents of a Git repository to Git clients accessing the repository over http:// and https:// protocols. @@ -35,7 +33,7 @@ GIT_HTTP_EXPORT_ALL environmental variable is set). the receive-pack service is enabled, which serves git send-pack clients, which is invoked from git push. - + SERVICES These services can be enabled/disabled using the per-repository configuration file: @@ -83,7 +81,7 @@ http.receivepack - + URL TRANSLATION To determine the location of the repository on disk, git http-backend concatenates the environment variables PATH_INFO, which is set @@ -92,7 +90,7 @@ manually in the web server configuration. If GIT_PROJECT_ROOT is not set, git http-backend reads PATH_TRANSLATED, which is also set automatically by the web server. - + EXAMPLES All of the following examples map http://$hostname/git/foo/bar.git to /var/www/git/foo/bar.git. @@ -177,7 +175,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ - + ENVIRONMENT git http-backend relies upon the CGI environment variables set by the invoking web server, including: @@ -223,16 +221,16 @@ identifying information of the remote user who performed the push. All CGI environment variables are available to each of the hooks invoked by the git-receive-pack. - + Author Written by Shawn O. Pearce <spearce@spearce.org>. - + Documentation Documentation by Shawn O. Pearce <spearce@spearce.org>. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-http-fetch.xml b/doc/source/en/TortoiseGit/git_doc/git-http-fetch.xml index 4669d3116..68d2ad94f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-http-fetch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-http-fetch.xml @@ -1,30 +1,28 @@ - + -
- + git-http-fetch(1) git-http-fetch(1) - - + NAME git-http-fetch - Download from a remote git repository via HTTP - + SYNOPSIS
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
- + DESCRIPTION Downloads a remote git repository via HTTP. NOTE: use of this command without -a is deprecated. The -a behaviour will become the default in a future release. - + OPTIONS @@ -114,8 +112,8 @@ commit-id - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-http-push.xml b/doc/source/en/TortoiseGit/git_doc/git-http-push.xml index d8bab8d84..6d893d24a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-http-push.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-http-push.xml @@ -1,24 +1,22 @@ - + -
- + git-http-push(1) git-http-push(1) - - + NAME git-http-push - Push objects over HTTP/DAV to another repository - + SYNOPSIS
git http-push [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>…]
- + DESCRIPTION Sends missing objects to remote repository, and updates the remote branch. @@ -26,7 +24,7 @@ remote branch. is older than 7.16, as the combination has been reported not to work and sometimes corrupts repository. - + OPTIONS @@ -120,7 +118,7 @@ Specified branch is an ancestor of the remote HEAD - + Specifying the Refs A <ref> specification can be either a single pattern, or a pair of such patterns separated by a colon ":" (this means that a ref name @@ -168,8 +166,8 @@ remote ref and lose other peoples' commits from there. Optionally, a <ref> parameter can be prefixed with a plus + sign to disable the fast-forward check only on that ref. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-imap-send.xml b/doc/source/en/TortoiseGit/git_doc/git-imap-send.xml index 1ea0d3b9b..bb89f0d16 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-imap-send.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-imap-send.xml @@ -1,24 +1,22 @@ - + -
- + git-imap-send(1) git-imap-send(1) - - + NAME git-imap-send - Send a collection of patches from stdin to an IMAP folder - + SYNOPSIS
git imap-send
- + DESCRIPTION This command uploads a mailbox generated with git format-patch into an IMAP drafts folder. This allows patches to be sent as @@ -29,11 +27,11 @@ that order. Typical usage is something like: git format-patch --signoff --stdout --attach origin | git imap-send - + CONFIGURATION To use the tool, imap.folder and either imap.tunnel or imap.host must be set to appropriate values. -
+
Variables @@ -144,7 +142,7 @@ imap.authMethod
-
+
Examples Using tunnel mode: [imap] @@ -166,7 +164,7 @@ imap.authMethod sslverify = false
- + EXAMPLE To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig to specify your account settings: @@ -184,7 +182,7 @@ that the "Folder doesn't exist". interface will wrap lines no matter what, so you need to use a real IMAP client). - + CAUTION It is still your responsibility to make sure that the email message sent by your email program meets the standards of your project. @@ -196,12 +194,12 @@ flames ridiculing you if you don't check this. users may wish to visit this web page for more information: http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email - + SEE ALSO , , mbox(5) - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-index-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-index-pack.xml index 6b8e85f4c..13c3318e4 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-index-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-index-pack.xml @@ -1,18 +1,16 @@ - + -
- + git-index-pack(1) git-index-pack(1) - - + NAME git-index-pack - Build pack index file for an existing packed archive - + SYNOPSIS
git index-pack [-v] [-o <index-file>] <pack-file> @@ -20,14 +18,14 @@ [<pack-file>]
- + DESCRIPTION Reads a packed archive (.pack) from the specified file, and builds a pack index file (.idx) for it. The packed archive together with the pack index can then be placed in the objects/pack/ directory of a git repository. - + OPTIONS @@ -136,9 +134,26 @@ objects/pack/ directory of a git repository. + + +--threads=<n> + + + + Specifies the number of threads to spawn when resolving + deltas. This requires that index-pack be compiled with + pthreads otherwise this option is ignored with a warning. + This is meant to reduce packing time on multiprocessor + machines. The required amount of memory for the delta search + window is however multiplied by the number of threads. + Specifying 0 will cause git to auto-detect the number of CPU's + and use maximum 3 threads. + + + - + Note Once the index has been created, the list of object names is sorted and the SHA1 hash of that list is printed to stdout. If --stdin was @@ -147,8 +162,8 @@ new .keep file was successfully created. This is useful to remove a .keep file used as a lock to prevent the race with git repack mentioned above. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-init-db.xml b/doc/source/en/TortoiseGit/git_doc/git-init-db.xml index 830f70b38..70b92bdde 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-init-db.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-init-db.xml @@ -1,30 +1,28 @@ - + -
- + git-init-db(1) git-init-db(1) - - + NAME git-init-db - Creates an empty git repository - + SYNOPSIS
git init-db [-q | --quiet] [--bare] [--template=<template_directory>] [--separate-git-dir <git dir>] [--shared[=<permissions>]]
- + DESCRIPTION This is a synonym for . Please refer to the documentation of that command. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-init.xml b/doc/source/en/TortoiseGit/git_doc/git-init.xml index caf066fdb..138a3c279 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-init.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-init.xml @@ -1,18 +1,16 @@ - + -
- + git-init(1) git-init(1) - - + NAME git-init - Create an empty git repository or reinitialize an existing one - + SYNOPSIS
git init [-q | --quiet] [--bare] [--template=<template_directory>] @@ -20,7 +18,7 @@ [--shared[=<permissions>]] [directory]
- + DESCRIPTION This command creates an empty git repository - basically a .git directory with subdirectories for objects, refs/heads, @@ -37,7 +35,7 @@ overwrite things that are already there. The primary reason for rerunning git init is to pick up newly added templates (or to move the repository to another place if --separate-git-dir is given). - + OPTIONS @@ -149,7 +147,7 @@ into it. If you name a (possibly non-existent) directory at the end of the command line, the command is run inside the directory (possibly after creating it). - + TEMPLATE DIRECTORY The template directory contains files and directories that will be copied to the $GIT_DIR after it is created. @@ -180,7 +178,7 @@ The default template directory: /usr/share/git-core/templates - + EXAMPLES @@ -189,15 +187,15 @@ Start a new git repository for an existing code base $ cd /path/to/my/codebase -$ git init -$ git add . +$ git init +$ git add . - + prepare /path/to/my/codebase/.git directory - + add all existing file to the index @@ -207,8 +205,8 @@ add all existing file to the index - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-instaweb.xml b/doc/source/en/TortoiseGit/git_doc/git-instaweb.xml index 7e4c0cba2..8a3f6b35a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-instaweb.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-instaweb.xml @@ -1,18 +1,16 @@ - + -
- + git-instaweb(1) git-instaweb(1) - - + NAME git-instaweb - Instantly browse your working repository in gitweb - + SYNOPSIS
git instaweb [--local] [--httpd=<httpd>] [--port=<port>] @@ -20,12 +18,12 @@ git instaweb [--start] [--stop] [--restart]
- + DESCRIPTION A simple script to set up gitweb and a web server for browsing the local repository. - + OPTIONS @@ -147,7 +145,7 @@ restart - + CONFIGURATION You may specify configuration in your .git/config [instaweb] @@ -160,12 +158,12 @@ restart web.browser will be used instead if it is defined. See for more information about this. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-log.xml b/doc/source/en/TortoiseGit/git_doc/git-log.xml index bb820a841..154a90afa 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-log.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-log.xml @@ -1,24 +1,22 @@ - + -
- + git-log(1) git-log(1) - - + NAME git-log - Show commit logs - + SYNOPSIS
git log [<options>] [<since>..<until>] [[--] <path>…]
- + DESCRIPTION Shows the commit logs. The command takes options applicable to the git rev-list @@ -26,22 +24,11 @@ command to control what is shown and how, and options applicable to the git diff-* commands to control how the changes each commit introduces are shown. - + OPTIONS --<n> - - - - Limits the number of commits to show. - Note that this is a commit limiting option, see below. - - - - - <since>..<until> @@ -139,16 +126,24 @@ be prefixed with "-- " to separate them from options or refnames. -
+
Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit +limiting may be applied. +Using more options generally further limits the output (e.g. +--since=<date1> limits to commits newer than <date1>, and using it +with --grep=<pattern> further limits to commits whose log message +has a line that matches <pattern>), unless otherwise noted. +Note that these are applied before commit ordering and formatting options, such as --reverse. --n number +-<number> + + +-n <number> --max-count=<number> @@ -205,7 +200,24 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one --author=<pattern>, + commits whose author matches any of the given patterns are + chosen (similarly for multiple --committer=<pattern>). + + + + + +--grep-reflog=<pattern> + + + + Limit the commits output to ones with reflog entries that + match the specified pattern (regular expression). With + more than one --grep-reflog, commits whose reflog message + matches any of the given patterns are chosen. It is an + error to use this option unless --walk-reflogs is in use. @@ -216,8 +228,13 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one --grep=<pattern>, commits whose message + matches any of the given patterns are chosen (but see + --all-match). +When --show-notes is in effect, the message from the notes as +if it is part of the log message. @@ -227,7 +244,7 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. @@ -246,6 +263,17 @@ ordering and formatting options, such as --reverse. +--basic-regexp + + + + Consider the limiting patterns to be basic regular expressions; + this is the default. + + + + + -E @@ -274,6 +302,17 @@ ordering and formatting options, such as --reverse. +--perl-regexp + + + + Consider the limiting patterns to be Perl-compatible regexp. + Requires libpcre to be compiled in. + + + + + --remove-empty @@ -569,7 +608,7 @@ See also .
-
+
History Simplification Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of @@ -931,31 +970,42 @@ above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).
-
+
Commit Ordering By default, the commits are shown in reverse chronological order. ---topo-order +--date-order - This option makes them appear in topological order (i.e. - descendant commits are shown before their parents). + Show no parents before all of its children are shown, but + otherwise show commits in the commit timestamp order. ---date-order +--topo-order - This option is similar to --topo-order in the sense that no - parent comes before all of its children, but otherwise things - are still ordered in the commit timestamp order. + Show no parents before all of its children are shown, and + avoid showing commits on multiple lines of history + intermixed. +For example, in a commit history like this: + ---1----2----4----7 + \ \ + 3----5----6----8--- +where the numbers denote the order of commit timestamps, git +rev-list and friends with --date-order show the commits in the +timestamp order: 8 7 6 5 4 3 2 1. +With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 +3 1); some older commits are shown before newer ones in order to +avoid showing the commits from two parallel development track mixed +together. @@ -971,7 +1021,7 @@ commits are marked as TREESAME (subject to be simplified away).
-
+
Object Traversal These options are mostly targeted for packing of git repositories. @@ -1015,11 +1065,16 @@ commits are marked as TREESAME (subject to be simplified away). ---no-walk +--no-walk[=(sorted|unsorted)] - Only show the given revs, but do not traverse their ancestors. + Only show the given commits, but do not traverse their ancestors. + This has no effect if a range is specified. If the argument + "unsorted" is given, the commits are show in the order they were + given on the command line. Otherwise (if "sorted" or no argument + was given), the commits are show in reverse chronological order + by commit time. @@ -1035,7 +1090,7 @@ commits are marked as TREESAME (subject to be simplified away).
-
+
Commit Formatting @@ -1163,6 +1218,17 @@ being displayed. Examples: "--notes=foo" will show only notes from +--show-signature + + + + Check the validity of a signed commit object by passing the signature + to gpg --verify and show the output. + + + + + --relative-date @@ -1261,7 +1327,7 @@ format, often found in E-mail messages.
-
+
Diff Formatting Below are listed options that control the formatting of diff output. Some of them are specific to , however other diff @@ -1287,7 +1353,7 @@ options may be given. See for more options. - This flag implies the -c options and further compresses the + This flag implies the -c option and further compresses the patch output by omitting uninteresting hunks whose contents in the parents have only two variants and the merge result picks one of them without modification. @@ -1342,7 +1408,7 @@ options may be given. See for more options.
- + PRETTY FORMATS If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is @@ -1599,6 +1665,21 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +%GG: raw verification message from GPG for a signed commit + + + + +%G?: show either "G" for Good or "B" for Bad for a signed commit + + + + +%GS: show the name of the signer for a signed commit + + + + %gD: reflog selector, e.g., refs/stash@{1} @@ -1729,7 +1810,7 @@ $ git log -2 --pretty=%h 4da45bef - + Common diff options @@ -1825,7 +1906,7 @@ $ git log -2 --pretty=%h 4da45bef Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overriden by + if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using @@ -2024,7 +2105,8 @@ any of those replacements occurred. the commits in the range like summary does. Omitting the --submodule option or specifying --submodule=short, uses the short format. This format just shows the names of the commits - at the beginning and end of the range. + at the beginning and end of the range. Can be tweaked via the + diff.submodule configuration variable. @@ -2261,7 +2343,11 @@ another file. index (i.e. amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a % sign, the number is to be read as + a fraction, with a decimal point before it. I.e., -M5 becomes + 0.5, and is thus the same as -M50%. Similarly, -M05 is + the same as -M5%. To limit detection to exact renames, use + -M100%. @@ -2606,7 +2692,7 @@ of a delete/create pair. For more detailed explanation on these common options, see also . - + Generating patches with -p When "git-diff-index", "git-diff-tree", or "git-diff-files" are run with a -p option, "git diff" without the --raw option, or @@ -2681,7 +2767,7 @@ rename to a - + combined diff format Any diff-generating command can take the -c` or --cc option to produce a combined diff when showing a merge. This is the default @@ -2790,7 +2876,7 @@ two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version"). - + Examples @@ -2887,9 +2973,19 @@ two unresolved merge parents with the working tree file + + +git log -3 + + + + Limits the number of commits to show to 3. + + + - + Discussion At the core level, git is character encoding agnostic. @@ -2958,7 +3054,7 @@ message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation. - + Configuration See for core variables and for settings related to diff generation. @@ -3042,8 +3138,8 @@ and overridden by the --notes=<ref> option. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-lost-found.xml b/doc/source/en/TortoiseGit/git_doc/git-lost-found.xml index 739ac9126..a08cf4da3 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-lost-found.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-lost-found.xml @@ -1,24 +1,22 @@ - + -
- + git-lost-found(1) git-lost-found(1) - - + NAME git-lost-found - Recover lost refs that luckily have not yet been pruned - + SYNOPSIS
git lost-found
- + DESCRIPTION NOTE: this command is deprecated. Use with the option --lost-found instead. @@ -27,12 +25,12 @@ creates refs to them in the .git/lost-found/ directory. Commits and tags that dereference to commits are stored in .git/lost-found/commit, and other objects are stored in .git/lost-found/other. - + OUTPUT Prints to standard output the object names and one-line descriptions of any commits or tags found. - + EXAMPLE Suppose you run git tag -f and mistype the tag to overwrite. The ref to your tag is overwritten, but until you run git @@ -44,7 +42,8 @@ prune, the tag itself is still there. other. $ gitk $(cd .git/lost-found/commit && echo ??*) After making sure you know which the object is the tag you are looking -for, you can reconnect it to your regular .git/refs hierarchy. +for, you can reconnect it to your regular refs hierarchy by using +the update-ref command. $ git cat-file -t 1ef2b196 tag $ git cat-file tag 1ef2b196 @@ -61,8 +60,8 @@ $ git update-ref refs/tags/not-lost-anymore 1ef2b196 $ git rev-parse not-lost-anymore 1ef2b196d909eed523d4f3c9bf54b78cdd6843c6 - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-ls-files.xml b/doc/source/en/TortoiseGit/git_doc/git-ls-files.xml index f0bc58424..6b62968cf 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-ls-files.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-ls-files.xml @@ -1,18 +1,16 @@ - + -
- + git-ls-files(1) git-ls-files(1) - - + NAME git-ls-files - Show information about files in the index and the working tree - + SYNOPSIS
git ls-files [-z] [-t] [-v] @@ -26,7 +24,7 @@ [--full-name] [--abbrev] [--] [<file>…]
- + DESCRIPTION This merges the file listing in the directory cache index with the actual working directory list, and shows different combinations of the @@ -34,7 +32,7 @@ two. One or more of the options below may be used to determine the files shown: - + OPTIONS @@ -412,7 +410,7 @@ other - + Output git ls-files just outputs the filenames unless --stage is specified in which case it outputs: @@ -428,7 +426,7 @@ path. (see for more information on state)\t, \n, and \\, respectively. - + Exclude Patterns git ls-files can use a list of "exclude patterns" when traversing the directory tree and finding files to show when the @@ -466,12 +464,12 @@ top of the directory tree. A pattern read from a file specified by --exclude-per-directory is relative to the directory that the pattern file appears in. - + SEE ALSO , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-ls-remote.xml b/doc/source/en/TortoiseGit/git_doc/git-ls-remote.xml index e2736b4a1..2444c5377 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-ls-remote.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-ls-remote.xml @@ -1,30 +1,28 @@ - + -
- + git-ls-remote(1) git-ls-remote(1) - - + NAME git-ls-remote - List references in a remote repository - + SYNOPSIS
git ls-remote [--heads] [--tags] [-u <exec> | --upload-pack <exec>] [--exit-code] <repository> [<refs>…]
- + DESCRIPTION Displays references available in a remote repository along with the associated commit IDs. - + OPTIONS @@ -80,6 +78,18 @@ commit IDs. +--get-url + + + + Expand the URL of the given remote repository taking into account any + "url.<base>.insteadOf" config setting (See ) and + exit without talking to the remote. + + + + + <repository> @@ -105,7 +115,7 @@ commit IDs. - + EXAMPLES $ git ls-remote --tags ./. d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 @@ -124,8 +134,8 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-ls-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-ls-tree.xml index c069f256e..1011e488e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-ls-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-ls-tree.xml @@ -1,18 +1,16 @@ - + -
- + git-ls-tree(1) git-ls-tree(1) - - + NAME git-ls-tree - List the contents of a tree object - + SYNOPSIS
git ls-tree [-d] [-r] [-t] [-l] [-z] @@ -20,7 +18,7 @@ <tree-ish> [<path>…]
- + DESCRIPTION Lists the contents of a given tree object, like what "/bin/ls -a" does in the current working directory. Note that: @@ -48,7 +46,7 @@ the behaviour is similar to that of "/bin/ls" in that the <path> - + OPTIONS @@ -176,7 +174,7 @@ the behaviour is similar to that of "/bin/ls" in that the <path> - + Output Format <mode> SP <type> SP <object> TAB <file> Unless the -z option is used, TAB, LF, and backslash characters @@ -189,8 +187,8 @@ This output format is compatible with what --index-info --stdin- character is used in place of size. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mailinfo.xml b/doc/source/en/TortoiseGit/git_doc/git-mailinfo.xml index 55895d345..327fd95b3 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mailinfo.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mailinfo.xml @@ -1,24 +1,22 @@ - + -
- + git-mailinfo(1) git-mailinfo(1) - - + NAME git-mailinfo - Extracts patch and authorship from a single e-mail message - + SYNOPSIS
git mailinfo [-k|-b] [-u | --encoding=<encoding> | -n] [--scissors] <msg> <patch>
- + DESCRIPTION Reads a single e-mail message from the standard input, and writes the commit log message in <msg> file, and the patches in @@ -27,7 +25,7 @@ written out to the standard output to be used by git am to create a commit. It is usually not necessary to use this command directly. See instead. - + OPTIONS @@ -167,8 +165,8 @@ beginning of the proposed commit log message with a scissors line. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mailsplit.xml b/doc/source/en/TortoiseGit/git_doc/git-mailsplit.xml index 3399186eb..504e6b16a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mailsplit.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mailsplit.xml @@ -1,31 +1,29 @@ - + -
- + git-mailsplit(1) git-mailsplit(1) - - + NAME git-mailsplit - Simple UNIX mbox splitter program - + SYNOPSIS
git mailsplit [-b] [-f<nn>] [-d<prec>] [--keep-cr] -o<directory> [--] [(<mbox>|<Maildir>)…]
- + DESCRIPTION Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the specified directory so you can process them further from there. Maildir splitting relies upon filenames being sorted to output patches in the correct order. - + OPTIONS @@ -106,8 +104,8 @@ patches in the correct order. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-base.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-base.xml index 902004223..954664432 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge-base.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge-base.xml @@ -1,26 +1,25 @@ - + -
- + git-merge-base(1) git-merge-base(1) - - + NAME git-merge-base - Find as good common ancestors as possible for a merge - + SYNOPSIS
git merge-base [-a|--all] <commit> <commit>… git merge-base [-a|--all] --octopus <commit>… +git merge-base --is-ancestor <commit> <commit> git merge-base --independent <commit>…
- + DESCRIPTION git merge-base finds best common ancestor(s) between two commits to use in a three-way merge. One common ancestor is better than another common @@ -29,7 +28,7 @@ that does not have any better common ancestor is a best common ancestor, i.e. a merge base. Note that there can be more than one merge base for a pair of commits. - + OPERATION MODE As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. @@ -67,9 +66,21 @@ from when used with the --merge- + + +--is-ancestor + + + + Check if the first <commit> is an ancestor of the second <commit>, + and exit with status 0 if true, or with status 1 if not. + Errors are signaled by a non-zero status that is not 1. + + + - + OPTIONS @@ -87,7 +98,7 @@ from when used with the --merge- - + DISCUSSION Given two commits A and B, git merge-base A B will output a commit which is reachable from both A and B through the parent relationship. @@ -126,15 +137,30 @@ the best common ancestor of all commits. both 1 and 2 are merge-bases of A and B. Neither one is better than the other (both are best merge bases). When the --all option is not given, it is unspecified which best one is output. +A common idiom to check "fast-forward-ness" between two commits A +and B is (or at least used to be) to compute the merge base between +A and B, and check if it is the same as A, in which case, A is an +ancestor of B. You will see this idiom used often in older scripts. +A=$(git rev-parse --verify A) +if test "$A" = "$(git merge-base A B)" +then + ... A is an ancestor of B ... +fi +In modern git, you can say this in a more direct way: +if git merge-base --is-ancestor A B +then + ... A is an ancestor of B ... +fi +instead. - + See also , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-file.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-file.xml index c5ba1cc0e..13bb87cfb 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge-file.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge-file.xml @@ -1,18 +1,16 @@ - + -
- + git-merge-file(1) git-merge-file(1) - - + NAME git-merge-file - Run a three-way file merge - + SYNOPSIS
git merge-file [-L <current-name> [-L <base-name> [-L <other-name>]]] @@ -20,7 +18,7 @@ <current-file> <base-file> <other-file>
- + DESCRIPTION git merge-file incorporates all changes that lead from the <base-file> to <other-file> into <current-file>. The result ordinarily goes into @@ -48,7 +46,7 @@ conflicts otherwise. If the merge was clean, the exit value is 0. implements all of RCS merge's functionality which is needed by . - + OPTIONS @@ -106,7 +104,7 @@ implements all of RCS merge's functionality which is needed - + EXAMPLES @@ -133,8 +131,8 @@ implements all of RCS merge's functionality which is needed - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-index.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-index.xml index 40e810422..860b1bf90 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge-index.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge-index.xml @@ -1,31 +1,29 @@ - + -
- + git-merge-index(1) git-merge-index(1) - - + NAME git-merge-index - Run a merge for files needing merging - + SYNOPSIS
git merge-index [-o] [-q] <merge-program> (-a | [--] <file>*)
- + DESCRIPTION This looks up the <file>(s) in the index and, if there are any merge entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty argument if no file), and <file> as argument 4. File modes for the three files are passed as arguments 5, 6 and 7. - + OPTIONS @@ -103,8 +101,8 @@ merge once anything has returned an error (i.e., cat return for the AA file, because it didn't exist in the original, and thus git merge-index didn't even try to merge the MM thing). - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-one-file.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-one-file.xml index 7f60b232a..f81ad86f6 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge-one-file.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge-one-file.xml @@ -1,30 +1,28 @@ - + -
- + git-merge-one-file(1) git-merge-one-file(1) - - + NAME git-merge-one-file - The standard helper program to use with git-merge-index - + SYNOPSIS
git merge-one-file
- + DESCRIPTION This is the standard helper program to use with git merge-index to resolve a merge after the trivial merge done with git read-tree -m. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-tree.xml index 9f2b56130..77a1e7a6c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge-tree.xml @@ -1,24 +1,22 @@ - + -
- + git-merge-tree(1) git-merge-tree(1) - - + NAME git-merge-tree - Show three-way merge without touching index - + SYNOPSIS
git merge-tree <base-tree> <branch1> <branch2>
- + DESCRIPTION Reads three treeish, and output trivial merge results and conflicting stages to the standard output. This is similar to @@ -30,8 +28,8 @@ merge results outside of the index, and stuff the results back into the index. For this reason, the output from the command omits entries that match the <branch1> tree. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge.xml b/doc/source/en/TortoiseGit/git_doc/git-merge.xml index 6ce19c7f6..44669567b 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-merge.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-merge.xml @@ -1,18 +1,16 @@ - + -
- + git-merge(1) git-merge(1) - - + NAME git-merge - Join two or more development histories together - + SYNOPSIS
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] @@ -22,7 +20,7 @@ git merge --abort
- + DESCRIPTION Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current @@ -56,7 +54,7 @@ reconstruct the original (pre-merge) changes. Therefore: discouraged: while possible, it leaves you in a state that is hard to back out of in the case of a conflict. - + OPTIONS @@ -338,14 +336,14 @@ commit or stash your changes before running git merge. If no commit is given from the command line, and if merge.defaultToUpstream -configuration variable is set, merge the remote tracking branches +configuration variable is set, merge the remote-tracking branches that the current branch is configured to use as its upstream. See also the configuration section of this manual page. - + PRE-MERGE CHECKS Before applying outside changes, you should get your own work in good shape and committed locally, so it will not be clobbered if @@ -361,7 +359,7 @@ would result from the merge already.) If all named commits are already ancestors of HEAD, git merge will exit early with the message "Already up-to-date." - + FAST-FORWARD MERGE Often the current branch head is an ancestor of the named commit. This is the most common case especially when invoked from git @@ -373,7 +371,7 @@ updated to point at the named commit, without creating an extra merge commit. This behavior can be suppressed with the --no-ff option. - + TRUE MERGE Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them @@ -423,7 +421,7 @@ No other changes are made. In particular, the local If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort. - + HOW CONFLICTS ARE PRESENTED During a merge, the working tree files are updated to reflect the result of the merge. Among the changes made to the common ancestor's version, @@ -432,7 +430,7 @@ other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, however, git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area. -By default, git uses the same style as that is used by "merge" program +By default, git uses the same style as the one used by the "merge" program from the RCS suite to present such a conflicted hunk, like this: Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. @@ -472,7 +470,7 @@ that statement and gave up, while the other side tried to have a more positive attitude. You can sometimes come up with a better resolution by viewing the original. - + HOW TO RESOLVE CONFLICTS After seeing a conflict, you can do two things: @@ -524,7 +522,7 @@ Look at the originals. git show :1:filename shows the - + EXAMPLES @@ -555,7 +553,7 @@ release/version name would be acceptable. - + MERGE STRATEGIES The merge mechanism (git-merge and git-pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies @@ -605,6 +603,7 @@ ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. + For a binary file, the entire contents are taken from our side. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything @@ -617,7 +616,7 @@ theirs - This is opposite of ours. + This is the opposite of ours. @@ -773,7 +772,7 @@ subtree - + CONFIGURATION @@ -799,11 +798,11 @@ merge.defaultToUpstream If merge is called without any commit argument, merge the upstream branches configured for the current branch by using their last - observed values stored in their remote tracking branches. + observed values stored in their remote-tracking branches. The values of the branch.<current branch>.merge that name the branches at the remote named by branch.<current branch>.remote are consulted, and then they are mapped via remote.<remote>.fetch - to their corresponding remote tracking branches, and the tips of + to their corresponding remote-tracking branches, and the tips of these tracking branches are merged. @@ -956,7 +955,7 @@ branch.<name>.mergeoptions - + SEE ALSO , , , @@ -965,8 +964,8 @@ branch.<name>.mergeoptions , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mergetool--lib.xml b/doc/source/en/TortoiseGit/git_doc/git-mergetool--lib.xml index cdfce86e6..70196330e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mergetool--lib.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mergetool--lib.xml @@ -1,24 +1,22 @@ - + -
- + git-mergetool--lib(1) git-mergetool--lib(1) - - + NAME git-mergetool--lib - Common git merge tool shell scriptlets - + SYNOPSIS
TOOL_MODE=(diff|merge) . "$(git --exec-path)/git-mergetool--lib"
- + DESCRIPTION This is not a command the end user would want to run. Ever. This documentation is meant for people who are studying the @@ -30,7 +28,7 @@ with git merge tools. to define the operation mode for the functions listed below. diff and merge are valid values. - + FUNCTIONS @@ -78,8 +76,8 @@ run_merge_tool - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mergetool.xml b/doc/source/en/TortoiseGit/git_doc/git-mergetool.xml index e5e5a1044..7aa15af34 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mergetool.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mergetool.xml @@ -1,24 +1,22 @@ - + -
- + git-mergetool(1) git-mergetool(1) - - + NAME git-mergetool - Run merge conflict resolution tools to resolve merge conflicts - + SYNOPSIS
git mergetool [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>…]
- + DESCRIPTION Use git mergetool to run one of several merge utilities to resolve merge conflicts. It is typically run after git merge. @@ -28,7 +26,7 @@ conflicts). Specifying a directory will include all unresolved files in that path. If no <file> names are specified, git mergetool will run the merge tool program on every file with merge conflicts. - + OPTIONS @@ -41,9 +39,9 @@ the merge tool program on every file with merge conflicts. Use the merge resolution program specified by <tool>. - Valid merge tools are: - araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, - meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff. + Valid values include emerge, gvimdiff, kdiff3, + meld, vimdiff, and tortoisemerge. Run git mergetool --tool-help + for the list of valid <tool> settings. If a merge resolution program is not specified, git mergetool will use the configuration variable merge.tool. If the @@ -77,6 +75,16 @@ success of the resolution after the custom tool has exited. +--tool-help + + + + Print a list of merge tools that may be used with --tool. + + + + + -y @@ -103,7 +111,7 @@ success of the resolution after the custom tool has exited. - + TEMPORARY FILES git mergetool creates *.orig backup files while resolving merges. These are safe to remove once a file has been merged and its @@ -112,8 +120,8 @@ These are safe to remove once a file has been merged and its causes git mergetool to automatically remove the backup as files are successfully merged. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mktag.xml b/doc/source/en/TortoiseGit/git_doc/git-mktag.xml index 22b99bfd1..4842a6e7b 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mktag.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mktag.xml @@ -1,30 +1,28 @@ - + -
- + git-mktag(1) git-mktag(1) - - + NAME git-mktag - Creates a tag object - + SYNOPSIS
git mktag < signature_file
- + DESCRIPTION Reads a tag contents on standard input and creates a tag object that can also be used to sign other objects. The output is the new tag's <object> identifier. - + Tag Format A tag signature file has a very simple fixed format: four lines of object <sha1> @@ -37,8 +35,8 @@ exists, is separated by a blank line from the header. The message part may contain a signature that git itself doesn't care about, but that can be verified with gpg. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mktree.xml b/doc/source/en/TortoiseGit/git_doc/git-mktree.xml index 1985f0acd..94beb6da0 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mktree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mktree.xml @@ -1,31 +1,29 @@ - + -
- + git-mktree(1) git-mktree(1) - - + NAME git-mktree - Build a tree-object from ls-tree formatted text - + SYNOPSIS
git mktree [-z] [--missing] [--batch]
- + DESCRIPTION Reads standard input in non-recursive ls-tree output format, and creates a tree object. The order of the tree entries is normalised by mktree so pre-sorting the input is not required. The object name of the tree object built is written to the standard output. - + OPTIONS @@ -66,8 +64,8 @@ built is written to the standard output. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-mv.xml b/doc/source/en/TortoiseGit/git_doc/git-mv.xml index 070a44042..a64eac50a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-mv.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-mv.xml @@ -1,24 +1,22 @@ - + -
- + git-mv(1) git-mv(1) - - + NAME git-mv - Move or rename a file, a directory, or a symlink - + SYNOPSIS
git mv <options>… <args>…
- + DESCRIPTION This script is used to move or rename a file, directory or symlink. git mv [-v] [-f] [-n] [-k] <source> <destination> @@ -30,7 +28,7 @@ directory; the given sources will be moved into this directory. The index is updated after successful completion, but the change must still be committed. - + OPTIONS @@ -87,8 +85,8 @@ committed. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-name-rev.xml b/doc/source/en/TortoiseGit/git_doc/git-name-rev.xml index 60cfadd68..33e71ff1a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-name-rev.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-name-rev.xml @@ -1,30 +1,28 @@ - + -
- + git-name-rev(1) git-name-rev(1) - - + NAME git-name-rev - Find symbolic names for given revs - + SYNOPSIS
git name-rev [--tags] [--refs=<pattern>] ( --all | --stdin | <committish>… )
- + DESCRIPTION Finds symbolic names suitable for human digestion for revisions given in any format parsable by git rev-parse. - + OPTIONS @@ -104,7 +102,7 @@ format parsable by git rev-parse. - + EXAMPLE Given a commit, find out where it is relative to the local refs. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. @@ -117,8 +115,8 @@ not the context. Another nice thing you can do is: % git log | git name-rev --stdin - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-notes.xml b/doc/source/en/TortoiseGit/git_doc/git-notes.xml index c0ee9ee4b..83c7caa6e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-notes.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-notes.xml @@ -1,18 +1,16 @@ - + -
- + git-notes(1) git-notes(1) - - + NAME git-notes - Add or inspect object notes - + SYNOPSIS
git notes [list [<object>]] @@ -29,7 +27,7 @@ git notes get-ref
- + DESCRIPTION Adds, removes, or reads notes attached to objects, without touching the objects themselves. @@ -43,12 +41,15 @@ the original commit message. To distinguish these notes from the message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for refs/notes/commits). +Notes can also be added to patches prepared with git format-patch by +using the --notes option. Such notes are added as a patch commentary +after a three dash separator line. To change which notes are shown by git log, see the "notes.displayRef" configuration in . See the "notes.rewrite.<command>" configuration for a way to carry notes across commands that rewrite commits. - + SUBCOMMANDS @@ -186,7 +187,7 @@ get-ref - + OPTIONS @@ -389,7 +390,7 @@ get-ref - + DISCUSSION Commit notes are blobs containing extra information about an object (usually information to supplement a commit's message). These blobs @@ -410,7 +411,7 @@ These details may change in the future. object, in which case the history of the notes can be read with git log -p -g <refname>. - + NOTES MERGE STRATEGIES The default notes merge strategy is "manual", which checks out conflicting notes in a special work tree for resolving notes conflicts @@ -436,7 +437,7 @@ Note that if either the local or remote version contain duplicate lines prior to the merge, these will also be removed by this notes merge strategy. - + EXAMPLES You can use notes to add annotations with information that was not available at the time a commit was written. @@ -459,7 +460,7 @@ Of course, it doesn't make much sense to display non-text-format notes with git log, so if you use such notes, you'll probably need to write some special-purpose tools to do something useful with them. - + CONFIGURATION @@ -538,7 +539,7 @@ enable note rewriting. - + ENVIRONMENT @@ -597,17 +598,17 @@ on the notes.rewrite.<command> and notes.re - + Author Written by Johannes Schindelin <johannes.schindelin@gmx.de> and Johan Herland <johan@herland.net> - + Documentation Documentation by Johannes Schindelin and Johan Herland - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-p4.xml b/doc/source/en/TortoiseGit/git_doc/git-p4.xml index 49211bc40..6c7a7065c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-p4.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-p4.xml @@ -1,18 +1,16 @@ - + -
- + git-p4(1) git-p4(1) - - + NAME git-p4 - Import from and submit to Perforce repositories - + SYNOPSIS
git p4 clone [<sync options>] [<clone options>] <p4 depot path>… @@ -21,7 +19,7 @@ git p4 submit [<submit options>] [<master branch name>]
- + DESCRIPTION This command provides a way to interact with p4 repositories using git. @@ -33,18 +31,11 @@ Submit git changes back to p4 using git p4 submit. The com git p4 rebase does a sync plus rebases the current branch onto the updated p4 remote branch. - + EXAMPLE -Create an alias for git p4, using the full path to the git-p4 - script if needed: - -$ git config --global alias.p4 '!git-p4' - - - Clone a repository: $ git p4 clone //depot/path/project @@ -72,9 +63,9 @@ Submit your commits back to p4: - + COMMANDS -
+
Clone Generally, git p4 clone is used to create a new git directory from an existing p4 repository: @@ -102,7 +93,7 @@ Creates a local branch, master from this remote and checks the depot path: $ git p4 clone //depot/path/project@all
-
+
Sync As development continues in the p4 repository, those changes can be included in the git repository using: @@ -123,7 +114,7 @@ will be fetched and consulted first during a git p4 sync. importing directly from p4 is considerably slower than pulling changes from a git remote, this can be useful in a multi-developer environment.
-
+
Rebase A common working pattern is to fetch the latest changes from the p4 depot and merge them with local uncommitted changes. Often, the p4 repository @@ -132,7 +123,7 @@ sense. This command does git p4 sync followed by $ git p4 rebase
-
+
Submit Submitting changes from a git repository back to the p4 repository requires a separate p4 client workspace. This should be specified @@ -152,11 +143,11 @@ according to the author of the git commit. This option requires admin privileges in p4, which can be granted using p4 protect.
- + OPTIONS -
+
General options -All commands except clone accept this option. +All commands except clone accept these options. @@ -168,9 +159,19 @@ privileges in p4, which can be granted using p4 protect. + + +--verbose, -v + + + + Provide more progress information. + + +
-
+
Sync options These options can be used in the initial clone as well as in subsequent sync operations. @@ -227,22 +228,23 @@ git repository: ---verbose +--detect-labels - Provide more progress information. + Query p4 for labels associated with the depot paths, and add + them as tags in git. Limited usefulness as only imports labels + associated with new changelists. Deprecated. ---detect-labels +--import-labels - Query p4 for labels associated with the depot paths, and add - them as tags in git. + Import labels from p4 into git. @@ -301,7 +303,7 @@ git repository:
-
+
Clone options These options can be used in an initial clone, along with the sync options described above. @@ -340,22 +342,12 @@ options described above.
-
+
Submit options These options can be used to modify git p4 submit behavior. ---verbose - - - - Provide more progress information. - - - - - --origin <commit> @@ -368,7 +360,7 @@ options described above. --M[<n>] +-M @@ -390,10 +382,76 @@ options described above. + + +--export-labels + + + + Export tags from git as p4 labels. Tags found in git are applied + to the perforce working directory. + + + + + +--dry-run, -n + + + + Show just what commits would be submitted to p4; do not change + state in git or p4. + + + + + +--prepare-p4-only + + + + Apply a commit to the p4 workspace, opening, adding and deleting + files in p4 as for a normal submit operation. Do not issue the + final "p4 submit", but instead print a message about how to + submit manually or revert. This option always stops after the + first (oldest) commit. Git tags are not exported to p4. + + + + + +--conflict=(ask|skip|quit) + + + + Conflicts can occur when applying a commit to p4. When this + happens, the default behavior ("ask") is to prompt whether to + skip this commit and continue, or quit. This option can be used + to bypass the prompt, causing conflicting commits to be automatically + skipped, or to quit trying to apply commits, without prompting. + + + + +
+
+Rebase options +These options can be used to modify git p4 rebase behavior. + + + +--import-labels + + + + Import p4 labels. + + +
- + DEPOT PATH SYNTAX The p4 depot path argument to git p4 sync and git p4 clone can be one or more space-separated p4 depot paths, with an optional @@ -449,7 +507,7 @@ p4 revision specifier on the end: See p4 help revisions for the full syntax of p4 revision specifiers. - + CLIENT SPEC The p4 client specification is maintained with the p4 client command and contains among other fields, a View that specifies how the depot @@ -460,22 +518,22 @@ useClientSpec variable is automatically set in the repository configuration file. This allows future git p4 submit commands to work properly; the submit command looks only at the variable and does not have a command-line option. -The full syntax for a p4 view is documented in p4 help views. Git-p4 +The full syntax for a p4 view is documented in p4 help views. Git p4 knows only a subset of the view syntax. It understands multi-line mappings, overlays with +, exclusions with - and double-quotes -around whitespace. Of the possible wildcards, git-p4 only handles -…, and only when it is at the end of the path. Git-p4 will complain +around whitespace. Of the possible wildcards, git p4 only handles +…, and only when it is at the end of the path. Git p4 will complain if it encounters an unhandled wildcard. Bugs in the implementation of overlap mappings exist. If multiple depot paths map through overlays to the same location in the repository, -git-p4 can choose the wrong one. This is hard to solve without -dedicating a client spec just for git-p4. -The name of the client can be given to git-p4 in multiple ways. The +git p4 can choose the wrong one. This is hard to solve without +dedicating a client spec just for git p4. +The name of the client can be given to git p4 in multiple ways. The variable git-p4.client takes precedence if it exists. Otherwise, normal p4 mechanisms of determining the client are used: environment variable P4CLIENT, a file referenced by P4CONFIG, or the local host name. - + BRANCH DETECTION P4 does not have the same concept of a branch as git. Instead, p4 organizes its content as a directory tree, where by convention @@ -508,18 +566,18 @@ occur with: git config git-p4.branchList main:branch1 git p4 clone --detect-branches //depot@all - + PERFORMANCE The fast-import mechanism used by git p4 creates one pack file for each invocation of git p4 sync. Normally, git garbage compression () automatically compresses these to fewer pack files, but explicit invocation of git repack -adf may improve performance. - + CONFIGURATION VARIABLES The following config settings can be used to modify git p4 behavior. They all are in the git-p4 section. -
+
General variables @@ -582,7 +640,7 @@ git-p4.client
-
+
Clone and sync variables @@ -629,6 +687,38 @@ git config --add git-p4.branchList main:branchB +git-p4.ignoredP4Labels + + + + List of p4 labels to ignore. This is built automatically as + unimportable labels are discovered. + + + + + +git-p4.importLabels + + + + Import p4 labels into git, as per --import-labels. + + + + + +git-p4.labelImportRegexp + + + + Only p4 labels matching this regular expression will be imported. The + default value is [a-zA-Z0-9_\-.]+$. + + + + + git-p4.useClientSpec @@ -642,7 +732,7 @@ git-p4.useClientSpec
-
+
Submit variables @@ -651,7 +741,8 @@ git-p4.detectRenames - Detect renames. See . + Detect renames. See . This can be true, + false, or a score as expected by git diff -M. @@ -661,7 +752,8 @@ git-p4.detectCopies - Detect copies. See . + Detect copies. See . This can be true, + false, or a score as expected by git diff -C. @@ -671,7 +763,7 @@ git-p4.detectCopiesHarder - Detect copies harder. See . + Detect copies harder. See . A boolean. @@ -754,17 +846,49 @@ git-p4.attemptRCSCleanup - If enabled, git p4 submit will attempt to cleanup RCS keywords - ($Header$, etc). These would otherwise cause merge conflicts and prevent - the submit going ahead. This option should be considered experimental at - present. + If enabled, git p4 submit will attempt to cleanup RCS keywords + ($Header$, etc). These would otherwise cause merge conflicts and prevent + the submit going ahead. This option should be considered experimental at + present. + + + + + +git-p4.exportLabels + + + + Export git tags to p4 labels, as per --export-labels. + + + + + +git-p4.labelExportRegexp + + + + Only p4 labels matching this regular expression will be exported. The + default value is [a-zA-Z0-9_\-.]+$. + + + + + +git-p4.conflict + + + + Specify submit behavior when a conflict with p4 is found, as per + --conflict. The default behavior is ask.
- + IMPLEMENTATION DETAILS @@ -795,4 +919,4 @@ Each commit imported by git p4 has a line at the end of the -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-pack-objects.xml b/doc/source/en/TortoiseGit/git_doc/git-pack-objects.xml index e30f5dccd..7d7343865 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-pack-objects.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-pack-objects.xml @@ -1,18 +1,16 @@ - + -
- + git-pack-objects(1) git-pack-objects(1) - - + NAME git-pack-objects - Create a packed archive of objects - + SYNOPSIS
git pack-objects [-q | --progress | --all-progress] [--all-progress-implied] @@ -22,7 +20,7 @@ [--keep-true-parents] < object-list
- + DESCRIPTION Reads list of objects from the standard input, and writes a packed archive with specified base-name, or to the standard output. @@ -45,7 +43,7 @@ one-object" format; this is typically done by the smart-pull commands when a pack is created on-the-fly for efficient network transport by their peers. - + OPTIONS @@ -403,14 +401,14 @@ So does git bundle (see ) w - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-pack-redundant.xml b/doc/source/en/TortoiseGit/git_doc/git-pack-redundant.xml index 6e9cd4967..beb5dd20a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-pack-redundant.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-pack-redundant.xml @@ -1,24 +1,22 @@ - + -
- + git-pack-redundant(1) git-pack-redundant(1) - - + NAME git-pack-redundant - Find redundant pack files - + SYNOPSIS
git pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename … >
- + DESCRIPTION This program computes which packs in your repository are redundant. The output is suitable for piping to @@ -30,7 +28,7 @@ objects. git fsck --full --unreachable | cut -d ' ' -f3 | \ git pack-redundant --all | xargs rm - + OPTIONS @@ -66,14 +64,14 @@ git pack-redundant --all | xargs rm - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-pack-refs.xml b/doc/source/en/TortoiseGit/git_doc/git-pack-refs.xml index 7966763b2..7919a736f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-pack-refs.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-pack-refs.xml @@ -1,39 +1,39 @@ - + -
- + git-pack-refs(1) git-pack-refs(1) - - + NAME git-pack-refs - Pack heads and tags for efficient repository access - + SYNOPSIS
git pack-refs [--all] [--no-prune]
- + DESCRIPTION Traditionally, tips of branches and tags (collectively known as -refs) were stored one file per ref under $GIT_DIR/refs +refs) were stored one file per ref in a (sub)directory +under $GIT_DIR/refs directory. While many branch tips tend to be updated often, most tags and some branch tips are never updated. When a repository has hundreds or thousands of tags, this one-file-per-ref format both wastes storage and hurts performance. This command is used to solve the storage and performance -problem by stashing the refs in a single file, +problem by storing the refs in a single file, $GIT_DIR/packed-refs. When a ref is missing from the -traditional $GIT_DIR/refs hierarchy, it is looked up in this +traditional $GIT_DIR/refs directory hierarchy, it is looked +up in this file and used if found. Subsequent updates to branches always create new files under -$GIT_DIR/refs hierarchy. +$GIT_DIR/refs directory 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 @@ -43,7 +43,7 @@ only the currently active branch heads will become unpacked, and the next pack-refs (without --all) will leave them unpacked. - + OPTIONS @@ -74,8 +74,14 @@ hierarchy after packing them. This option tells it not to. - + +BUGS +Older documentation written before the packed-refs mechanism was +introduced may still say things like ".git/refs/heads/<branch> file +exists" when it means "branch <branch> exists". + + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-parse-remote.xml b/doc/source/en/TortoiseGit/git_doc/git-parse-remote.xml index 1f1190ae5..44cb44104 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-parse-remote.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-parse-remote.xml @@ -1,32 +1,30 @@ - + -
- + git-parse-remote(1) git-parse-remote(1) - - + NAME git-parse-remote - Routines to help parsing remote repository access parameters - + SYNOPSIS
. "$(git --exec-path)/git-parse-remote"
- + DESCRIPTION This script is included in various scripts to supply routines to parse files under $GIT_DIR/remotes/ and $GIT_DIR/branches/ and configuration variables that are related to fetching, pulling and pushing. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-patch-id.xml b/doc/source/en/TortoiseGit/git_doc/git-patch-id.xml index c58aa597c..1a05b7533 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-patch-id.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-patch-id.xml @@ -1,24 +1,22 @@ - + -
- + git-patch-id(1) git-patch-id(1) - - + NAME git-patch-id - Compute unique ID for a patch - + SYNOPSIS
git patch-id < <patch>
- + DESCRIPTION A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with whitespace and line numbers ignored. As such, it's "reasonably stable", but at @@ -31,7 +29,7 @@ commit, and outputs two 40-byte hexadecimal strings. The first string is the patch ID, and the second string is the commit ID. This can be used to make a mapping from patch ID to commit ID. - + OPTIONS @@ -46,8 +44,8 @@ This can be used to make a mapping from patch ID to commit ID. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-peek-remote.xml b/doc/source/en/TortoiseGit/git_doc/git-peek-remote.xml index c21a3df13..84df2c713 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-peek-remote.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-peek-remote.xml @@ -1,28 +1,26 @@ - + -
- + git-peek-remote(1) git-peek-remote(1) - - + NAME git-peek-remote - List the references in a remote repository - + SYNOPSIS
git peek-remote [--upload-pack=<git-upload-pack>] [<host>:]<directory>
- + DESCRIPTION This command is deprecated; use git ls-remote instead. - + OPTIONS @@ -68,8 +66,8 @@ - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-prune-packed.xml b/doc/source/en/TortoiseGit/git_doc/git-prune-packed.xml index ac48a0bf6..3aafe0d5e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-prune-packed.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-prune-packed.xml @@ -1,24 +1,22 @@ - + -
- + git-prune-packed(1) git-prune-packed(1) - - + NAME git-prune-packed - Remove extra objects that are already in pack files - + SYNOPSIS
git prune-packed [-n|--dry-run] [-q|--quiet]
- + DESCRIPTION This program searches the $GIT_OBJECT_DIR for all objects that currently exist in a pack file as well as the independent object directories. @@ -28,7 +26,7 @@ compression applied, stored in a single file, with an associated index file.Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc. - + OPTIONS @@ -60,13 +58,13 @@ disk storage, etc. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-prune.xml b/doc/source/en/TortoiseGit/git_doc/git-prune.xml index fe309b3d5..6e1e59b71 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-prune.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-prune.xml @@ -1,24 +1,22 @@ - + -
- + git-prune(1) git-prune(1) - - + NAME git-prune - Prune all unreachable objects from the object database - + SYNOPSIS
git prune [-n] [-v] [--expire <expire>] [--] [<head>…]
- + DESCRIPTION In most cases, users should run git gc, which calls git prune. See the section "NOTES", below. @@ -32,7 +30,7 @@ running git prune-packed. Note that unreachable, packed objects will remain. If this is not desired, see . - + OPTIONS @@ -96,14 +94,14 @@ not desired, see . - + EXAMPLE To prune objects not used by your repository nor another that borrows from your repository via its .git/objects/info/alternates: $ git prune $(cd ../another && $(git rev-parse --all)) - + Notes In most cases, users will not need to call git prune directly, but should instead call git gc, which handles pruning along with @@ -111,14 +109,14 @@ many other housekeeping tasks. For a description of which objects are considered for pruning, see git fsck's --unreachable option. - + SEE ALSO , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-pull.xml b/doc/source/en/TortoiseGit/git_doc/git-pull.xml index 4a5d7bca2..4a340de96 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-pull.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-pull.xml @@ -1,24 +1,22 @@ - + -
- + git-pull(1) git-pull(1) - - + NAME git-pull - Fetch from and merge with another repository or a local branch - + SYNOPSIS
git pull [options] [<repository> [<refspec>…]]
- + DESCRIPTION Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for @@ -60,7 +58,7 @@ the merge will be automatically cancelled and the work tree untouched. It is generally best to get any local changes in working order before pulling or stash them away with . - + OPTIONS Options meant for git pull itself and the underlying git merge must be given before the options meant for git fetch. @@ -110,7 +108,7 @@ must be given before the options meant for git fetch. -
+
Options related to merging @@ -338,6 +336,9 @@ option can be used to override --squash. +-r + + --rebase @@ -369,7 +370,7 @@ unless you have read carefully.
-
+
Options related to fetching @@ -405,7 +406,8 @@ unless you have read carefully. Deepen the history of a shallow repository created by git clone with --depth=<depth> option (see ) - by the specified number of commits. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. @@ -505,8 +507,8 @@ unless you have read carefully. The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL - (see the section GIT URLS below) or the name - of a remote (see the section REMOTES below). + (see the section GIT URLS below) or the name + of a remote (see the section REMOTES below). @@ -582,14 +584,17 @@ A parameter <ref> without a colon is equivalent to
- -GIT URLS<anchor id="URLS" xreflabel="[URLS]"/> + +GIT URLS<anchor id="git-pull(1)_URLS" xreflabel="[URLS]"/> In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git supports ssh, git, http, and https protocols (in addition, ftp, +and ftps can be used for fetching and rsync can be used for fetching +and pushing, but these are inefficient and deprecated; do not use +them). +The following syntaxes may be used with them: @@ -697,8 +702,8 @@ configuration section of the form: "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL. - -REMOTES<anchor id="REMOTES" xreflabel="[REMOTES]"/> + +REMOTES<anchor id="git-pull(1)_REMOTES" xreflabel="[REMOTES]"/> The name of one of the following can be used instead of a URL as <repository> argument: @@ -720,7 +725,7 @@ a file in the $GIT_DIR/branches directory. All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default. -
+
Named remote in configuration file You can choose to provide the name of a remote which you had previously configured using , @@ -737,7 +742,7 @@ config file would appear like this: The <pushurl> is used for pushes only. It is optional and defaults to <url>.
-
+
Named file in <emphasis>$GIT_DIR/remotes</emphasis> You can choose to provide the name of a file in $GIT_DIR/remotes. The URL @@ -753,7 +758,7 @@ following format: Multiple Push: and Pull: lines may be specified for additional branch mappings.
-
+
Named file in <emphasis>$GIT_DIR/branches</emphasis> You can choose to provide the name of a file in $GIT_DIR/branches. @@ -771,7 +776,7 @@ refspecs, if you don't provide one on the command line. HEAD:refs/heads/<head>
- + MERGE STRATEGIES The merge mechanism (git-merge and git-pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies @@ -821,6 +826,7 @@ ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. + For a binary file, the entire contents are taken from our side. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything @@ -833,7 +839,7 @@ theirs - This is opposite of ours. + This is the opposite of ours. @@ -989,7 +995,7 @@ subtree - + DEFAULT BEHAVIOUR Often people use git pull without giving any parameter. Traditionally, this has been equivalent to saying git pull @@ -1043,7 +1049,7 @@ Otherwise the remote branch of the first refspec is merged. - + EXAMPLES @@ -1072,7 +1078,7 @@ $ git merge origin/next If you tried a pull which resulted in a complex conflicts and would want to start over, you can recover with git reset. - + BUGS Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the @@ -1081,12 +1087,12 @@ fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future git version. - + SEE ALSO , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-push.xml b/doc/source/en/TortoiseGit/git_doc/git-push.xml index fb31c35b8..9c174b56f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-push.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-push.xml @@ -1,18 +1,16 @@ - + -
- + git-push(1) git-push(1) - - + NAME git-push - Update remote refs along with associated objects - + SYNOPSIS
git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] @@ -20,7 +18,7 @@ [<repository> [<refspec>…]]
- + DESCRIPTION Updates remote refs using local refs, while sending objects necessary to complete the given refs. @@ -28,8 +26,8 @@ necessary to complete the given refs. every time you push into it, by setting up hooks there. See documentation for . - -OPTIONS<anchor id="OPTIONS" xreflabel="[OPTIONS]"/> + +OPTIONS<anchor id="git-push(1)_OPTIONS" xreflabel="[OPTIONS]"/> @@ -39,8 +37,8 @@ documentation for . The "remote" repository that is destination of a push operation. This parameter can be either a URL - (see the section GIT URLS below) or the name - of a remote (see the section REMOTES below). + (see the section GIT URLS below) or the name + of a remote (see the section REMOTES below). @@ -54,7 +52,9 @@ documentation for . +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>. It is used to specify with what <src> object the <dst> ref - in the remote repository is to be updated. + in the remote repository is to be updated. If not specified, + the behavior of the command is controlled by the push.default + configuration variable. The <src> is often the name of the branch you would want to push, but it can be any arbitrary "SHA-1 expression", such as master~4 or @@ -77,7 +77,8 @@ directs git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line -nor in any Push line of the corresponding remotes file---see below). +nor in any Push line of the corresponding remotes file---see below) and +no push.default configuration variable is set. @@ -300,26 +301,35 @@ useful if you write an alias or script around git push. ---recurse-submodules=check +--recurse-submodules=check|on-demand - Check whether all submodule commits used by the revisions to be - pushed are available on a remote tracking branch. Otherwise the - push will be aborted and the command will exit with non-zero status. + Make sure all submodule commits used by the revisions to be + pushed are available on a remote-tracking branch. If check is + used git will verify that all submodule commits that changed in + the revisions to be pushed are available on at least one remote + of the submodule. If any commits are missing the push will be + aborted and exit with non-zero status. If on-demand is used + all submodules that changed in the revisions to be pushed will + be pushed. If on-demand was not able to push all necessary + revisions it will also be aborted and exit with non-zero status. - -GIT URLS<anchor id="URLS" xreflabel="[URLS]"/> + +GIT URLS<anchor id="git-push(1)_URLS" xreflabel="[URLS]"/> In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git supports ssh, git, http, and https protocols (in addition, ftp, +and ftps can be used for fetching and rsync can be used for fetching +and pushing, but these are inefficient and deprecated; do not use +them). +The following syntaxes may be used with them: @@ -427,8 +437,8 @@ configuration section of the form: "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL. - -REMOTES<anchor id="REMOTES" xreflabel="[REMOTES]"/> + +REMOTES<anchor id="git-push(1)_REMOTES" xreflabel="[REMOTES]"/> The name of one of the following can be used instead of a URL as <repository> argument: @@ -450,7 +460,7 @@ a file in the $GIT_DIR/branches directory. All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default. -
+
Named remote in configuration file You can choose to provide the name of a remote which you had previously configured using , @@ -467,7 +477,7 @@ config file would appear like this: The <pushurl> is used for pushes only. It is optional and defaults to <url>.
-
+
Named file in <emphasis>$GIT_DIR/remotes</emphasis> You can choose to provide the name of a file in $GIT_DIR/remotes. The URL @@ -483,7 +493,7 @@ following format: Multiple Push: and Pull: lines may be specified for additional branch mappings.
-
+
Named file in <emphasis>$GIT_DIR/branches</emphasis> You can choose to provide the name of a file in $GIT_DIR/branches. @@ -501,7 +511,7 @@ refspecs, if you don't provide one on the command line. HEAD:refs/heads/<head>
- + OUTPUT The output of "git push" depends on the transport method used; this section describes the output when pushing over the git protocol (either @@ -678,7 +688,7 @@ reason - + Note about fast-forwards When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a @@ -694,7 +704,8 @@ leading to commit A. The history looks like this: / ---X---A Further suppose that the other person already pushed changes leading to A -back to the original repository you two obtained the original commit X. +back to the original repository from which you two obtained the original +commit X. The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward. But if you try to push, you will attempt to update the branch (that @@ -735,7 +746,7 @@ you are certain that nobody in the meantime fetched your earlier commit A overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history. - + Examples @@ -760,7 +771,8 @@ a case where you do mean to lose history. git push origin :. The default behavior of this command when no <refspec> is given can be -configured by setting the push option of the remote. +configured by setting the push option of the remote, or the push.default +configuration variable. For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for @@ -774,7 +786,7 @@ the ones in the examples below) can be configured as the default for Push "matching" branches to origin. See - <refspec> in the OPTIONS section above for a + <refspec> in the OPTIONS section above for a description of "matching" branches. @@ -806,15 +818,25 @@ the ones in the examples below) can be configured as the default for -git push origin master:satellite/master dev:satellite/dev +git push mothership master:satellite/master dev:satellite/dev Use the source ref that matches master (e.g. refs/heads/master) to update the ref that matches satellite/master (most probably - refs/remotes/satellite/master) in the origin repository, then + refs/remotes/satellite/master) in the mothership repository; do the same for dev and satellite/dev. +This is to emulate git fetch run on the mothership using git +push that is run in the opposite direction in order to integrate +the work done on satellite, and is often necessary when you can +only make connection in one way (i.e. satellite can ssh into +mothership but mothership cannot initiate connection to satellite +because the latter is behind a firewall or does not run sshd). +After running this git push on the satellite machine, you would +ssh into the mothership and run git merge there to complete the +emulation of git pull that were run on mothership to pull changes +made on satellite. @@ -879,8 +901,8 @@ a git gc command on the origin repository. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-quiltimport.xml b/doc/source/en/TortoiseGit/git_doc/git-quiltimport.xml index 2b6a960a4..541679d85 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-quiltimport.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-quiltimport.xml @@ -1,24 +1,22 @@ - + -
- + git-quiltimport(1) git-quiltimport(1) - - + NAME git-quiltimport - Applies a quilt patchset onto the current branch - + SYNOPSIS
git quiltimport [--dry-run | -n] [--author <author>] [--patches <dir>]
- + DESCRIPTION Applies a quilt patchset onto the current git branch, preserving the patch boundaries, patch order, and patch descriptions present @@ -31,7 +29,7 @@ interactively enter the author of the patch. If a subject is not found in the patch description the patch name is preserved as the 1 line subject in the git description. - + OPTIONS @@ -77,8 +75,8 @@ variable. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-read-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-read-tree.xml index ce708e2c6..a4237c65e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-read-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-read-tree.xml @@ -1,18 +1,16 @@ - + -
- + git-read-tree(1) git-read-tree(1) - - + NAME git-read-tree - Reads tree information into the index - + SYNOPSIS
git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] @@ -21,7 +19,7 @@ (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])
- + DESCRIPTION Reads the tree information given by <tree-ish> into the index, but does not actually update any of the files it "caches". (see: @@ -33,7 +31,7 @@ the files in the work tree with the result of the merge. Trivial merges are done by git read-tree itself. Only conflicting paths will be in unmerged state when git read-tree returns. - + OPTIONS @@ -246,13 +244,13 @@ when both sides add a path identically. The resolution - + Merging If -m is specified, git read-tree can perform 3 kinds of merge, a single tree merge if only 1 tree is given, a fast-forward merge with 2 trees, or a 3-way merge if 3 trees are provided. -
+
Single Tree Merge If only 1 tree is specified, git read-tree operates as if the user did not specify -m, except that if the original index has an entry for a @@ -265,7 +263,7 @@ the stuff that really changed. This is used to avoid unnecessary false hits when git diff-files is run after git read-tree.
-
+
Two Tree Merge Typically, this is invoked as git read-tree -m $H $M, where $H is the head commit of the current repository, and $M is the head @@ -345,7 +343,7 @@ the initial checkout from happening, so the rule is modified to use M (new tree) only when the content of the index is empty. Otherwise the removal of the path is kept as long as $H and $M are the same.
-
+
3-Way Merge Each "index" entry has two bits worth of "stage" state. stage 0 is the normal one, and is the only one you'd see in any kind of normal use. @@ -491,7 +489,7 @@ middle of doing, and when your working tree is ready (i.e. you have finished your work-in-progress), attempt the merge again.
- + Sparse checkout "Sparse checkout" allows populating the working directory sparsely. It uses the skip-worktree bit (see ) to tell @@ -524,13 +522,13 @@ read-tree and similar commands is disabled by default. You need to turn core.sparseCheckout on in order to have sparse checkout support. - + SEE ALSO ; ; - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-rebase.xml b/doc/source/en/TortoiseGit/git_doc/git-rebase.xml index 4547d42d2..414dd8286 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-rebase.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-rebase.xml @@ -1,28 +1,26 @@ - + -
- + git-rebase(1) git-rebase(1) - - + NAME git-rebase - Forward-port local commits to the updated upstream head - + SYNOPSIS
-git rebase [-i | --interactive] [options] [--onto <newbase>] +git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] -git rebase [-i | --interactive] [options] --onto <newbase> +git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -git rebase --continue | --skip | --abort +git rebase --continue | --skip | --abort | --edit-todo
- + DESCRIPTION If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise @@ -136,7 +134,7 @@ desired resolution, you can continue the rebasing process with Alternatively, you can undo the git rebase with git rebase --abort - + CONFIGURATION @@ -162,12 +160,12 @@ rebase.autosquash - + OPTIONS -<newbase> +--onto <newbase> @@ -229,6 +227,17 @@ leave out at most one of A and B, in which case it defaults to HEAD. +--keep-empty + + + + Keep the commits that do not change anything from its + parents in the result. + + + + + --skip @@ -239,6 +248,16 @@ leave out at most one of A and B, in which case it defaults to HEAD. +--edit-todo + + + + Edit the todo list during an interactive rebase. + + + + + -m @@ -288,7 +307,7 @@ which makes little sense. Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, -s recursive. Note the reversal of ours and - theirs as noted in above for the -m option. + theirs as noted above for the -m option. @@ -461,16 +480,42 @@ idea unless you know what you are doing (see BUGS below). +-x <cmd> + + +--exec <cmd> + + + + Append "exec <cmd>" after each line creating a commit in the + final history. <cmd> will be interpreted as one or more shell + commands. + +This option can only be used with the --interactive option +(see INTERACTIVE MODE below). +You may execute several commands by either using one instance of --exec +with several commands: +git rebase -i --exec "cmd1 && cmd2 && ..." +or by giving more than one --exec: +git rebase -i --exec "cmd1" --exec "cmd2" --exec ... +If --autosquash is used, "exec" lines will not be appended for +the intermediate commits, and will only appear at the end of each +squash/fixup series. + + + + --root Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase - the root commit(s) on a branch. Must be used with --onto, and + the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of - <upstream>). When used together with --preserve-merges, all - root commits will be rewritten to have <newbase> as parent + <upstream>) whereas without --onto it will operate on every change. + When used together with both --onto and --preserve-merges, + all root commits will be rewritten to have <newbase> as parent instead. @@ -516,7 +561,7 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). - + MERGE STRATEGIES The merge mechanism (git-merge and git-pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies @@ -566,6 +611,7 @@ ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. + For a binary file, the entire contents are taken from our side. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything @@ -578,7 +624,7 @@ theirs - This is opposite of ours. + This is the opposite of ours. @@ -734,7 +780,7 @@ subtree - + NOTES You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE @@ -745,7 +791,7 @@ reject the rebase if it isn't appropriate. Please see the template pre-rebase hook script for an example. Upon completion, <branch> will be the current branch. - + INTERACTIVE MODE Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can @@ -871,8 +917,19 @@ continue with git rebase --continue. in $SHELL, or the default shell if $SHELL is not set), so you can use shell features (like "cd", ">", ";" …). The command is run from the root of the working tree. +$ git rebase -i --exec "make test" +This command lets you check that intermediate commits are compilable. +The todo list becomes like that: +pick 5928aea one +exec make test +pick 04d0fda two +exec make test +pick ba46169 three +exec make test +pick f4593f9 four +exec make test - + SPLITTING COMMITS In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this @@ -927,7 +984,7 @@ consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary. - + RECOVERING FROM UPSTREAM REBASE Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to @@ -988,7 +1045,7 @@ Hard case: The changes are not the same. -
+
The easy case Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase @@ -1004,7 +1061,7 @@ changes that are already present in the new upstream. So if you say \ *---*---* topic
-
+
The hard case Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase. @@ -1039,7 +1096,7 @@ saying (for the reflog case, and assuming you are on topic case" recovery too!
- + BUGS The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and @@ -1054,8 +1111,8 @@ reorder commits tend to produce counterintuitive results. / 1 --- 2 --- 4 --- 5 - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-receive-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-receive-pack.xml index b9728f199..ab5e87432 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-receive-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-receive-pack.xml @@ -1,24 +1,22 @@ - + -
- + git-receive-pack(1) git-receive-pack(1) - - + NAME git-receive-pack - Receive what is pushed into the repository - + SYNOPSIS
git-receive-pack <directory>
- + DESCRIPTION Invoked by git send-pack and updates the repository with the information fed from the remote end. @@ -36,7 +34,7 @@ post-update hooks found in the Documentation/howto directory. option, which tells it if updates to a ref should be denied if they are not fast-forwards. - + OPTIONS @@ -51,7 +49,7 @@ are not fast-forwards. - + pre-receive Hook Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists and is executable, it will be invoked once with no parameters. The @@ -70,7 +68,7 @@ will be performed, and the update, post-receive and post-update hooks will not be invoked either. This can be useful to quickly bail out if the update is not to be supported. - + update Hook Before each ref is updated, if $GIT_DIR/hooks/update file exists and is executable, it is invoked once per ref, with three parameters: @@ -88,7 +86,7 @@ ensure the ref will actually be updated, it is only a prerequisite. As such it is not a good idea to send notices (e.g. email) from this hook. Consider using the post-receive hook instead. - + post-receive Hook After all refs were updated (or attempted to be updated), if any ref update was successful, and if $GIT_DIR/hooks/post-receive @@ -129,7 +127,7 @@ after it was updated by git-receive-pack, but before the ho to evaluate it. It is recommended that hooks rely on sha1-new rather than the current value of refname. - + post-update Hook After all other processing, if at least one ref was updated, and if $GIT_DIR/hooks/post-update file exists and is executable, then @@ -143,12 +141,12 @@ if the repository is packed and is served via a dumb transport. #!/bin/sh exec git update-server-info - + SEE ALSO , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-reflog.xml b/doc/source/en/TortoiseGit/git_doc/git-reflog.xml index 39817a650..2394004bd 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-reflog.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-reflog.xml @@ -1,24 +1,22 @@ - + -
- + git-reflog(1) git-reflog(1) - - + NAME git-reflog - Manage reflog information - + SYNOPSIS
git reflog <subcommand> <options>
- + DESCRIPTION The command takes various subcommands, and different options depending on the subcommand: @@ -49,7 +47,7 @@ more details. To delete single entries from the reflog, use the subcommand "delete" and specify the exact entry (e.g. "git reflog delete master@{2}"). - + OPTIONS @@ -142,8 +140,8 @@ them. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-relink.xml b/doc/source/en/TortoiseGit/git_doc/git-relink.xml index 510aabe5d..bce25612d 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-relink.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-relink.xml @@ -1,30 +1,28 @@ - + -
- + git-relink(1) git-relink(1) - - + NAME git-relink - Hardlink common objects in local repositories - + SYNOPSIS
git relink [--safe] <dir>… <master_dir>
- + DESCRIPTION This will scan 1 or more object repositories and look for objects in common with a master repository. Objects not already hardlinked to the master repository will be replaced with a hardlink to the master repository. - + OPTIONS @@ -50,8 +48,8 @@ repository will be replaced with a hardlink to the master repository. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-remote-ext.xml b/doc/source/en/TortoiseGit/git_doc/git-remote-ext.xml index b3312d391..d3f71195e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-remote-ext.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-remote-ext.xml @@ -1,24 +1,22 @@ - + -
- + git-remote-ext(1) git-remote-ext(1) - - + NAME git-remote-ext - Bridge smart transport to external command. - + SYNOPSIS
git remote add <nick> "ext::<command>[ <arguments>…]"
- + DESCRIPTION This remote helper uses the specified <command> to connect to a remote git server. @@ -103,7 +101,7 @@ some tunnel. - + ENVIRONMENT VARIABLES: @@ -118,7 +116,7 @@ GIT_TRANSLOOP_DEBUG - + ENVIRONMENT VARIABLES PASSED TO COMMAND: @@ -145,7 +143,7 @@ GIT_EXT_SERVICE_NOPREFIX - + EXAMPLES: This remote helper is transparently used by git when you use commands such as "git fetch <URL>", "git clone <URL>", @@ -232,13 +230,13 @@ begins with ext::. Examples: - + Documentation Documentation by Ilari Liusvaara, Jonathan Nieder and the git list <git@vger.kernel.org> - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-remote-fd.xml b/doc/source/en/TortoiseGit/git_doc/git-remote-fd.xml index 9b1b71e7c..cf0e9d481 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-remote-fd.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-remote-fd.xml @@ -1,22 +1,20 @@ - + -
- + git-remote-fd(1) git-remote-fd(1) - - + NAME git-remote-fd - Reflect smart transport stream back to caller - + SYNOPSIS "fd::<infd>[,<outfd>][/<anything>]" (as URL) - + DESCRIPTION This helper uses specified file descriptors to connect to a remote git server. This is not meant for end users but for programs and scripts calling git @@ -32,7 +30,7 @@ and <outfd> being the outbound pipe. information to user in the URL in case that URL is displayed in some context. - + ENVIRONMENT VARIABLES @@ -47,7 +45,7 @@ GIT_TRANSLOOP_DEBUG - + EXAMPLES @@ -95,12 +93,12 @@ GIT_TRANSLOOP_DEBUG - + Documentation Documentation by Ilari Liusvaara and the git list <git@vger.kernel.org> - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-remote-helpers.xml b/doc/source/en/TortoiseGit/git_doc/git-remote-helpers.xml index 703469d32..529f0a7c8 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-remote-helpers.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-remote-helpers.xml @@ -1,24 +1,22 @@ - + -
- + git-remote-helpers(1) git-remote-helpers(1) - - + NAME git-remote-helpers - Helper programs to interact with remote repositories - + SYNOPSIS
git remote-<transport> <repository> [<URL>]
- + DESCRIPTION Remote helper programs are normally not used directly by end users, but they are invoked by git when it needs to interact with remote @@ -40,7 +38,34 @@ transport protocols, such as git-remote-http, git git-remote-ftp and git-remote-ftps. They implement the capabilities fetch, option, and push. - + +INVOCATION +Remote helper programs are invoked with one or (optionally) two +arguments. The first argument specifies a remote repository as in git; +it is either the name of a configured remote or a URL. The second +argument specifies a URL; it is usually of the form +<transport>://<address>, but any arbitrary string is possible. +The GIT_DIR environment variable is set up for the remote helper +and can be used to determine where to store additional data or from +which directory to invoke auxiliary git commands. +When git encounters a URL of the form <transport>://<address>, where +<transport> is a protocol that it cannot handle natively, it +automatically invokes git remote-<transport> with the full URL as +the second argument. If such a URL is encountered directly on the +command line, the first argument is the same as the second, and if it +is encountered in a configured remote, the first argument is the name +of that remote. +A URL of the form <transport>::<address> explicitly instructs git to +invoke git remote-<transport> with <address> as the second +argument. If such a URL is encountered directly on the command line, +the first argument is <address>, and if it is encountered in a +configured remote, the first argument is the name of that remote. +Additionally, when a configured remote has remote.<name>.vcs set to +<transport>, git explicitly invokes git remote-<transport> with +<name> as the first argument. If set, the second argument is +remote.<name>.url; otherwise, the second argument is omitted. + + INPUT FORMAT Git sends the remote helper a list of commands on standard input, one per line. The first command is always the capabilities command, in @@ -52,226 +77,201 @@ in the remainder of the command stream. (indicated in the documentation of the relevant commands), this blank line is followed by a payload in some other protocol (e.g., the pack protocol), while in others it indicates the end of input. -
+
Capabilities Each remote helper is expected to support only a subset of commands. The operations a helper supports are declared to git in the response to the capabilities command (see COMMANDS, below). +In the following, we list all defined capabilities and for +each we list which commands a helper with that capability +must provide. +
+Capabilities for Pushing -option +connect - For specifying settings like verbosity (how much output to - write to stderr) and depth (how much history is wanted in the - case of a shallow clone) that affect how other commands are - carried out. + Can attempt to connect to git receive-pack (for pushing), + git upload-pack, etc for communication using + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. +Supported commands: connect. -connect +push - For fetching and pushing using git's native packfile protocol - that requires a bidirectional, full-duplex connection. + Can discover remote refs and push local commits and the + history leading up to them to new or existing remote refs. +Supported commands: list for-push, push. -push +export - For listing remote refs and pushing specified objects from the - local object store to remote refs. + Can discover remote refs and push specified objects from a + fast-import stream to remote refs. +Supported commands: list for-push, export. + +If a helper advertises connect, git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the connect command under COMMANDS). +When choosing between push and export, git prefers push. +Other frontends may have some other order of preference. +
+
+Capabilities for Fetching + -fetch +connect - For listing remote refs and fetching the associated history to - the local object store. + Can try to connect to git upload-pack (for fetching), + git receive-pack, etc for communication using the + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. +Supported commands: connect. -import +fetch - For listing remote refs and fetching the associated history as - a fast-import stream. + Can discover remote refs and transfer objects reachable from + them to the local object store. +Supported commands: list, fetch. -refspec <refspec> +import - This modifies the import capability, allowing the produced - fast-import stream to modify refs in a private namespace - instead of writing to refs/heads or refs/remotes directly. - It is recommended that all importers providing the import - capability use this. + Can discover remote refs and output objects reachable from + them as a stream in fast-import format. -A helper advertising the capability -refspec refs/heads/*:refs/svn/origin/branches/* -is saying that, when it is asked to import refs/heads/topic, the -stream it outputs will update the refs/svn/origin/branches/topic -ref. -This capability can be advertised multiple times. The first -applicable refspec takes precedence. The left-hand of refspecs -advertised with this capability must cover all refs reported by -the list command. If no refspec capability is advertised, -there is an implied refspec *:*. +Supported commands: list, import. +If a helper advertises connect, git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the connect command under COMMANDS). +When choosing between fetch and import, git prefers fetch. +Other frontends may have some other order of preference.
-
-Capabilities for Pushing +
+Miscellaneous capabilities -connect - - - - Can attempt to connect to git receive-pack (for pushing), - git upload-pack, etc for communication using the - packfile protocol. - -Supported commands: connect. - - - - -push +option - Can discover remote refs and push local commits and the - history leading up to them to new or existing remote refs. + For specifying settings like verbosity (how much output to + write to stderr) and depth (how much history is wanted in the + case of a shallow clone) that affect how other commands are + carried out. -Supported commands: list for-push, push. - -If a helper advertises both connect and push, git will use -connect if possible and fall back to push if the helper requests -so when connecting (see the connect command under COMMANDS). -
-
-Capabilities for Fetching - -connect +refspec <refspec> - Can try to connect to git upload-pack (for fetching), - git receive-pack, etc for communication using the - packfile protocol. + This modifies the import capability, allowing the produced + fast-import stream to modify refs in a private namespace + instead of writing to refs/heads or refs/remotes directly. + It is recommended that all importers providing the import + capability use this. -Supported commands: connect. +A helper advertising the capability +refspec refs/heads/*:refs/svn/origin/branches/* +is saying that, when it is asked to import refs/heads/topic, the +stream it outputs will update the refs/svn/origin/branches/topic +ref. +This capability can be advertised multiple times. The first +applicable refspec takes precedence. The left-hand of refspecs +advertised with this capability must cover all refs reported by +the list command. If no refspec capability is advertised, +there is an implied refspec *:*. -fetch +bidi-import - Can discover remote refs and transfer objects reachable from - them to the local object store. + This modifies the import capability. + The fast-import commands cat-blob and ls can be used by remote-helpers + to retrieve information about blobs and trees that already exist in + fast-import's memory. This requires a channel from fast-import to the + remote-helper. + If it is advertised in addition to "import", git establishes a pipe from + fast-import to the remote-helper's stdin. + It follows that git and fast-import are both connected to the + remote-helper's stdin. Because git can send multiple commands to + the remote-helper it is required that helpers that use bidi-import + buffer all import commands of a batch before sending data to fast-import. + This is to prevent mixing commands and fast-import responses on the + helper's stdin. -Supported commands: list, fetch. -import +export-marks <file> - Can discover remote refs and output objects reachable from - them as a stream in fast-import format. + This modifies the export capability, instructing git to dump the + internal marks table to <file> when complete. For details, + read up on --export-marks=<file> in . -Supported commands: list, import. - -If a helper advertises connect, git will use it if possible and -fall back to another capability if the helper requests so when -connecting (see the connect command under COMMANDS). -When choosing between fetch and import, git prefers fetch. -Other frontends may have some other order of preference. - -refspec <refspec> +import-marks <file> - This modifies the import capability. + This modifies the export capability, instructing git to load the + marks specified in <file> before processing any input. For details, + read up on --import-marks=<file> in . -A helper advertising -refspec refs/heads/*:refs/svn/origin/branches/* -in its capabilities is saying that, when it handles -import refs/heads/topic, the stream it outputs will update the -refs/svn/origin/branches/topic ref. -This capability can be advertised multiple times. The first -applicable refspec takes precedence. The left-hand of refspecs -advertised with this capability must cover all refs reported by -the list command. If no refspec capability is advertised, -there is an implied refspec *:*.
+
- -INVOCATION -Remote helper programs are invoked with one or (optionally) two -arguments. The first argument specifies a remote repository as in git; -it is either the name of a configured remote or a URL. The second -argument specifies a URL; it is usually of the form -<transport>://<address>, but any arbitrary string is possible. -The GIT_DIR environment variable is set up for the remote helper -and can be used to determine where to store additional data or from -which directory to invoke auxiliary git commands. -When git encounters a URL of the form <transport>://<address>, where -<transport> is a protocol that it cannot handle natively, it -automatically invokes git remote-<transport> with the full URL as -the second argument. If such a URL is encountered directly on the -command line, the first argument is the same as the second, and if it -is encountered in a configured remote, the first argument is the name -of that remote. -A URL of the form <transport>::<address> explicitly instructs git to -invoke git remote-<transport> with <address> as the second -argument. If such a URL is encountered directly on the command line, -the first argument is <address>, and if it is encountered in a -configured remote, the first argument is the name of that remote. -Additionally, when a configured remote has remote.<name>.vcs set to -<transport>, git explicitly invokes git remote-<transport> with -<name> as the first argument. If set, the second argument is -remote.<name>.url; otherwise, the second argument is omitted. - - + COMMANDS Commands are given by the caller on the helper's standard input, one per line. @@ -283,10 +283,11 @@ configured remote, the first argument is the name of that remote. Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with *, - which marks them mandatory for git version using the remote - helper to understand (unknown mandatory capability is fatal - error). + which marks them mandatory for git versions using the remote + helper to understand. Any unknown mandatory capability is a + fatal error. +Support for this command is mandatory. @@ -302,9 +303,25 @@ configured remote, the first argument is the name of that remote. the name; unrecognized attributes are ignored. The list ends with a blank line. -If push is supported this may be called as list for-push -to obtain the current refs prior to sending one or more push -commands to the helper. +See REF LIST ATTRIBUTES for a list of currently defined attributes. +Supported if the helper has the "fetch" or "import" capability. + + + + +list for-push + + + + Similar to list, except that it is used if and only if + the caller wants to the resulting ref list to prepare + push commands. + A helper supporting both push and fetch can use this + to distinguish for which operation the output of list + is going to be used, possibly reducing the amount + of work that needs to be performed. + +Supported if the helper has the "push" or "export" capability. @@ -320,6 +337,7 @@ commands to the helper. for it). Options should be set before other commands, and may influence the behavior of those commands. +See OPTIONS for a list of currently defined options. Supported if the helper has the "option" capability. @@ -334,7 +352,7 @@ commands to the helper. per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. + in the output of list with a sha1 may be fetched this way. Optionally may output a lock <file> line indicating a file under GIT_DIR/objects/pack which is keeping a pack until refs can be @@ -394,11 +412,35 @@ system. terminated with a blank line. For each batch of import, the remote helper should produce a fast-import stream terminated by a done command. +Note that if the bidi-import capability is used the complete batch +sequence has to be buffered before starting to send data to fast-import +to prevent mixing of commands and fast-import responses on the helper's +stdin. Supported if the helper has the "import" capability. +export + + + + Instructs the remote helper that any subsequent input is + part of a fast-import stream (generated by git fast-export) + containing objects which should be pushed to the remote. + +Especially useful for interoperability with a foreign versioning +system. +The export-marks and import-marks capabilities, if specified, +affect this command in so far as they are passed on to git +fast-export, which then will load/store a table of marks for +local objects. This can be used to implement for incremental +operations. +Supported if the helper has the "export" capability. + + + + connect <service> @@ -425,23 +467,14 @@ completing a valid response for the current command. Additional commands may be supported, as may be determined from capabilities reported by the helper. - + REF LIST ATTRIBUTES +The list command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. -for-push - - - - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. - - - - - unchanged @@ -453,8 +486,10 @@ capabilities reported by the helper. - + OPTIONS +The following options are defined and (under suitable circumstances) +set by git if the remote helper has the option capability. @@ -528,13 +563,13 @@ capabilities reported by the helper. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-remote-testgit.xml b/doc/source/en/TortoiseGit/git_doc/git-remote-testgit.xml index 770bf0937..56d082123 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-remote-testgit.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-remote-testgit.xml @@ -1,24 +1,22 @@ - + -
- + git-remote-testgit(1) git-remote-testgit(1) - - + NAME git-remote-testgit - Example remote-helper - + SYNOPSIS
git clone testgit::<source-repo> [<destination>]
- + DESCRIPTION This command is a simple remote-helper, that is used both as a testcase for the remote-helper functionality, and as an example to @@ -26,12 +24,12 @@ show remote-helper authors one possible implementation. The best way to learn more is to read the comments and source code in git-remote-testgit.py. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-remote.xml b/doc/source/en/TortoiseGit/git_doc/git-remote.xml index 37a3573a1..18ea747b4 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-remote.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-remote.xml @@ -1,24 +1,22 @@ - + -
- + git-remote(1) git-remote(1) - - + NAME git-remote - manage set of tracked repositories - + SYNOPSIS
git remote [-v | --verbose] git remote add [-t <branch>] [-m <master>] [-f] [--tags|--no-tags] [--mirror=<fetch|push>] <name> <url> git remote rename <old> <new> -git remote rm <name> +git remote remove <name> git remote set-head <name> (-a | -d | <branch>) git remote set-branches [--add] <name> <branch>… git remote set-url [--push] <name> <newurl> [<oldurl>] @@ -29,11 +27,11 @@ git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]
- + DESCRIPTION Manage the set of repositories ("remotes") whose branches you track. - + OPTIONS @@ -52,7 +50,7 @@ - + COMMANDS With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes. @@ -105,6 +103,9 @@ the configuration file format. +remove + + rm @@ -219,13 +220,13 @@ be updated. (See ). - + DISCUSSION The remote configuration is achieved using the remote.origin.url and remote.origin.fetch configuration variables. (See ). - + Examples @@ -261,14 +262,14 @@ $ git merge origin - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-repack.xml b/doc/source/en/TortoiseGit/git_doc/git-repack.xml index f34d79bd2..19949087a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-repack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-repack.xml @@ -1,24 +1,22 @@ - + -
- + git-repack(1) git-repack(1) - - + NAME git-repack - Pack unpacked objects in a repository - + SYNOPSIS
git repack [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [--window=<n>] [--depth=<n>]
- + DESCRIPTION This script is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize @@ -29,7 +27,7 @@ associated index file. Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc. - + OPTIONS @@ -194,7 +192,7 @@ other objects in that pack they already have locally. - + Configuration By default, the command passes --delta-base-offset option to git pack-objects; this typically results in slightly smaller packs, @@ -206,13 +204,13 @@ need to set the configuration variable repack.UseDeltaBaseOffset - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-replace.xml b/doc/source/en/TortoiseGit/git_doc/git-replace.xml index dab640a23..9e63d6a6a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-replace.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-replace.xml @@ -1,18 +1,16 @@ - + -
- + git-replace(1) git-replace(1) - - + NAME git-replace - Create, list, delete refs to replace objects - + SYNOPSIS
git replace [-f] <object> <replacement> @@ -20,14 +18,13 @@ git replace -l [<pattern>]
- + DESCRIPTION -Adds a replace reference in .git/refs/replace/ +Adds a replace reference in refs/replace/ namespace. The name of the replace reference is the SHA1 of the object that is replaced. The content of the replace reference is the SHA1 of the replacement object. -Unless -f is given, the replace reference must not yet exist in -.git/refs/replace/ directory. +Unless -f is given, the replace reference must not yet exist. Replacement references will be used by default by all git commands except those doing reachability traversal (prune, pack transfer and fsck). @@ -41,7 +38,7 @@ command using the --no-replace-objects option just after The GIT_NO_REPLACE_OBJECTS environment variable can be set to achieve the same effect as the --no-replace-objects option. - + OPTIONS @@ -80,7 +77,7 @@ achieve the same effect as the --no-replace-objects option. - + BUGS Comparing blobs or trees that have been replaced with those that replace them will not work properly. And using git reset --hard to @@ -91,14 +88,14 @@ pending objects. And of course things may break if an object of one type is replaced by an object of another type (for example a blob replaced by a commit). - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-repo-config.xml b/doc/source/en/TortoiseGit/git_doc/git-repo-config.xml index 5e04c2b23..5a2383471 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-repo-config.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-repo-config.xml @@ -1,30 +1,28 @@ - + -
- + git-repo-config(1) git-repo-config(1) - - + NAME git-repo-config - Get and set repository or global options - + SYNOPSIS
git repo-config …
- + DESCRIPTION This is a synonym for . Please refer to the documentation of that command. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-request-pull.xml b/doc/source/en/TortoiseGit/git_doc/git-request-pull.xml index 4ecf34a35..6cfe85dc5 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-request-pull.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-request-pull.xml @@ -1,29 +1,27 @@ - + -
- + git-request-pull(1) git-request-pull(1) - - + NAME git-request-pull - Generates a summary of pending changes - + SYNOPSIS
git request-pull [-p] <start> <url> [<end>]
- + DESCRIPTION Summarizes the changes between two commits to the standard output, and includes the given URL in the generated summary. - + OPTIONS @@ -68,8 +66,8 @@ the given URL in the generated summary. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-rerere.xml b/doc/source/en/TortoiseGit/git_doc/git-rerere.xml index c925bc8ae..40b71bdd1 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-rerere.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-rerere.xml @@ -1,24 +1,22 @@ - + -
- + git-rerere(1) git-rerere(1) - - + NAME git-rerere - Reuse recorded resolution of conflicted merges - + SYNOPSIS
git rerere [clear|forget <pathspec>|diff|remaining|status|gc]
- + DESCRIPTION In a workflow employing relatively long lived topic branches, the developer sometimes needs to resolve the same conflicts over @@ -31,7 +29,7 @@ hand resolutions to their corresponding automerge results. You need to set the configuration variable rerere.enabled in order to enable this command. - + COMMANDS Normally, git rerere is run without arguments or user-intervention. However, it has several commands that allow it to interact with @@ -112,7 +110,7 @@ variables respectively. - + DISCUSSION When your topic branch modifies an overlapping area that your master branch (or upstream) touched since your topic branch @@ -222,8 +220,8 @@ would conflict the same way as the test merge you resolved earlier. git rerere will be run by git rebase to help you resolve this conflict. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-reset.xml b/doc/source/en/TortoiseGit/git_doc/git-reset.xml index ce2c059c3..8d6ac9b29 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-reset.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-reset.xml @@ -1,26 +1,24 @@ - + -
- + git-reset(1) git-reset(1) - - + NAME git-reset - Reset current HEAD to the specified state - + SYNOPSIS
git reset [-q] [<commit>] [--] <paths>… git reset (--patch | -p) [<commit>] [--] [<paths>…] -git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>] +git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
- + DESCRIPTION In the first and second form, copy entries from <commit> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally @@ -64,14 +62,14 @@ section of to learn how to operate the - -git reset --<mode> [<commit>] +git reset [<mode>] [<commit>] This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and - the working tree depending on <mode>, which - must be one of the following: + the working tree depending on <mode>. If <mode> is omitted, + defaults to "--mixed". The <mode> must be one of the following: @@ -147,7 +145,7 @@ but carries forward unmerged index entries. If you want to undo a commit other than the latest on a branch, is your friend. - + OPTIONS @@ -165,7 +163,7 @@ but carries forward unmerged index entries. - + EXAMPLES @@ -173,13 +171,13 @@ but carries forward unmerged index entries. Undo add -$ edit +$ edit $ git add frotz.c filfre.c -$ mailx -$ git reset -$ git pull git://info.example.com/ nitfol +$ mailx +$ git reset +$ git pull git://info.example.com/ nitfol - + You are happily working on something, and find the changes in these files are in good order. You do not want to see them @@ -187,12 +185,12 @@ when you run "git diff", because you plan to work on other files and changes with these files are distracting. - + Somebody asks you to pull, and the changes sounds worthy of merging. - + However, you already dirtied the index (i.e. your index does not match the HEAD commit). But you know the pull you are going @@ -201,7 +199,7 @@ index changes for these two files. Your changes in working tree remain there. - + Then you can pull and merge, leaving frotz.c and filfre.c changes still in the working tree. @@ -216,23 +214,23 @@ Undo a commit and redo $ git commit ... -$ git reset --soft HEAD^ -$ edit -$ git commit -a -c ORIG_HEAD +$ git reset --soft HEAD^ +$ edit +$ git commit -a -c ORIG_HEAD - + This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset". - + Make corrections to working tree files. - + "reset" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to @@ -248,11 +246,11 @@ edit the message further, you can give -C option instead. Undo a commit, making it a topic branch -$ git branch topic/wip -$ git reset --hard HEAD~3 -$ git checkout topic/wip +$ git branch topic/wip +$ git reset --hard HEAD~3 +$ git checkout topic/wip - + You have made some commits, but realize they were premature to be in the "master" branch. You want to continue polishing @@ -260,12 +258,12 @@ them in a topic branch, so create "topic/wip" branch off of the current HEAD. - + Rewind the master branch to get rid of those three commits. - + Switch to "topic/wip" branch and keep working. @@ -279,9 +277,9 @@ Undo commits permanently $ git commit ... -$ git reset --hard HEAD~3 +$ git reset --hard HEAD~3 - + The last three commits (HEAD, HEAD^, and HEAD~2) were bad and you do not want to ever see them again. Do not do this if @@ -298,37 +296,37 @@ the implications of doing so.) Undo a merge or pull -$ git pull +$ git pull Auto-merging nitfol CONFLICT (content): Merge conflict in nitfol Automatic merge failed; fix conflicts and then commit the result. -$ git reset --hard -$ git pull . topic/branch +$ git reset --hard +$ git pull . topic/branch Updating from 41223... to 13134... Fast-forward -$ git reset --hard ORIG_HEAD +$ git reset --hard ORIG_HEAD - + Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later. - + "pull" has not made merge commit, so "git reset --hard" which is a synonym for "git reset --hard HEAD" clears the mess from the index file and the working tree. - + Merge a topic branch into the current branch, which resulted in a fast-forward. - + But you decided that the topic branch is not ready for public consumption yet. "pull" or "merge" always leaves the original @@ -345,14 +343,14 @@ and resets the tip of the branch to that commit. Undo a merge or pull inside a dirty working tree -$ git pull +$ git pull Auto-merging nitfol Merge made by recursive. nitfol | 20 +++++---- ... -$ git reset --merge ORIG_HEAD +$ git reset --merge ORIG_HEAD - + Even if you may have local modifications in your working tree, you can safely say "git pull" when you know @@ -360,7 +358,7 @@ that the change in the other branch does not overlap with them. - + After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running @@ -383,26 +381,26 @@ working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix. $ git checkout feature ;# you were working in "feature" branch and $ work work work ;# got interrupted -$ git commit -a -m "snapshot WIP" +$ git commit -a -m "snapshot WIP" $ git checkout master $ fix fix fix $ git commit ;# commit with real log $ git checkout feature -$ git reset --soft HEAD^ ;# go back to WIP state -$ git reset +$ git reset --soft HEAD^ ;# go back to WIP state +$ git reset - + This commit will get blown away so a throw-away log message is OK. - + This removes the WIP commit from the commit history, and sets your working tree to the state just before you made that snapshot. - + At this point the index file still has all the WIP changes you committed as snapshot WIP. This updates the index to show your @@ -421,22 +419,22 @@ Reset a single file in the index Suppose you have added a file to your index, but later decide you do not want to add it to your commit. You can remove the file from the index while keeping your changes with git reset. -$ git reset -- frotz.c -$ git commit -m "Commit files in index" -$ git add frotz.c +$ git reset -- frotz.c +$ git commit -m "Commit files in index" +$ git add frotz.c - + This removes the file from the index while keeping it in the working directory. - + This commits all other changes in the index. - + Adds the file to the index again. @@ -457,17 +455,17 @@ reset it while keeping the changes in your working tree. $ git tag start $ git checkout -b branch1 $ edit -$ git commit ... +$ git commit ... $ edit -$ git checkout -b branch2 -$ git reset --keep start +$ git checkout -b branch2 +$ git reset --keep start - + This commits your first edits in branch1. - + In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched @@ -475,7 +473,7 @@ In the ideal world, you could have realized that the earlier perfect. - + But you can use "reset --keep" to remove the unwanted commit after you switched to "branch2". @@ -486,7 +484,7 @@ But you can use "reset --keep" to remove the unwanted commit after - + DISCUSSION The tables below show what happens when running: git reset --option target @@ -576,8 +574,8 @@ entries: --keep (disallowed) X means any state and U means an unmerged index. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-rev-list.xml b/doc/source/en/TortoiseGit/git_doc/git-rev-list.xml index 17a1a62c4..d9bbd3d71 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-rev-list.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-rev-list.xml @@ -1,18 +1,16 @@ - + -
- + git-rev-list(1) git-rev-list(1) - - + NAME git-rev-list - Lists commit objects in reverse chronological order - + SYNOPSIS
git rev-list [ --max-count=<number> ] @@ -64,7 +62,7 @@ <commit>… [ -- <paths>… ]
- + DESCRIPTION List commits that are reachable by following the parent links from the given commit(s), but exclude commits that are reachable from the one(s) @@ -96,18 +94,26 @@ this reason, it has a lot of different options that enables it to be used by commands as different as git bisect and git repack. - + OPTIONS -
+
Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit +limiting may be applied. +Using more options generally further limits the output (e.g. +--since=<date1> limits to commits newer than <date1>, and using it +with --grep=<pattern> further limits to commits whose log message +has a line that matches <pattern>), unless otherwise noted. +Note that these are applied before commit ordering and formatting options, such as --reverse. --n number +-<number> + + +-n <number> --max-count=<number> @@ -177,7 +183,24 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one --author=<pattern>, + commits whose author matches any of the given patterns are + chosen (similarly for multiple --committer=<pattern>). + + + + + +--grep-reflog=<pattern> + + + + Limit the commits output to ones with reflog entries that + match the specified pattern (regular expression). With + more than one --grep-reflog, commits whose reflog message + matches any of the given patterns are chosen. It is an + error to use this option unless --walk-reflogs is in use. @@ -188,8 +211,13 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one --grep=<pattern>, commits whose message + matches any of the given patterns are chosen (but see + --all-match). +When --show-notes is in effect, the message from the notes as +if it is part of the log message. @@ -199,7 +227,7 @@ ordering and formatting options, such as --reverse. Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. @@ -218,6 +246,17 @@ ordering and formatting options, such as --reverse. +--basic-regexp + + + + Consider the limiting patterns to be basic regular expressions; + this is the default. + + + + + -E @@ -246,6 +285,17 @@ ordering and formatting options, such as --reverse. +--perl-regexp + + + + Consider the limiting patterns to be Perl-compatible regexp. + Requires libpcre to be compiled in. + + + + + --remove-empty @@ -542,7 +592,7 @@ See also .
-
+
History Simplification Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of @@ -904,7 +954,7 @@ above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).
-
+
Bisection Helpers @@ -973,31 +1023,42 @@ after all the sorted commit objects, there will be the same text as if
-
+
Commit Ordering By default, the commits are shown in reverse chronological order. ---topo-order +--date-order - This option makes them appear in topological order (i.e. - descendant commits are shown before their parents). + Show no parents before all of its children are shown, but + otherwise show commits in the commit timestamp order. ---date-order +--topo-order - This option is similar to --topo-order in the sense that no - parent comes before all of its children, but otherwise things - are still ordered in the commit timestamp order. + Show no parents before all of its children are shown, and + avoid showing commits on multiple lines of history + intermixed. +For example, in a commit history like this: + ---1----2----4----7 + \ \ + 3----5----6----8--- +where the numbers denote the order of commit timestamps, git +rev-list and friends with --date-order show the commits in the +timestamp order: 8 7 6 5 4 3 2 1. +With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 +3 1); some older commits are shown before newer ones in order to +avoid showing the commits from two parallel development track mixed +together. @@ -1013,7 +1074,7 @@ after all the sorted commit objects, there will be the same text as if
-
+
Object Traversal These options are mostly targeted for packing of git repositories. @@ -1057,11 +1118,16 @@ after all the sorted commit objects, there will be the same text as if ---no-walk +--no-walk[=(sorted|unsorted)] - Only show the given revs, but do not traverse their ancestors. + Only show the given commits, but do not traverse their ancestors. + This has no effect if a range is specified. If the argument + "unsorted" is given, the commits are show in the order they were + given on the command line. Otherwise (if "sorted" or no argument + was given), the commits are show in reverse chronological order + by commit time. @@ -1077,7 +1143,7 @@ after all the sorted commit objects, there will be the same text as if
-
+
Commit Formatting Using these options, will act similar to the more specialized family of commit log tools: , @@ -1208,6 +1274,17 @@ being displayed. Examples: "--notes=foo" will show only notes from +--show-signature + + + + Check the validity of a signed commit object by passing the signature + to gpg --verify and show the output. + + + + + --relative-date @@ -1344,7 +1421,7 @@ format, often found in E-mail messages.
- + PRETTY FORMATS If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is @@ -1601,6 +1678,21 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +%GG: raw verification message from GPG for a signed commit + + + + +%G?: show either "G" for Good or "B" for Bad for a signed commit + + + + +%GS: show the name of the signer for a signed commit + + + + %gD: reflog selector, e.g., refs/stash@{1} @@ -1731,8 +1823,8 @@ $ git log -2 --pretty=%h 4da45bef - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-rev-parse.xml b/doc/source/en/TortoiseGit/git_doc/git-rev-parse.xml index 7cdd21b8d..ef53f2ca0 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-rev-parse.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-rev-parse.xml @@ -1,24 +1,22 @@ - + -
- + git-rev-parse(1) git-rev-parse(1) - - + NAME git-rev-parse - Pick out and massage parameters - + SYNOPSIS
git rev-parse [ --option ] <args>…
- + DESCRIPTION Many git porcelainish commands take mixture of flags (i.e. parameters that begin with a dash -) and parameters @@ -27,7 +25,7 @@ and flags and parameters for the other commands they use downstream of git rev-list. This command is used to distinguish between them. - + OPTIONS @@ -223,6 +221,19 @@ distinguish between them. +--disambiguate=<prefix> + + + + Show every object whose name begins with the given prefix. + The <prefix> must be at least 4 hexadecimal digits long to + avoid listing each and every object in the repository by + mistake. + + + + + --all @@ -307,7 +318,8 @@ shown. If the pattern does not contain a globbing character (? Show $GIT_DIR if defined. Otherwise show the path to - the .git directory, relative to the current directory. + the .git directory. The path shown, when relative, is + relative to the current working directory. If $GIT_DIR is not defined and the current directory is not detected to lie in a git repository or work tree @@ -426,7 +438,7 @@ print a message to stderr and exit with nonzero status. - + SPECIFYING REVISIONS A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called an extended SHA1 @@ -470,20 +482,20 @@ blobs contained in a commit. object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean. - When ambiguous, a <name> is disambiguated by taking the + When ambiguous, a <refname> is disambiguated by taking the first match in the following rules: -If $GIT_DIR/<name> exists, that is what you mean (this is usually +If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD); -otherwise, refs/<name> if it exists; +otherwise, refs/<refname> if it exists; @@ -493,17 +505,17 @@ otherwise, refs/tags/<refname> if it exists; -otherwise, refs/heads/<name> if it exists; +otherwise, refs/heads/<refname> if it exists; -otherwise, refs/remotes/<name> if it exists; +otherwise, refs/remotes/<refname> if it exists; -otherwise, refs/remotes/<name>/HEAD if it exists. +otherwise, refs/remotes/<refname>/HEAD if it exists. HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a remote repository @@ -517,7 +529,9 @@ when you run git merge. CHERRY_PICK_HEAD records the commit which you are cherry-picking when you run git cherry-pick. Note that any of the refs/* cases above may come either from -the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. +the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. +While the ref name encoding is unspecified, UTF-8 is prefered as +some output processing may assume ref names in UTF-8. @@ -741,7 +755,7 @@ H = D^2 = B^^2 = A^^^2 = A~2^2 I = F^ = B^3^ = A^^3^ J = F^2 = B^3^2 = A^^3^2 - + SPECIFYING RANGES History traversing commands such as git log operate on a set of commits, not just a single commit. To these commands, @@ -761,21 +775,101 @@ of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable from either one of r1 or r2 but not from both. +In these two shorthands, you can omit one end and let it default to HEAD. +For example, origin.. is a shorthand for origin..HEAD and asks "What +did I do since I forked from the origin branch?" Similarly, ..origin +is a shorthand for HEAD..origin and asks "What did the origin do since +I forked from them?" Note that .. would mean HEAD..HEAD which is an +empty range that is both reachable and unreachable from HEAD. Two other shorthands for naming a set that is formed by a commit and its parent commits exist. The r1^@ notation means all parents of r1. r1^! includes commit r1 but excludes all of its parents. +To summarize: + + + +<rev> + + + + Include commits that are reachable from (i.e. ancestors of) + <rev>. + + + + + +^<rev> + + + + Exclude commits that are reachable from (i.e. ancestors of) + <rev>. + + + + + +<rev1>..<rev2> + + + + Include commits that are reachable from <rev2> but exclude + those that are reachable from <rev1>. + + + + + +<rev1>...<rev2> + + + + Include commits that are reachable from either <rev1> or + <rev2> but exclude those that are reachable from both. + + + + + +<rev>^@, e.g. HEAD^@ + + + + A suffix ^ followed by an at sign is the same as listing + all parents of <rev> (meaning, include anything reachable from + its parents, but not the commit itself). + + + + + +<rev>^!, e.g. HEAD^! + + + + A suffix ^ followed by an exclamation mark is the same + as giving commit <rev> and then all its parents prefixed with + ^ to exclude them (and their ancestors). + + + + Here are a handful of examples: D G H D D F G H I J D F ^G D H D ^D B E I J F B +B..C C B...C G H D E B C ^D B C E I J F B C +C I J F C C^@ I J F +C^! C F^! D G H D F - + PARSEOPT In --parseopt mode, git rev-parse helps massaging options to bring to shell scripts the same facilities C builtins have. It works as an option normalizer @@ -786,7 +880,7 @@ to replace the arguments with normalized ones. In case of error, it outputs usage on the standard error stream, and exits with code 129. Note: Make sure you quote the result when passing it to eval. See below for an example. -
+
Input Format git rev-parse --parseopt input format is fully text based. It has two parts, separated by a line that contains only --. The lines before the separator @@ -849,7 +943,7 @@ as the help associated to the option. as option group headers (start the line with a space to create such lines on purpose).
-
+
Example OPTS_SPEC="\ some-command [options] <args>... @@ -867,7 +961,7 @@ C? option C with an optional argument" eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
- + SQ-QUOTE In --sq-quote mode, git rev-parse echoes on the standard output a single line suitable for sh(1) eval. This line is made by @@ -876,7 +970,7 @@ quoting the arguments is done. If you want command input to still be interpreted as usual by git rev-parse before the output is shell quoted, see the --sq option. -
+
Example $ cat >your-git-script.sh <<\EOF #!/bin/sh @@ -889,7 +983,7 @@ EOF $ sh your-git-script.sh "a b'c"
- + EXAMPLES @@ -914,8 +1008,8 @@ Same as above: - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-revert.xml b/doc/source/en/TortoiseGit/git_doc/git-revert.xml index f0fda987c..90d46ffe2 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-revert.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-revert.xml @@ -1,18 +1,16 @@ - + -
- + git-revert(1) git-revert(1) - - + NAME git-revert - Revert some existing commits - + SYNOPSIS
git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>… @@ -21,7 +19,7 @@ git revert --abort
- + DESCRIPTION Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record @@ -36,7 +34,7 @@ should see , specifically the git ch <commit> -- <filename> syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. - + OPTIONS @@ -166,7 +164,7 @@ effect to your index in a row. - + SEQUENCER SUBCOMMANDS @@ -205,7 +203,7 @@ effect to your index in a row. - + EXAMPLES @@ -235,12 +233,12 @@ effect to your index in a row. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-rm.xml b/doc/source/en/TortoiseGit/git_doc/git-rm.xml index d9dd9fd2a..44ec8773c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-rm.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-rm.xml @@ -1,24 +1,22 @@ - + -
- + git-rm(1) git-rm(1) - - + NAME git-rm - Remove files from the working tree and from the index - + SYNOPSIS
git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…
- + DESCRIPTION Remove files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. @@ -31,7 +29,7 @@ When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index. - + OPTIONS @@ -140,7 +138,7 @@ allowing the file to be removed from just the index. - + DISCUSSION The <file> list given to the command can be exact pathnames, file glob patterns, or leading directory names. The command @@ -151,13 +149,13 @@ two directories d and d2, there is a d using git rm 'd*' and git rm 'd/*', as the former will also remove all of directory d2. - + REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM There is no option for git rm to remove from the index only the paths that have disappeared from the filesystem. However, depending on the use case, there are several ways that can be done. -
+
Using git commit -a If you intend that your next commit should record all modifications of tracked files in the working tree and record all removals of @@ -166,7 +164,7 @@ files that have been removed from the working tree with rm automatically notice and record all removals. You can also have a similar effect without committing by using git add -u.
-
+
Using git add -A When accepting a new code drop for a vendor branch, you probably want to record both the removal of paths and additions of new paths @@ -181,7 +179,7 @@ modifications in the working tree is: git add -A See .
-
+
Other ways If all you really want to do is to remove from the index the files that are no longer present in the working tree (perhaps because @@ -189,8 +187,22 @@ your working tree is dirty so that you cannot use git commit -a git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
+
+Submodules +Only submodules using a gitfile (which means they were cloned +with a git version 1.7.8 or newer) will be removed from the work +tree, as their repository lives inside the .git directory of the +superproject. If a submodule (or one of those nested inside it) +still uses a .git directory, git rm will fail - no matter if forced +or not - to protect the submodule's history. +A submodule is considered up-to-date when the HEAD is the same as +recorded in the index, no tracked files are modified and no untracked +files that aren't ignored are present in the submodules work tree. +Ignored files are deemed expendable and won't stop a submodule's work +tree from being removed. +
- + EXAMPLES @@ -221,12 +233,12 @@ of files and subdirectories under the Documentation/ direct - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-send-email.xml b/doc/source/en/TortoiseGit/git_doc/git-send-email.xml index 369bd5907..b786326f0 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-send-email.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-send-email.xml @@ -1,24 +1,22 @@ - + -
- + git-send-email(1) git-send-email(1) - - + NAME git-send-email - Send a collection of patches as emails - + SYNOPSIS
git send-email [options] <file|directory|rev-list options>…
- + DESCRIPTION Takes the patches given on the command line and emails them out. Patches can be specified as files, directories (which will send all @@ -47,9 +45,9 @@ and the "Subject:" of the message as the second line. - + OPTIONS -
+
Composing @@ -187,9 +185,20 @@ is not set, this will be prompted for. Note that no attempts whatsoever are made to validate the encoding. + + +--compose-encoding=<encoding> + + + + Specify encoding of compose message. Default is the value of the + sendemail.composeencoding; if that is unspecified, UTF-8 is assumed. + + +
-
+
Sending @@ -335,7 +344,7 @@ must be used for each option.
-
+
Automating @@ -500,7 +509,7 @@ recipient's MUA.
-
+
Administering @@ -612,7 +621,7 @@ default to --validate.
- + CONFIGURATION @@ -664,9 +673,9 @@ sendemail.confirm - + EXAMPLE -
+
Use gmail as the smtp server To use git send-email to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings: @@ -684,12 +693,12 @@ $ git send-email outgoing/* Net::SMTP::SSL, MIME::Base64 and Authen::SASL
- + SEE ALSO , , mbox(5) - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-send-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-send-pack.xml index 19c6c5f7b..3ba672a85 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-send-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-send-pack.xml @@ -1,31 +1,29 @@ - + -
- + git-send-pack(1) git-send-pack(1) - - + NAME git-send-pack - Push objects over git protocol to another repository - + SYNOPSIS
git send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>…]
- + DESCRIPTION Usually you would want to use git push, which is a higher-level wrapper of this command, instead. See . Invokes git-receive-pack on a possibly remote repository, and updates it from the current repository, sending named refs. - + OPTIONS @@ -141,7 +139,7 @@ updates it from the current repository, sending named refs. - + Specifying the Refs There are three ways to specify which refs to update on the remote end. @@ -203,8 +201,8 @@ remote ref and lose other peoples' commits from there. Optionally, a <ref> parameter can be prefixed with a plus + sign to disable the fast-forward check only on that ref. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-sh-i18n--envsubst.xml b/doc/source/en/TortoiseGit/git_doc/git-sh-i18n--envsubst.xml index d465fb781..7ee1b16c4 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-sh-i18n--envsubst.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-sh-i18n--envsubst.xml @@ -1,18 +1,16 @@ - + -
- + git-sh-i18n--envsubst(1) git-sh-i18n--envsubst(1) - - + NAME git-sh-i18n--envsubst - Git's own envsubst(1) for i18n fallbacks - + SYNOPSIS
eval_gettext () { @@ -23,7 +21,7 @@ }
- + DESCRIPTION This is not a command the end user would want to run. Ever. This documentation is meant for people who are studying the @@ -36,8 +34,8 @@ passed to the eval_gettext function. program won't disappear without warning in the next version of Git. Don't use it. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-sh-i18n.xml b/doc/source/en/TortoiseGit/git_doc/git-sh-i18n.xml index e42858bc8..e4ef18507 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-sh-i18n.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-sh-i18n.xml @@ -1,24 +1,22 @@ - + -
- + git-sh-i18n(1) git-sh-i18n(1) - - + NAME git-sh-i18n - Git's i18n setup code for shell scripts - + SYNOPSIS
. "$(git --exec-path)/git-sh-i18n"
- + DESCRIPTION This is not a command the end user would want to run. Ever. This documentation is meant for people who are studying the @@ -30,7 +28,7 @@ script. It provides wrappers for the GNU gettext and script, and provides pass-through fallbacks on systems without GNU gettext. - + FUNCTIONS @@ -60,8 +58,8 @@ eval_gettext - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-sh-setup.xml b/doc/source/en/TortoiseGit/git_doc/git-sh-setup.xml index b9ff2eb2e..2499e768c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-sh-setup.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-sh-setup.xml @@ -1,24 +1,22 @@ - + -
- + git-sh-setup(1) git-sh-setup(1) - - + NAME git-sh-setup - Common git shell script setup code - + SYNOPSIS
. "$(git --exec-path)/git-sh-setup"
- + DESCRIPTION This is not a command the end user would want to run. Ever. This documentation is meant for people who are studying the @@ -34,7 +32,7 @@ if the script can run from a subdirectory of the working tree The scriptlet sets GIT_DIR and GIT_OBJECT_DIRECTORY shell variables, but does not export them to the environment. - + FUNCTIONS @@ -155,8 +153,8 @@ get_author_ident_from_commit - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-shell.xml b/doc/source/en/TortoiseGit/git_doc/git-shell.xml index f516cb788..be0a254d6 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-shell.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-shell.xml @@ -1,24 +1,22 @@ - + -
- + git-shell(1) git-shell(1) - - + NAME git-shell - Restricted login shell for Git-only SSH access - + SYNOPSIS
git shell [-c <command> <argument>]
- + DESCRIPTION A login shell for SSH accounts to provide restricted Git access. When -c is given, the program executes <command> non-interactively; @@ -33,8 +31,8 @@ read and execute permissions to the directory in order to execute the programs in it. The programs are executed with a cwd of $HOME, and <argument> is parsed as a command-line string. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-shortlog.xml b/doc/source/en/TortoiseGit/git_doc/git-shortlog.xml index 8a43ba1b0..eb3dcc1ef 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-shortlog.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-shortlog.xml @@ -1,36 +1,33 @@ - + -
- + git-shortlog(1) git-shortlog(1) - - + NAME git-shortlog - Summarize git log output - + SYNOPSIS
git log --pretty=short | git shortlog [-h] [-n] [-s] [-e] [-w] git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] <commit>…
- + DESCRIPTION Summarizes git log output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +in release announcements. Each commit will be grouped by author and title. Additionally, "[PATCH]" will be stripped from the commit description. If no revisions are passed on the command line and either standard input is not a terminal or there is no current branch, git shortlog will output a summary of the log read from standard input, without reference to the current repository. - + OPTIONS @@ -115,7 +112,7 @@ reference to the current repository. - + MAPPING AUTHORS The .mailmap feature is used to coalesce together commits by the same person in the shortlog, where their name and/or email address was @@ -149,7 +146,7 @@ prefers her family name fully spelled out. A proper .mailmap Jane Doe <jane@desktop.(none)> Joe R. Developer <joe@example.com> -Note how there is no need for an entry for <jane@laptop.(none)>, because the +Note how there is no need for an entry for <jane@laptop.(none)>, because the real name of that author is already correct. Example 2: Your repository contains commits from the following authors: @@ -168,8 +165,8 @@ Santa Claus <santa.claus@northpole.xx> <me@company.xx> Use hash # for comments that are either on their own line, or after the email address. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-show-branch.xml b/doc/source/en/TortoiseGit/git_doc/git-show-branch.xml index bde96e9b5..2ed259593 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-show-branch.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-show-branch.xml @@ -1,18 +1,16 @@ - + -
- + git-show-branch(1) git-show-branch(1) - - + NAME git-show-branch - Show branches and their commits - + SYNOPSIS
git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] @@ -23,7 +21,7 @@ git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
- + DESCRIPTION Shows the commit ancestry graph starting from the commits named with <rev>s or <globs>s (or all refs under refs/heads @@ -32,7 +30,7 @@ and/or refs/tags) semi-visually. It uses showbranch.default multi-valued configuration items if no <rev> nor <glob> is given on the command line. - + OPTIONS @@ -267,7 +265,7 @@ no <rev> nor <glob> is given on the command line. Note that --more, --list, --independent and --merge-base options are mutually exclusive. - + OUTPUT Given N <references>, the first N lines are the one-line description from their commit message. The branch head that is @@ -303,7 +301,7 @@ The "fixes" branch adds one commit "Introduce "reset type" flag to "git reset"". The "mhf" branch adds many other commits. The current branch is "master". - + EXAMPLE If you keep your primary branches immediately under refs/heads, and topic branches in subdirectories of @@ -319,8 +317,8 @@ your topic branch, it is shown as well. Without --list, the output also shows how these tips are topologically related with each other. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-show-index.xml b/doc/source/en/TortoiseGit/git_doc/git-show-index.xml index 5014aa0ff..04cbb8c6c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-show-index.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-show-index.xml @@ -1,24 +1,22 @@ - + -
- + git-show-index(1) git-show-index(1) - - + NAME git-show-index - Show packed archive index - + SYNOPSIS
git show-index < idx-file
- + DESCRIPTION Reads given idx file for packed git archive created with git pack-objects command, and dumps its contents. @@ -26,8 +24,8 @@ git verify-pack -v; this command only shows the packfile offset and SHA1 of each object. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-show-ref.xml b/doc/source/en/TortoiseGit/git_doc/git-show-ref.xml index fdc791c0b..46dc8331b 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-show-ref.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-show-ref.xml @@ -1,18 +1,16 @@ - + -
- + git-show-ref(1) git-show-ref(1) - - + NAME git-show-ref - List references in a local repository - + SYNOPSIS
git show-ref [-q|--quiet] [--verify] [--head] [-d|--dereference] @@ -21,7 +19,7 @@ git show-ref --exclude-existing[=<pattern>] < ref-list
- + DESCRIPTION Displays references available in a local repository along with the associated commit IDs. Results can be filtered using a pattern and tags can be @@ -32,7 +30,7 @@ refs from stdin that don't exist in the local repository. Use of this utility is encouraged in favor of directly accessing files under the .git directory. - + OPTIONS @@ -158,7 +156,7 @@ the .git directory. - + OUTPUT The output is in the format: <SHA-1 ID> <space> <reference name>. $ git show-ref --head --dereference @@ -177,7 +175,7 @@ the .git directory. 03adf42c988195b50e1a1935ba5fcbc39b2b029b ... - + EXAMPLE To show all references called "master", whether tags or heads or anything else, and regardless of how deep in the reference naming hierarchy they are, @@ -205,18 +203,18 @@ flag, so you can do git show-ref --tags --dereference to get a listing of all tags together with what they dereference. - + FILES .git/refs/*, .git/packed-refs - + SEE ALSO , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-show.xml b/doc/source/en/TortoiseGit/git_doc/git-show.xml index 3074a0b24..b1865fa57 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-show.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-show.xml @@ -1,24 +1,22 @@ - + -
- + git-show(1) git-show(1) - - + NAME git-show - Show various types of objects - + SYNOPSIS
git show [options] <object>…
- + DESCRIPTION Shows one or more objects (blobs, trees, tags and commits). For commits it shows the log message and textual diff. It also @@ -32,7 +30,7 @@ with --name-only). control how the changes the commit introduces are shown. This manual page describes only the most frequently used options. - + OPTIONS @@ -170,9 +168,20 @@ being displayed. Examples: "--notes=foo" will show only notes from + + +--show-signature + + + + Check the validity of a signed commit object by passing the signature + to gpg --verify and show the output. + + + - + PRETTY FORMATS If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is @@ -429,6 +438,21 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +%GG: raw verification message from GPG for a signed commit + + + + +%G?: show either "G" for Good or "B" for Bad for a signed commit + + + + +%GS: show the name of the signer for a signed commit + + + + %gD: reflog selector, e.g., refs/stash@{1} @@ -559,7 +583,7 @@ $ git log -2 --pretty=%h 4da45bef - + EXAMPLES @@ -619,7 +643,7 @@ $ git log -2 --pretty=%h 4da45bef - + Discussion At the core level, git is character encoding agnostic. @@ -688,8 +712,8 @@ message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-stage.xml b/doc/source/en/TortoiseGit/git_doc/git-stage.xml index 517734db1..74a8d4a1a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-stage.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-stage.xml @@ -1,30 +1,28 @@ - + -
- + git-stage(1) git-stage(1) - - + NAME git-stage - Add file contents to the staging area - + SYNOPSIS
git stage args…
- + DESCRIPTION This is a synonym for . Please refer to the documentation of that command. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-stash.xml b/doc/source/en/TortoiseGit/git_doc/git-stash.xml index 1f9a2f03e..a7ebbc7a3 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-stash.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-stash.xml @@ -1,18 +1,16 @@ - + -
- + git-stash(1) git-stash(1) - - + NAME git-stash - Stash the changes in a dirty working directory away - + SYNOPSIS
git stash list [<options>] @@ -26,7 +24,7 @@ git stash create
- + DESCRIPTION Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean @@ -45,7 +43,7 @@ the usual reflog syntax (e.g. stash@{0} is the most recentl created stash, stash@{1} is the one before it, stash@{2.hours.ago} is also possible). - + OPTIONS @@ -184,7 +182,7 @@ drop [-q|--quiet] [<stash>] Remove a single stashed state from the stash list. When no <stash> is given, it removes the latest one. i.e. stash@{0}, otherwise - <stash> must a valid stash log reference of the form + <stash> must be a valid stash log reference of the form stash@{<revision>}. @@ -202,7 +200,7 @@ create - + DISCUSSION A stash is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at HEAD when @@ -216,7 +214,7 @@ the HEAD commit. The ancestry graph looks like this:W is a commit that records the state of the working tree. - + EXAMPLES @@ -310,15 +308,15 @@ xargs git log --merges --no-walk --grep=WIP - + SEE ALSO , , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-status.xml b/doc/source/en/TortoiseGit/git_doc/git-status.xml index 70af6bdbf..d62ffac78 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-status.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-status.xml @@ -1,24 +1,22 @@ - + -
- + git-status(1) git-status(1) - - + NAME git-status - Show the working tree status - + SYNOPSIS
git status [<options>…] [--] [<pathspec>…]
- + DESCRIPTION Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working @@ -28,7 +26,7 @@ are what you would commit by running git commitcould commit by running git add before running git commit. - + OPTIONS @@ -72,6 +70,16 @@ third are what you could commit by running git ad +--long + + + + Give the output in the long-format. This is the default. + + + + + -u[<mode>] @@ -149,9 +157,25 @@ configuration variable documented in . + + +--column[=<options>] + + +--no-column + + + + Display untracked files in columns. See configuration variable + column.status for option syntax.--column and --no-column + without options are equivalent to always and never + respectively. + + + - + OUTPUT The output from this command is designed to be used as a commit template comment, and all the output lines are prefixed with #. @@ -162,7 +186,7 @@ at any time. made relative to the current directory if you are working in a subdirectory (this is on purpose, to help cutting and pasting). See the status.relativePaths config option below. -
+
Short Format In the short-format, the status of each path is shown as XY PATH1 -> PATH2 @@ -245,7 +269,7 @@ U U unmerged, both modified If -b is used the short-format status is preceded by a line ## branchname tracking info
-
+
Porcelain Format The porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between git versions or @@ -277,7 +301,7 @@ characters are not specially formatted; no quoting or backslash-escaping is performed.
- + CONFIGURATION The command honors color.status (or status.color -- they mean the same thing and the latter is kept for backward @@ -291,12 +315,12 @@ to -1 or an unlimited number), the submodule summary will be enabled for the long format and a summary of commits for modified submodules will be shown (see --summary-limit option of ). - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-stripspace.xml b/doc/source/en/TortoiseGit/git_doc/git-stripspace.xml index 3fb2a7d44..acccd17c6 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-stripspace.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-stripspace.xml @@ -1,24 +1,22 @@ - + -
- + git-stripspace(1) git-stripspace(1) - - + NAME git-stripspace - Remove unnecessary whitespace - + SYNOPSIS
git stripspace [-s | --strip-comments] < input
- + DESCRIPTION Clean the input in the manner used by git for text such as commit messages, notes, tags and branch descriptions. @@ -51,7 +49,7 @@ output will be produced. mode of for correcting whitespace of patches or files in the repository. - + OPTIONS @@ -69,7 +67,7 @@ the repository. - + EXAMPLES Given the following noisy input with $ indicating the end of a line: |A brief introduction $ @@ -101,8 +99,8 @@ the repository. |$ |The end.$ - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-submodule.xml b/doc/source/en/TortoiseGit/git_doc/git-submodule.xml index f7aac4531..19053eaa9 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-submodule.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-submodule.xml @@ -1,21 +1,19 @@ - + -
- + git-submodule(1) git-submodule(1) - - + NAME git-submodule - Initialize, update or inspect submodules - + SYNOPSIS
-git submodule [--quiet] add [-b branch] [-f|--force] +git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>] git submodule [--quiet] status [--cached] [--recursive] [--] [<path>…] git submodule [--quiet] init [--] [<path>…] @@ -27,7 +25,7 @@ git submodule [--quiet] sync [--] [<path>…]
- + DESCRIPTION Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed @@ -65,7 +63,7 @@ using the status subcommand and get a detailed overview of difference between the index and checkouts using the summary subcommand. - + COMMANDS @@ -123,7 +121,6 @@ status initialized, + if the currently checked out submodule commit does not match the SHA-1 found in the index of the containing repository and U if the submodule has merge conflicts. - This command is the default command for git submodule. If --recursive is specified, this command will recurse into nested submodules, and show their status as well. @@ -163,7 +160,7 @@ update checkout the commit specified in the index of the containing repository. This will make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to - rebase, merge or none. none can be overriden by specifying + rebase, merge or none. none can be overridden by specifying --checkout. If the submodule is not yet initialized, and you just want to use the @@ -171,6 +168,10 @@ setting as stored in .gitmodules, you can automatically initialize the submodule with the --init option. If --recursive is specified, this command will recurse into the registered submodules, and update any nested submodules within. +If --force is specified, the submodule will be checked out (using +git checkout --force if appropriate), even if the commit specified in the +index of the containing repository already matches the commit checked out in +the submodule. @@ -238,7 +239,7 @@ sync - + OPTIONS @@ -279,7 +280,9 @@ sync This option is only valid for add and update commands. When running add, allow adding an otherwise ignored submodule path. When running update, throw away local changes in submodules when - switching to a different commit. + switching to a different commit; and always run a checkout operation + in the submodule, even if the commit listed in the index of the + containing repository matches the commit checked out in the submodule. @@ -385,6 +388,18 @@ sync +--name + + + + This option is only valid for the add command. It sets the submodule's + name to the given string instead of defaulting to its path. The name + must be valid as a directory name and may not end with a /. + + + + + --reference <repository> @@ -424,7 +439,7 @@ for 's --reference and - + FILES When initializing submodules, a .gitmodules file in the top-level directory of the containing repository is used to find the url of each submodule. @@ -432,8 +447,8 @@ This file should be formatted in the same way as $GIT_DIR/config for details. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-svn.xml b/doc/source/en/TortoiseGit/git_doc/git-svn.xml index 774531192..003491a61 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-svn.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-svn.xml @@ -1,24 +1,22 @@ - + -
- + git-svn(1) git-svn(1) - - + NAME git-svn - Bidirectional operation between a Subversion repository and git - + SYNOPSIS
git svn <command> [options] [arguments]
- + DESCRIPTION git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git @@ -31,7 +29,7 @@ It can also follow branches and tags in any layout with the -T/-t/-b options repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command. - + COMMANDS @@ -282,6 +280,20 @@ Skip "branches" and "tags" of first level directories + + +--log-window-size=<n> + + + + Fetch <n> log entries per request when scanning Subversion history. + The default is 100. For very large Subversion repositories, larger + values may be needed for clone/fetch to complete in reasonable + time. But overly large values may lead to higher memory usage and + request timeouts. + + + @@ -371,19 +383,15 @@ and have no uncommitted changes. - Commit each diff from a specified head directly to the SVN + Commit each diff from the current branch directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This will create a revision in SVN for each commit in git. - It is recommended that you run git svn fetch and rebase (not - pull or merge) your commits against the latest changes in the - SVN repository. - An optional revision or branch argument may be specified, and - causes git svn to do all work on that revision/branch - instead of HEAD. - This is advantageous over set-tree (below) because it produces - cleaner, more linear history. +When an optional git branch name (or a git commit object name) +is specified as an argument, the subcommand works on the specified +branch, not on the current branch. +Use of dcommit is preferred to set-tree (below). @@ -900,7 +908,7 @@ future dcommit! - + OPTIONS @@ -1093,6 +1101,12 @@ config key: svn.repackflags --strategy=<strategy> + +-p + + +--preserve-merges + These are only used with the dcommit and rebase commands. @@ -1150,7 +1164,7 @@ creating the branch or tag. - + ADVANCED OPTIONS @@ -1190,10 +1204,19 @@ creating the branch or tag. + This option is only relevant if we are tracking branches (using + one of the repository layout options --trunk, --tags, + --branches, --stdlayout). For each tracked branch, try to find + out where its revision was copied from, and set + a suitable parent in the first git commit for the branch. This is especially helpful when we're tracking a directory - that has been moved around within the repository, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + that has been moved around within the repository. If this + feature is disabled, the branches created by git svn will all + be linear and not share any history, meaning that there will be + no information on where branches were branched off or merged. + However, following long/convoluted histories can take a long + time, so disabling this feature may speed up the cloning + process. This feature is enabled by default, use --no-follow-parent to disable it.
@@ -1203,7 +1226,7 @@ creating the branch or tag. - + CONFIG FILE-ONLY OPTIONS @@ -1365,9 +1388,10 @@ and these settings should never be changed once they are set. section because they affect the git-svn-id: metadata line, except for rewriteRoot and rewriteUUID which can be used together. - + BASIC EXAMPLES -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): # Clone a repo (like git clone): git svn clone http://svn.example.com/project/trunk # Enter the newly cloned directory: @@ -1386,8 +1410,10 @@ for rewriteRoot and rewriteUUID which can be used together. git svn show-ignore >> .git/info/exclude Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN @@ -1422,20 +1448,22 @@ have each person clone that repository with git clone: - + REBASE VS. PULL/MERGE -Originally, git svn recommended that the remotes/git-svn branch be -pulled or merged from. This is because the author favored +Prefer to use git svn rebase or git rebase, rather than +git pull or git merge to synchronize unintegrated commits with a git svn +branch. Doing so will keep the history of unintegrated commits linear with +respect to the upstream SVN repository and allow the use of the preferred +git svn dcommit subcommand to push unintegrated commits back into SVN. +Originally, git svn recommended that developers pulled or merged from +the git svn branch. This was because the author favored git svn set-tree B to commit a single head rather than the -git svn set-tree A..B notation to commit multiple commits. -If you use git svn set-tree A..B to commit several diffs and you do -not have the latest remotes/git-svn merged into my-branch, you should -use git svn rebase to update your work branch instead of git pull or -git merge. pull/merge can cause non-linear history to be flattened -when committing into SVN, which can lead to merge commits reversing -previous commits in SVN. +git svn set-tree A..B notation to commit multiple commits. Use of +git pull or git merge with git svn set-tree A..B will cause non-linear +history to be flattened when committing into SVN and this can lead to merge +commits unexpectedly reversing previous commits in SVN. - + MERGE TRACKING While git svn can track copy history (including branches and tags) for repositories adopting a @@ -1444,7 +1472,49 @@ inside git back upstream to SVN users. Therefore it is advised that users keep history as linear as possible inside git to ease compatibility with SVN (see the CAVEATS section below). - + +HANDLING OF SVN BRANCHES +If git svn is configured to fetch branches (and --follow-branches +is in effect), it sometimes creates multiple git branches for one +SVN branch, where the addtional branches have names of the form +branchname@nnn (with nnn an SVN revision number). These additional +branches are created if git svn cannot find a parent commit for the +first commit in an SVN branch, to connect the branch to the history of +the other branches. +Normally, the first commit in an SVN branch consists +of a copy operation. git svn will read this commit to get the SVN +revision the branch was created from. It will then try to find the +git commit that corresponds to this SVN revision, and use that as the +parent of the branch. However, it is possible that there is no suitable +git commit to serve as parent. This will happen, among other reasons, +if the SVN branch is a copy of a revision that was not fetched by git +svn (e.g. because it is an old revision that was skipped with +--revision), or if in SVN a directory was copied that is not tracked +by git svn (such as a branch that is not tracked at all, or a +subdirectory of a tracked branch). In these cases, git svn will still +create a git branch, but instead of using an existing git commit as the +parent of the branch, it will read the SVN history of the directory the +branch was copied from and create appropriate git commits. This is +indicated by the message "Initializing parent: <branchname>". +Additionally, it will create a special branch named +<branchname>@<SVN-Revision>, where <SVN-Revision> is the SVN revision +number the branch was copied from. This branch will point to the newly +created parent commit of the branch. If in SVN the branch was deleted +and later recreated from a different version, there will be multiple +such branches with an @. +Note that this may mean that multiple git commits are created for a +single SVN revision. +An example: in an SVN repository with a standard +trunk/tags/branches layout, a directory trunk/sub is created in r.100. +In r.200, trunk/sub is branched by copying it to branches/. git svn +clone -s will then create a branch sub. It will also create new git +commits for r.100 through r.199 and use these as the history of branch +sub. Thus there will be two git commits for each revision from r.100 +to r.199 (one containing trunk/, one containing trunk/sub/). Finally, +it will create a branch sub@200 pointing to the new parent commit of +branch sub (i.e. the commit for r.200 and trunk/sub/). + + CAVEATS For the sake of simplicity and interoperating with Subversion, it is recommended that all git svn users clone, fetch and dcommit @@ -1476,6 +1546,20 @@ see the documentation for details. already dcommitted. It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. +When cloning an SVN repository, if none of the options for describing +the repository layout is used (--trunk, --tags, --branches, +--stdlayout), git svn clone will create a git repository with +completely linear history, where branches and tags appear as separate +directories in the working copy. While this is the easiest way to get a +copy of a complete repository, for projects with many branches it will +lead to a working copy many times larger than just the trunk. Thus for +projects using the standard directory structure (trunk/branches/tags), +it is recommended to clone with option --stdlayout. If the project +uses a non-standard structure, and/or if branches and tags are not +required, it is easiest to only clone one directory (typically trunk), +without giving any repository layout options. If the full history with +branches and tags is required, the options --trunk / --branches / +--tags must be used. When using multiple --branches or --tags, git svn does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, @@ -1485,7 +1569,7 @@ different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* - + BUGS We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.log @@ -1495,8 +1579,13 @@ this as it's quite difficult and time-consuming to get working for all the possible corner cases (git doesn't do it, either). Committing renamed and copied files is fully supported if they're similar enough for git to detect them. +In SVN, it is possible (though discouraged) to commit changes to a tag +(because a tag is just a directory copy, thus technically the same as a +branch). When cloning an SVN repository, git svn cannot know if such a +commit to a tag will happen in the future. Thus it acts conservatively +and imports all SVN tags as branches, prefixing the tag name with tags/. - + CONFIGURATION git svn stores [svn-remote] configuration information in the repository .git/config file. It is similar the core git @@ -1528,12 +1617,12 @@ or tag has appeared. If the subset of branches or tags is changed after fetching, then .git/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-symbolic-ref.xml b/doc/source/en/TortoiseGit/git_doc/git-symbolic-ref.xml index 096eca267..1758336cd 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-symbolic-ref.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-symbolic-ref.xml @@ -1,25 +1,24 @@ - + -
- + git-symbolic-ref(1) git-symbolic-ref(1) - - + NAME -git-symbolic-ref - Read and modify symbolic refs +git-symbolic-ref - Read, modify and delete symbolic refs - + SYNOPSIS
git symbolic-ref [-m <reason>] <name> <ref> -git symbolic-ref [-q] [--short] <name> +git symbolic-ref [-q] [--short] <name> +git symbolic-ref --delete [-q] <name>
- + DESCRIPTION Given one argument, reads which branch head the given symbolic ref refers to and outputs its path, relative to the .git/ @@ -27,15 +26,30 @@ directory. Typically you would give HEAD as the <name&g argument to see which branch your working tree is on. Given two arguments, creates or updates a symbolic ref <name> to point at the given branch <ref>. +Given --delete and an additional argument, deletes the given +symbolic ref. 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 +-d + + +--delete + + + + Delete the symbolic ref <name>. + + + + + -q @@ -73,7 +87,7 @@ a regular file whose contents is ref: refs/heads/master. - + NOTES In the past, .git/HEAD was a symbolic link pointing at refs/heads/master. When we wanted to switch to another branch, @@ -86,8 +100,8 @@ default. symbolic ref were printed correctly, with status 1 if the requested name is not a symbolic ref, or 128 if another error occurs. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-tag.xml b/doc/source/en/TortoiseGit/git_doc/git-tag.xml index c84d390a8..c1deeae8f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-tag.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-tag.xml @@ -1,34 +1,32 @@ - + -
- + git-tag(1) git-tag(1) - - + NAME git-tag - Create, list, delete or verify a tag object signed with GPG - + SYNOPSIS
git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <tagname> [<commit> | <object>] git tag -d <tagname>… git tag [-n[<num>]] -l [--contains <commit>] [--points-at <object>] + [--column[=<options>] | --no-column] [<pattern>…] [<pattern>…] git tag -v <tagname>…
- + DESCRIPTION -Add a tag reference in .git/refs/tags/, unless -d/-l/-v is given +Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags. -Unless -f is given, the tag to be created must not yet exist in the -.git/refs/tags/ directory. +Unless -f is given, the named tag must not yet exist. If one of -a, -s, or -u <key-id> is passed, the command creates a tag object, and requires a tag message. Unless -m <msg> or -F <file> is given, an editor is started for the user to type @@ -43,7 +41,7 @@ committer identity for the current user is used to find the GnuPG key for signing. The configuration variable gpg.program is used to specify custom GnuPG binary. - + OPTIONS @@ -157,6 +155,22 @@ is used to specify custom GnuPG binary. +--column[=<options>] + + +--no-column + + + + Display tag listing in columns. See configuration variable + column.tag for option syntax.--column and --no-column + without options are equivalent to always and never respectively. + +This option is only applicable when listing tags without annotation lines. + + + + --contains <commit> @@ -237,18 +251,18 @@ is used to specify custom GnuPG binary. - + 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 +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? @@ -309,7 +323,7 @@ Sorry for the inconvenience. way that it would be correct to just "fix" it automatically. 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 remote-tracking branches (refs/heads/origin in traditional @@ -358,7 +372,7 @@ they are most likely tracking each other's progress by having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
-
+
On Backdating Tags If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able @@ -372,7 +386,7 @@ values; the most common form is "YYYY-MM-DD HH:MM"). $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
- + DATE FORMATS The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats: @@ -417,12 +431,12 @@ ISO 8601 - + SEE ALSO . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-tar-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-tar-tree.xml index 42397ac58..96269ac78 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-tar-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-tar-tree.xml @@ -1,24 +1,22 @@ - + -
- + git-tar-tree(1) git-tar-tree(1) - - + NAME git-tar-tree - Create a tar archive of the files in the named tree object - + SYNOPSIS
git tar-tree [--remote=<repo>] <tree-ish> [ <base> ]
- + DESCRIPTION THIS COMMAND IS DEPRECATED. Use git archive with --format=tar option instead (and move the <base> argument to --prefix=base/). @@ -32,7 +30,7 @@ commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header. It can be extracted using git get-tar-commit-id. - + OPTIONS @@ -69,7 +67,7 @@ It can be extracted using git get-tar-commit-id. - + CONFIGURATION @@ -88,7 +86,7 @@ tar.umask - + EXAMPLES @@ -147,8 +145,8 @@ tar.umask - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-unpack-file.xml b/doc/source/en/TortoiseGit/git_doc/git-unpack-file.xml index bb9953f9c..3426becae 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-unpack-file.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-unpack-file.xml @@ -1,30 +1,28 @@ - + -
- + git-unpack-file(1) git-unpack-file(1) - - + NAME git-unpack-file - Creates a temporary file with a blob's contents - + SYNOPSIS
git unpack-file <blob>
- + DESCRIPTION Creates a file holding the contents of the blob specified by sha1. It returns the name of the temporary file in the following format: .merge_file_XXXXX - + OPTIONS @@ -39,8 +37,8 @@ returns the name of the temporary file in the following format: - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-unpack-objects.xml b/doc/source/en/TortoiseGit/git_doc/git-unpack-objects.xml index 37e58409a..742a7a81f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-unpack-objects.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-unpack-objects.xml @@ -1,24 +1,22 @@ - + -
- + git-unpack-objects(1) git-unpack-objects(1) - - + NAME git-unpack-objects - Unpack objects from a packed archive - + SYNOPSIS
git unpack-objects [-n] [-q] [-r] [--strict] <pack-file
- + DESCRIPTION Read a packed archive (.pack) from the standard input, expanding the objects contained within and writing them into the repository in @@ -29,7 +27,7 @@ this command on a pack-file that exists within the target repository. See for options to generate new packs and replace existing ones. - + OPTIONS @@ -79,8 +77,8 @@ new packs and replace existing ones. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-update-index.xml b/doc/source/en/TortoiseGit/git_doc/git-update-index.xml index 08086e7c8..db27faf9e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-update-index.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-update-index.xml @@ -1,18 +1,16 @@ - + -
- + git-update-index(1) git-update-index(1) - - + NAME git-update-index - Register file contents in the working tree to the index - + SYNOPSIS
git update-index @@ -25,12 +23,12 @@ [--ignore-submodules] [--really-refresh] [--unresolve] [--again | -g] [--info-only] [--index-info] - [-z] [--stdin] + [-z] [--stdin] [--index-version <n>] [--verbose] [--] [<file>…]
- + DESCRIPTION Modifies the index or directory cache. Each file mentioned is updated into the index and any unmerged or needs updating state is @@ -40,7 +38,7 @@ the most common operations on the index. The way git update-index handles files it is told about can be modified using the various options: - + OPTIONS @@ -296,6 +294,17 @@ you will need to handle the situation manually. +--index-version <n> + + + + Write the resulting index out in the named on-disk format version. + The current default version is 2. + + + + + -z @@ -331,7 +340,7 @@ you will need to handle the situation manually. - + Using --refresh --refresh does not calculate a new sha1 file or bring the index up-to-date for mode/content changes. But what it does do is to @@ -341,7 +350,7 @@ the stat entry is out of date. For example, you'd want to do this after doing a git read-tree, to link up the stat index details with the proper files. - + Using --cacheinfo or --info-only --cacheinfo is used to register a file that is not in the current working directory. This is useful for minimum-checkout @@ -356,7 +365,7 @@ in the database but the file isn't available locally. --info-only - + Using --index-info --index-info is a more powerful mechanism that lets you feed multiple entry definitions from the standard input, and designed @@ -405,7 +414,7 @@ for that path. After the above, we would end up with this: 100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz - + Using assume unchanged bit Many operations in git depend on your filesystem to have an efficient lstat(2) implementation, so that st_mtime @@ -434,7 +443,7 @@ unchanged". Note that "assume unchanged" bit is notgit update-index --really-refresh if you want to mark them as "assume unchanged"). - + Examples To update and refresh only the files already checked out: $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh @@ -444,61 +453,61 @@ to mark them as "assume unchanged"). On an inefficient filesystem with core.ignorestat set -$ git update-index --really-refresh -$ git update-index --no-assume-unchanged foo.c -$ git diff --name-only +$ git update-index --really-refresh +$ git update-index --no-assume-unchanged foo.c +$ git diff --name-only $ edit foo.c -$ git diff --name-only +$ git diff --name-only M foo.c -$ git update-index foo.c -$ git diff --name-only +$ git update-index foo.c +$ git diff --name-only $ edit foo.c -$ git diff --name-only -$ git update-index --no-assume-unchanged foo.c -$ git diff --name-only +$ git diff --name-only +$ git update-index --no-assume-unchanged foo.c +$ git diff --name-only M foo.c - + forces lstat(2) to set "assume unchanged" bits for paths that match index. - + mark the path to be edited. - + this does lstat(2) and finds index matches the path. - + this does lstat(2) and finds index does not match the path. - + registering the new version to index sets "assume unchanged" bit. - + and it is assumed unchanged. - + even after you edit it. - + you can tell about the change after the fact. - + now it checks with lstat(2) and finds it has been changed. @@ -508,7 +517,7 @@ now it checks with lstat(2) and finds it has been changed. - + Skip-worktree bit Skip-worktree bit can be defined in one (long) sentence: When reading an entry, if it is marked as skip-worktree, then Git pretends its @@ -525,7 +534,7 @@ working directory version matches index version) different from assume-unchanged bit's. Skip-worktree also takes precedence over assume-unchanged bit when both are set. - + Configuration The command honors core.filemode configuration variable. If your repository is on a filesystem whose executable bits are @@ -545,14 +554,14 @@ It can be useful when the inode change time is regularly modified by something outside Git (file system crawlers and backup systems use ctime for marking files processed) (see ). - + SEE ALSO , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-update-ref.xml b/doc/source/en/TortoiseGit/git_doc/git-update-ref.xml index 5bcf01ba6..174d37a7a 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-update-ref.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-update-ref.xml @@ -1,24 +1,22 @@ - + -
- + git-update-ref(1) git-update-ref(1) - - + NAME git-update-ref - Update the object name stored in a ref safely - + SYNOPSIS
git update-ref [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
- + DESCRIPTION Given two arguments, stores the <newvalue> in the <ref>, possibly dereferencing the symbolic refs. E.g. git update-ref HEAD @@ -56,7 +54,7 @@ archive by creating a symlink tree). With -d flag, it deletes the named <ref> after verifying it still contains <oldvalue>. - + Logging Updates If config parameter "core.logAllRefUpdates" is true and the ref is one under "refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or @@ -89,8 +87,8 @@ value supplied to the -m option. unable to create a new log file, append to the existing log file or does not have committer information available. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-update-server-info.xml b/doc/source/en/TortoiseGit/git_doc/git-update-server-info.xml index b809065d2..effbcb20f 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-update-server-info.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-update-server-info.xml @@ -1,24 +1,22 @@ - + -
- + git-update-server-info(1) git-update-server-info(1) - - + NAME git-update-server-info - Update auxiliary info file to help dumb servers - + SYNOPSIS
git update-server-info [--force]
- + DESCRIPTION A dumb server that does not do on-the-fly pack generations must have some auxiliary information files in $GIT_DIR/info and @@ -26,7 +24,7 @@ $GIT_OBJECT_DIRECTORY/info directories to help clients discover what references and packs the server has. This command generates such auxiliary files. - + OPTIONS @@ -44,7 +42,7 @@ generates such auxiliary files. - + OUTPUT Currently the command updates the following files. Please see for description of @@ -62,8 +60,8 @@ info/refs - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-upload-archive.xml b/doc/source/en/TortoiseGit/git_doc/git-upload-archive.xml index fc311bab7..ffa09cac1 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-upload-archive.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-upload-archive.xml @@ -1,24 +1,22 @@ - + -
- + git-upload-archive(1) git-upload-archive(1) - - + NAME git-upload-archive - Send archive back to git-archive - + SYNOPSIS
git upload-archive <directory>
- + DESCRIPTION Invoked by git archive --remote and sends a generated archive to the other end over the git protocol. @@ -26,7 +24,7 @@ other end over the git protocol. for the protocol is on the git archive side, and the program pair is meant to be used to get an archive from a remote repository. - + OPTIONS @@ -41,8 +39,8 @@ is meant to be used to get an archive from a remote repository. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-upload-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-upload-pack.xml index 713d51d81..b5cc7925c 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-upload-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-upload-pack.xml @@ -1,24 +1,22 @@ - + -
- + git-upload-pack(1) git-upload-pack(1) - - + NAME git-upload-pack - Send objects packed back to git-fetch-pack - + SYNOPSIS
git-upload-pack [--strict] [--timeout=<n>] <directory>
- + DESCRIPTION Invoked by git fetch-pack, learns what objects the other side is missing, and sends them after packing. @@ -27,7 +25,7 @@ The UI for the protocol is on the git fetch-pack side, and program pair is meant to be used to pull updates from a remote repository. For push operations, see git send-pack. - + OPTIONS @@ -62,12 +60,12 @@ repository. For push operations, see git send-pack. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-var.xml b/doc/source/en/TortoiseGit/git_doc/git-var.xml index 962281d96..db38dcc5e 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-var.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-var.xml @@ -1,28 +1,26 @@ - + -
- + git-var(1) git-var(1) - - + NAME git-var - Show a git logical variable - + SYNOPSIS
git var ( -l | <variable> )
- + DESCRIPTION Prints a git logical variable. - + OPTIONS @@ -40,12 +38,12 @@ - + EXAMPLE $ git var GIT_AUTHOR_IDENT Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600 - + VARIABLES @@ -79,7 +77,8 @@ GIT_EDITOR $SOME_ENVIRONMENT_VARIABLE, "C:\Program Files\Vim\gvim.exe" --nofork. The order of preference is the $GIT_EDITOR environment variable, then core.editor configuration, then - $VISUAL, then $EDITOR, and then finally vi. + $VISUAL, then $EDITOR, and then the default chosen at compile + time, which is usually vi. @@ -92,55 +91,21 @@ GIT_PAGER Text viewer for use by git commands (e.g., less). The value is meant to be interpreted by the shell. The order of preference is the $GIT_PAGER environment variable, then core.pager - configuration, then $PAGER, and then finally less. + configuration, then $PAGER, and then the default chosen at + compile time (usually less). - -Diagnostics - - - -You don't exist. Go away! - - - - The passwd(5) gecos field couldn't be read - - - - - -Your parents must have hated you! - - - - The passwd(5) gecos field is longer than a giant static buffer. - - - - - -Your sysadmin must hate you! - - - - The passwd(5) name field is longer than a giant static buffer. - - - - - - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-verify-pack.xml b/doc/source/en/TortoiseGit/git_doc/git-verify-pack.xml index ba1c0a8da..947a10a21 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-verify-pack.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-verify-pack.xml @@ -1,30 +1,28 @@ - + -
- + git-verify-pack(1) git-verify-pack(1) - - + NAME git-verify-pack - Validate packed git archive files - + SYNOPSIS
git verify-pack [-v|--verbose] [-s|--stat-only] [--] <pack>.idx …
- + DESCRIPTION Reads given idx file for packed git archive created with the git pack-objects command and verifies idx file and the corresponding pack file. - + OPTIONS @@ -77,7 +75,7 @@ corresponding pack file. - + OUTPUT FORMAT When specifying the -v option the format used is: SHA1 type size size-in-pack-file offset-in-packfile @@ -85,8 +83,8 @@ corresponding pack file. SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1 for objects that are deltified. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-verify-tag.xml b/doc/source/en/TortoiseGit/git_doc/git-verify-tag.xml index 91e5a739a..866f51c66 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-verify-tag.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-verify-tag.xml @@ -1,28 +1,26 @@ - + -
- + git-verify-tag(1) git-verify-tag(1) - - + NAME git-verify-tag - Check the GPG signature of tags - + SYNOPSIS
git verify-tag <tag>…
- + DESCRIPTION Validates the gpg signature created by git tag. - + OPTIONS @@ -50,8 +48,8 @@ - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-web--browse.xml b/doc/source/en/TortoiseGit/git_doc/git-web--browse.xml index 88a5bbae3..42c150de7 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-web--browse.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-web--browse.xml @@ -1,24 +1,22 @@ - + -
- + git-web--browse(1) git-web--browse(1) - - + NAME git-web--browse - git helper script to launch a web browser - + SYNOPSIS
git web--browse [OPTIONS] URL/FILE …
- + DESCRIPTION This script tries, as much as possible, to display the URLs and FILEs that are passed as arguments, as HTML pages in new tabs on an already @@ -103,7 +101,7 @@ start (this is the default under MinGW) Custom commands may also be specified. - + OPTIONS @@ -149,15 +147,15 @@ start (this is the default under MinGW) - + CONFIGURATION VARIABLES -
+
CONF.VAR (from -c option) and web.browser The web browser can be specified using a configuration variable passed with the -c (or --config) command line option, or the web.browser configuration variable if the former is not used.
-
+
browser.<tool>.path You can explicitly provide a full path to your preferred browser by setting the configuration variable browser.<tool>.path. For example, @@ -165,7 +163,7 @@ you can configure the absolute path to firefox by setting browser.firefox.path. Otherwise, git web--browse assumes the tool is available in PATH.
-
+
browser.<tool>.cmd When the browser, specified by options or configuration variables, is not among the supported ones, then the corresponding @@ -175,7 +173,7 @@ as a custom command and will use a shell eval to run the command with the URLs passed as arguments.
- + Note about konqueror When konqueror is specified by a command line option or a configuration variable, we launch kfmclient to try to open the HTML @@ -190,7 +188,7 @@ the following: [browser "konq"] cmd = A_PATH_TO/konqueror -
+
Note about git-config --global Note that these configuration variables should probably be set using the --global flag, for example like this: @@ -199,8 +197,8 @@ the --global flag, for example like this: See for more information about this.
- + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-whatchanged.xml b/doc/source/en/TortoiseGit/git_doc/git-whatchanged.xml index 0b1059abc..33f028dce 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-whatchanged.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-whatchanged.xml @@ -1,24 +1,22 @@ - + -
- + git-whatchanged(1) git-whatchanged(1) - - + NAME git-whatchanged - Show logs with difference each commit introduces - + SYNOPSIS
git whatchanged <option>…
- + DESCRIPTION Shows commit logs and diff output each commit introduces. The command internally invokes git rev-list piped to @@ -26,7 +24,7 @@ command internally invokes git rev-list piped to these commands. This manual page describes only the most frequently used options. - + OPTIONS @@ -210,9 +208,20 @@ being displayed. Examples: "--notes=foo" will show only notes from + + +--show-signature + + + + Check the validity of a signed commit object by passing the signature + to gpg --verify and show the output. + + + - + PRETTY FORMATS If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is @@ -469,6 +478,21 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +%GG: raw verification message from GPG for a signed commit + + + + +%G?: show either "G" for Good or "B" for Bad for a signed commit + + + + +%GS: show the name of the signer for a signed commit + + + + %gD: reflog selector, e.g., refs/stash@{1} @@ -599,7 +623,7 @@ $ git log -2 --pretty=%h 4da45bef - + Examples @@ -627,8 +651,8 @@ $ git log -2 --pretty=%h 4da45bef - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git-write-tree.xml b/doc/source/en/TortoiseGit/git_doc/git-write-tree.xml index 327ebcb87..a5de2d746 100644 --- a/doc/source/en/TortoiseGit/git_doc/git-write-tree.xml +++ b/doc/source/en/TortoiseGit/git_doc/git-write-tree.xml @@ -1,24 +1,22 @@ - + -
- + git-write-tree(1) git-write-tree(1) - - + NAME git-write-tree - Create a tree object from the current index - + SYNOPSIS
git write-tree [--missing-ok] [--prefix=<prefix>/]
- + DESCRIPTION Creates a tree object using the current index. The name of the new tree object is printed to standard output. @@ -29,7 +27,7 @@ In order to have that match what is actually in your directory right now, you need to have done a git update-index phase before you did the git write-tree. - + OPTIONS @@ -58,8 +56,8 @@ now, you need to have done a git update-index phase before - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/git.xml b/doc/source/en/TortoiseGit/git_doc/git.xml index 25e0fb293..ac265f658 100644 --- a/doc/source/en/TortoiseGit/git_doc/git.xml +++ b/doc/source/en/TortoiseGit/git_doc/git.xml @@ -1,18 +1,16 @@ - + -
- + git(1) git(1) - - + NAME git - the stupid content tracker - + SYNOPSIS
git [--version] [--help] [-c <name>=<value>] @@ -22,24 +20,23 @@ <command> [<args>]
- + DESCRIPTION Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. See 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 . See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. -The <command> is either a name of a Git command (see below) or an alias -as defined in the configuration file (see ). -Formatted and hyperlinked version of the latest git -documentation can be viewed at -http://www.kernel.org/pub/software/scm/git/docs/. +link:everyday.html[Everyday Git] for a useful minimum set of +commands. The link:user-manual.html[Git User's Manual] has a more +in-depth introduction. +After you mastered the basic concepts, you can come back to this +page to learn what commands git offers. You can learn more about +individual git commands with "git help command". +manual page gives you an overview of the command line command syntax. +Formatted and hyperlinked version of the latest git documentation +can be viewed at http://git-htmldocs.googlecode.com/git/git.html. - + OPTIONS @@ -218,29 +215,16 @@ help .... - -FURTHER DOCUMENTATION -See the references above to get started using git. The following is -probably more detail than necessary for a first-time user. -The git concepts chapter of the -user-manual and both provide -introductions to the underlying git architecture. -See for an overview of recommended workflows. -See also the link:howto-index.html[howto] documents for some useful -examples. -The internals are documented in the -link:technical/api-index.html[GIT API documentation]. - - + GIT COMMANDS We divide git into high level ("porcelain") commands and low level ("plumbing") commands. - + High-level commands (porcelain) We separate the porcelain commands into the main commands and some ancillary user utilities. -
+
Main porcelain commands @@ -615,7 +599,7 @@ ancillary user utilities.
-
+
Ancillary Commands Manipulators: @@ -924,7 +908,7 @@ ancillary user utilities.
-
+
Interacting with Others These commands are to interact with foreign SCM and with other people via patch over e-mail. @@ -981,6 +965,16 @@ people via patch over e-mail. + + + + + Import from and submit to Perforce repositories. + + + + + @@ -1022,7 +1016,7 @@ people via patch over e-mail.
- + Low-level commands (plumbing) Although git includes its own porcelain layer, its low-level commands are sufficient to support @@ -1040,7 +1034,7 @@ 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 @@ -1169,7 +1163,7 @@ repositories. - Read and modify symbolic refs. + Read, modify and delete symbolic refs. @@ -1215,7 +1209,7 @@ repositories.
-
+
Interrogation commands @@ -1402,7 +1396,7 @@ repositories. In general, the interrogate commands do not touch the files in the working tree.
-
+
Synching repositories @@ -1531,7 +1525,7 @@ typically do not use them directly.
-
+
Internal helper commands These are internal helper commands used by other commands; end users typically do not use them directly. @@ -1558,6 +1552,46 @@ users typically do not use them directly. + + + + + Display data in columns. + + + + + + + + + + Retrieve and store user credentials. + + + + + + + + + + Helper to temporarily store passwords in memory. + + + + + + + + + + Helper to store credentials on disk. + + + + + @@ -1618,6 +1652,16 @@ users typically do not use them directly. + + + + + Git's i18n setup code for shell scripts. + + + + + @@ -1639,7 +1683,7 @@ users typically do not use them directly.
- + Configuration Mechanism Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file is used to hold per-repository configuration options. It is a @@ -1662,7 +1706,7 @@ people. Here is an example: their operation accordingly. See for a list. - + Identifier Terminology @@ -1755,7 +1799,7 @@ list. - + Symbolic Identifiers Any git command accepting any <object> can also use the following symbolic notation: @@ -1796,21 +1840,21 @@ HEAD For a more complete list of ways to spell object names, see "SPECIFYING REVISIONS" section in . - + File/Directory Structure Please see the document. Read for more details about each hook. Higher level SCMs may provide and manage additional information in the $GIT_DIR. - + Terminology Please see . - + Environment Variables Various git commands use the following environment variables: -
+
The git Repository These environment variables apply to all core git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above @@ -1864,6 +1908,7 @@ git so take care if using Cogito etc. If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository. + The --git-dir command-line option also sets this value. @@ -1926,7 +1971,7 @@ git so take care if using Cogito etc.
-
+
git Commits @@ -1959,7 +2004,7 @@ git so take care if using Cogito etc.
-
+
git Diffs @@ -2030,7 +2075,7 @@ parameter, <path>.
-
+
other @@ -2065,7 +2110,7 @@ parameter, <path>. This environment variable overrides $EDITOR and $VISUAL. - It is used by several git comands when, on interactive mode, + It is used by several git commands when, on interactive mode, an editor is to be launched. See also and the core.editor option in . @@ -2147,8 +2192,8 @@ for further details.
- -Discussion<anchor id="Discussion" xreflabel="[Discussion]"/> + +Discussion<anchor id="git(1)_Discussion" xreflabel="[Discussion]"/> More detail on the following is available from the git concepts chapter of the user-manual and . @@ -2191,22 +2236,39 @@ content stored in the index. for a given pathname. These stages are used to hold the various unmerged version of a file when a merge is in progress. - + +FURTHER DOCUMENTATION +See the references in the "description" section to get started +using git. The following is probably more detail than necessary +for a first-time user. +The git concepts chapter of the +user-manual and both provide +introductions to the underlying git architecture. +See for an overview of recommended workflows. +See also the link:howto-index.html[howto] documents for some useful +examples. +The internals are documented in the +link:technical/api-index.html[GIT API documentation]. +Users migrating from CVS may also want to +read . + + Authors Git was started by Linus Torvalds, and is currently maintained by Junio C Hamano. Numerous contributions have come from the git mailing list -<git@vger.kernel.org>. For a more complete list of contributors, see -http://git-scm.com/about. If you have a clone of git.git itself, the +<git@vger.kernel.org>. http://www.ohloh.net/p/git/contributors/summary +gives you a more complete list of contributors. +If you have a clone of git.git itself, the output of and can show you the authors for specific parts of the project. - + Reporting Bugs Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there. - + SEE ALSO , , link:everyday.html[Everyday Git], , @@ -2214,8 +2276,8 @@ link:everyday.html[Everyday Git], , , link:user-manual.html[The Git User's Manual], - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitattributes.xml b/doc/source/en/TortoiseGit/git_doc/gitattributes.xml index 6fd4a80c1..a6678a7f7 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitattributes.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitattributes.xml @@ -1,22 +1,20 @@ - + -
- + gitattributes(5) gitattributes(5) - - + NAME gitattributes - defining attributes per path - + SYNOPSIS $GIT_DIR/info/attributes, .gitattributes - + DESCRIPTION A gitattributes file is a simple text file that gives attributes to pathnames. @@ -81,7 +79,8 @@ Unspecified When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute. The rules how the pattern matches paths are the -same as in .gitignore files; see . +same as in .gitignore files; see . +Unlike .gitignore, negative patterns are forbidden. When deciding what attributes are assigned to a path, git consults $GIT_DIR/info/attributes file (which has the highest precedence), .gitattributes file in the same directory as the @@ -90,6 +89,10 @@ work tree (the further the directory that contains .gitattributes +When the .gitattributes file is missing from the work tree, the +path in the index is used as a fall-back. During checkout process, +.gitattributes in the index is used and then the file in the +working tree is used as a fall-back. If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user's workflow for that repository), then @@ -99,25 +102,27 @@ repositories (i.e., attributes of interest to all users) should go into .gitattributes files. Attributes that should affect all repositories for a single user should be placed in a file specified by the core.attributesfile configuration option (see ). +Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME +is either not set or empty, $HOME/.config/git/attributes is used instead. Attributes for all users on a system should be placed in the $(prefix)/etc/gitattributes file. Sometimes you would need to override an setting of an attribute for a path to Unspecified state. This can be done by listing the name of the attribute prefixed with an exclamation point !. - + EFFECTS Certain operations by git can be influenced by assigning particular attributes to a path. Currently, the following operations are attributes-aware. -
+
Checking-out and checking-in These attributes affect how the contents stored in the repository are copied to the working tree files when commands such as git checkout and git merge run. They also affect how git stores the contents you prepare in the working tree in the repository upon git add and git commit. -
+
<emphasis>text</emphasis> This attribute enables and controls end-of-line normalization. When a text file is normalized, its line endings are converted to LF in the @@ -176,7 +181,7 @@ Unspecified Any other value causes git to act as if text has been left unspecified.
-
+
<emphasis>eol</emphasis> This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any @@ -208,7 +213,7 @@ Set to string value "lf"
-
+
Backwards compatibility with <emphasis>crlf</emphasis> attribute For backwards compatibility, the crlf attribute is interpreted as follows: @@ -216,7 +221,7 @@ follows: -crlf -text crlf=input eol=lf
-
+
End-of-line conversion While git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to @@ -301,7 +306,7 @@ few exceptions. Even though…
-
+
<emphasis>ident</emphasis> When the attribute ident is set for a path, git replaces $Id$ in the blob object with $Id:, followed by the @@ -310,7 +315,7 @@ sign $ upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in.
-
+
<emphasis>filter</emphasis> A filter attribute can be set to a string value that names a filter driver specified in the configuration. @@ -372,7 +377,7 @@ substitution. For example: clean = git-p4-filter --clean %f smudge = git-p4-filter --smudge %f
-
+
Interaction between checkin/checkout attributes In the check-in codepath, the worktree file is first converted with filter driver (if specified and corresponding driver @@ -382,7 +387,7 @@ and applicable). In the check-out codepath, the blob content is first converted with text, and then ident and fed to filter.
-
+
Merging branches with differing checkin/checkout attributes If you have added attributes to a file that cause the canonical repository format for that file to change, such as adding a @@ -402,9 +407,9 @@ not act in this way may cause additional merge conflicts that must be resolved manually.
-
+
Generating diff text -
+
<emphasis>diff</emphasis> The attribute diff affects how git generates diffs for particular files. It can tell git whether to generate a textual patch for the path @@ -466,7 +471,7 @@ String
-
+
Defining an external diff driver The definition of a diff driver is done in gitconfig, not gitattributes file, so strictly speaking this manual page is a @@ -481,7 +486,7 @@ with the above configuration, i.e. j-c-diff, with 7 parameters, just like GIT_EXTERNAL_DIFF program is called. See for details.
-
+
Defining a custom hunk-header Each group of changes (called a "hunk") in the textual diff output is prefixed with a line of the form: @@ -513,6 +518,11 @@ patterns are available: +ada suitable for source code in the Ada language. + + + + bibtex suitable for files with BibTeX coded references. @@ -583,7 +593,7 @@ patterns are available:
-
+
Customizing word diff You can customize the rules that git diff --word-diff uses to split words in a line, by specifying an appropriate regular expression @@ -597,7 +607,7 @@ whitespace. To separate them, use a regular expression in your A built-in pattern is provided for all languages listed in the previous section.
-
+
Performing text diffs of binary files Sometimes it is desirable to see the diff of a text-converted version of some binary files. For example, a word processor @@ -643,7 +653,7 @@ and now produces better output), you can remove the cache manually with git update-ref -d refs/notes/textconv/jpg (where "jpg" is the name of the diff driver, as in the example above).
-
+
Choosing textconv versus external diff If you want to show differences between binary or specially-formatted blobs in your repository, you can choose to use either an external diff @@ -681,7 +691,7 @@ Caching. Textconv caching can speed up repeated diffs, such as those
-
+
Marking files as binary Git usually guesses correctly whether a blob contains text or binary data by examining the beginning of the contents. However, sometimes you @@ -705,9 +715,9 @@ The solution is to use the diff.*.binary config option:
-
+
Performing a three-way merge -
+
<emphasis>merge</emphasis> The attribute merge affects how three versions of a file are merged when a file-level merge is necessary during git merge, @@ -768,7 +778,7 @@ String
-
+
Built-in merge drivers There are a few built-in low-level merge drivers defined that can be asked for via the merge attribute. @@ -817,7 +827,7 @@ union
-
+
Defining a custom merge driver The definition of a merge driver is done in the .git/config file, not in the gitattributes file, so strictly speaking this @@ -847,7 +857,7 @@ merge between common ancestors, when there are more than one. When left unspecified, the driver itself is used for both internal merge and the final merge.
-
+
<emphasis>conflict-marker-size</emphasis> This attribute controls the length of conflict markers left in the work tree file during a conflicted merge. Only setting to @@ -859,9 +869,9 @@ results in a conflict. Documentation/git-merge.txt conflict-marker-size=32
-
+
Checking whitespace errors -
+
<emphasis>whitespace</emphasis> The core.whitespace configuration variable allows you to define what diff and apply should consider whitespace errors for all paths in @@ -916,14 +926,14 @@ String
-
+
Creating an archive -
+
<emphasis>export-ignore</emphasis> Files and directories with the attribute export-ignore won't be added to archive files.
-
+
<emphasis>export-subst</emphasis> If the attribute export-subst is set for a file then git will expand several placeholders when adding this file to an archive. The @@ -936,17 +946,17 @@ in the file. E.g. the string $Format:%H$ will be replaced commit hash.
-
+
Packing objects -
+
<emphasis>delta</emphasis> Delta compression will not be attempted for blobs for paths with the attribute delta set to false.
-
+
Viewing files in GUI tools -
+
<emphasis>encoding</emphasis> The value of this attribute specifies the character encoding that should be used by GUI tools (e.g. and ) to @@ -959,7 +969,7 @@ manually enable per-file encodings in its options.
- + USING MACRO ATTRIBUTES You do not want any end-of-line conversions applied to, nor textual diffs produced for, any binary file you track. You would need to specify e.g. @@ -975,14 +985,14 @@ though setting one might have the effect of setting or unsetting other attributes or even returning other attributes to the "Unspecified" state. - + DEFINING MACRO ATTRIBUTES Custom macro attributes can be defined only in the .gitattributes file at the toplevel (i.e. not in any subdirectory). The built-in macro attribute "binary" is equivalent to: -[attr]binary -diff -text +[attr]binary -diff -merge -text - + EXAMPLE If you have these three gitattributes file: (in $GIT_DIR/info/attributes) @@ -1032,12 +1042,12 @@ baz set to false merge set to string value "filfre" frotz unspecified - + SEE ALSO . - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitcli.xml b/doc/source/en/TortoiseGit/git_doc/gitcli.xml index 25734e99f..8a6ee10c2 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitcli.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitcli.xml @@ -1,22 +1,20 @@ - + -
- + gitcli(7) gitcli(7) - - + NAME gitcli - git command line interface and conventions - + SYNOPSIS gitcli - + DESCRIPTION This manual describes the convention used throughout git CLI. Many commands take revisions (most often "commits", but sometimes @@ -50,11 +48,27 @@ Without disambiguating --, git makes a reasonable guess, bu you have to say either git diff HEAD -- or git diff -- HEAD to disambiguate. - - When writing a script that is expected to handle random user-input, it is a good practice to make it explicit which arguments are which by placing disambiguating -- at appropriate places. + + + +Many commands allow wildcards in paths, but you need to protect + them from getting globbed by the shell. These two mean different + things: + +$ git checkout -- *.c +$ git checkout -- \*.c +The former lets your shell expand the fileglob, and you are asking +the dot-C files in your working tree to be overwritten with the version +in the index. The latter passes the *.c to Git, and you are asking +the paths in the index that match the pattern to be checked out to your +working tree. After running git add hello.c; rm hello.c, you will not +see hello.c in your working tree with the former, but with the latter +you will. + + Here are the rules regarding the "flags" that you should follow when you are scripting git: @@ -87,14 +101,25 @@ when you give a revision parameter to a command, make sure the parameter is if you happen to have a file called HEAD in the work tree. + + +many commands allow a long option "--option" to be abbreviated + only to their unique prefix (e.g. if there is no other option + whose name begins with "opt", you may be able to spell "--opt" to + invoke the "--option" flag), but you should fully spell them out + when writing your scripts; later versions of Git may introduce a + new option whose name shares the same prefix, e.g. "--optimize", + to make a short prefix that used to be unique no longer unique. + + - + ENHANCED OPTION PARSER From the git 1.5.4 series and further, many git commands (not all of them at the time of the writing though) come with an enhanced option parser. -Here is an exhaustive list of the facilities provided by this option parser. -
+Here is a list of the facilities provided by this option parser. +
Magic Options Commands which have the enhanced option parser activated all understand a couple of magic command line options: @@ -132,20 +157,29 @@ usage: git describe [options] <committish>*
-
+
Negating options Options with long option names can be negated by prefixing --no-. For example, git branch has the option --track which is on by default. You can use --no-track to override that behaviour. The same goes for --color and --no-color.
-
+
Aggregating short options Commands that support the enhanced option parser allow you to aggregate short options. This means that you can for example use git rm -rf or git clean -fdx.
-
+
+Abbreviating long options +Commands that support the enhanced option parser accepts unique +prefix of a long option as if it is fully spelled out, but use this +with a caution. For example, git commit --amen behaves as if you +typed git commit --amend, but that is true only until a later version +of Git introduces another option that shares the same prefix, +e.g `git commit --amenity" option. +
+
Separating argument from the option You can write the mandatory option parameter to an option as a separate word on the command line. That means that all the following uses work: @@ -160,7 +194,7 @@ $ git describe --abbrev=10 HEAD # correct $ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT
- + NOTES ON FREQUENTLY CONFUSED OPTIONS Many commands that can work on files in the working tree and/or in the index can take --cached and/or --index @@ -201,8 +235,8 @@ entries. http://marc.info/?l=git&m=119150393620273 for further information. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitcore-tutorial.xml b/doc/source/en/TortoiseGit/git_doc/gitcore-tutorial.xml index 9df932c47..41ee8ab07 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitcore-tutorial.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitcore-tutorial.xml @@ -1,22 +1,20 @@ - + -
- + gitcore-tutorial(7) gitcore-tutorial(7) - - + NAME gitcore-tutorial - A git core tutorial for developers - + SYNOPSIS git * - + DESCRIPTION This tutorial explains how to use the "core" git commands to set up and work with a git repository. @@ -39,7 +37,7 @@ commands do is still valid. Deeper technical details are often marked as Notes, which you can skip on your first reading. - + Creating a git repository Creating a new git repository couldn't be easier: all git repositories start out empty, and the only thing you need to do is find yourself a @@ -113,7 +111,7 @@ after finishing this tutorial. You have now created your first git repository. Of course, since it's empty, that's not very useful, so let's start populating it with data. - + Populating a git repository We'll keep this simple and stupid, so we'll start off with populating a few trivial files just to get a feel for it. @@ -222,7 +220,7 @@ index 557db03..263414f 100644 Hello World +It's a new day for git - + Committing git state Now, we want to go to the next stage in git, which is to take the files that git knows about in the index, and commit them as a real tree. We do @@ -271,7 +269,7 @@ helpful script called git commit that will do all of this f you could have just written git commit instead, and it would have done the above magic scripting for you. - + Making a change Remember how we did the git update-index on file hello and then we changed hello afterward, and could compare the new state of hello with the @@ -360,7 +358,7 @@ it's a few very simple shell scripts to generate the helpful (?) commit message headers, and a few one-liners that actually do the commit itself (git commit). - + Inspecting Changes While creating changes is useful, it's even more useful if you can tell later what changed. The most useful command for this is another of the @@ -435,7 +433,7 @@ can explore on your own. git Plumbing commands, but using Porcelain such as git add, git-rm and git-commit. - + Tagging a version In git, there are two kinds of tags, a "light" one, and an "annotated tag". A "light" tag is technically nothing more than a branch, except we put @@ -466,7 +464,7 @@ want to do -- any time you decide that you want to remember a certain point, just create a private tag for it, and you have a nice symbolic name for the state at that point. - + Copying repositories git repositories are normally totally self-sufficient and relocatable. Unlike CVS, for example, there is no separate notion of @@ -563,7 +561,7 @@ $ git checkout You have now successfully copied somebody else's (mine) remote repository, and checked it out. - + Creating a new branch Branches in git are really nothing more than pointers into the git object database from within the .git/refs/ subdirectory, and as we @@ -608,7 +606,7 @@ You can then later -- once you decide that you want to actually develop on that branch -- switch to that branch with a regular git checkout with the branchname as the argument. - + Merging two branches One of the ideas of having a branch is that you do some (possibly experimental) work in it, and eventually merge it back to the main @@ -689,12 +687,11 @@ environment, is git show-branch. *+ [mybranch] Some work. * [master^] Some fun. The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their -top-of-the-tree commits, you are currently on master branch -(notice the asterisk * character), and the first column for -the later output lines is used to show commits contained in the +with the titles of their top-of-the-tree commits, you are currently on +master branch (notice the asterisk * character), and the first +column for the later output lines is used to show commits contained in the master branch, and the second column for the mybranch -branch. Three commits are shown along with their log messages. +branch. Three commits are shown along with their titles. All of them have non blank characters in the first column (* shows an ordinary commit on the current branch, - is a merge commit), which means they are now part of the master branch. Only the "Some @@ -724,8 +721,8 @@ $ git merge -m "Merge upstream changes." master would be different) Updating from ae3a2da... to a80b4aa.... Fast-forward (no commit created; -m option ignored) - example | 1 + - hello | 1 + + example | 1 + + hello | 1 + 2 files changed, 2 insertions(+) Because your branch did not contain anything more than what had already been merged into the master branch, the merge operation did @@ -740,7 +737,7 @@ looks like, or run show-branch, which tells you this. - + Merging external work It's usually much more common that you merge with somebody else than merging with your own branches, so it's worth pointing out that git @@ -894,7 +891,7 @@ like this: - + How does the merge work? We said this tutorial shows what plumbing does to help you cope with the porcelain that isn't flushing, but we so far did not @@ -998,7 +995,7 @@ merge for you to resolve. Notice that the path hello is st unmerged, and what you see with git diff at this point is differences since stage 2 (i.e. your version). - + Publishing your work 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 @@ -1063,7 +1060,7 @@ repository. Kernel.org mirror network takes care of the propagation to other publicly visible machines: $ git push master.kernel.org:/pub/scm/git/git.git/ - + Packing your repository Earlier, we saw that one file under .git/objects/??/ directory is stored for each git object you create. This representation @@ -1115,7 +1112,7 @@ While this allows you to use different packing strategies on both ends, it also means you may need to repack both repositories every once in a while. - + Working with Others Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy @@ -1285,7 +1282,7 @@ Use git format-patch origin to prepare patches for e-mail - + Working with Others, Shared Repository Style If you are coming from CVS background, the style of cooperation suggested in the previous section may be new to you. You do not @@ -1293,7 +1290,7 @@ have to worry. git supports "shared public repository" style of cooperation you are probably more familiar with as well. See for the details. - + Bundling your work together It is likely that you will be working on more than one thing at a time. It is easy to manage those more-or-less independent tasks @@ -1368,7 +1365,7 @@ and the reason why you preferred changes made in one side over the other. Otherwise it would make the project history harder to follow, not easier. - + SEE ALSO , , @@ -1377,8 +1374,8 @@ to follow, not easier. link:everyday.html[Everyday git], link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitcredentials.xml b/doc/source/en/TortoiseGit/git_doc/gitcredentials.xml index f23323ae8..077826af2 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitcredentials.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitcredentials.xml @@ -1,23 +1,21 @@ - + -
- + gitcredentials(7) gitcredentials(7) - - + NAME gitcredentials - providing usernames and passwords to git - + SYNOPSIS git config credential.https://example.com.username myusername git config credential.helper "$helper $options" - + DESCRIPTION Git will sometimes need credentials from the user in order to perform operations; for example, it may need to ask for a username and password @@ -25,7 +23,7 @@ in order to access a remote repository over HTTP. This manual describes the mechanisms git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly. - + REQUESTING CREDENTIALS Without any credential helpers defined, git will try the following strategies to ask the user for usernames and passwords: @@ -57,7 +55,7 @@ Otherwise, the user is prompted on the terminal. - + AVOIDING REPETITION It can be cumbersome to input the same credentials over and over. Git provides two methods to reduce this annoyance: @@ -138,7 +136,7 @@ variable, each helper will be tried in turn, and may provide a username, password, or nothing. Once git has acquired both a username and a password, no more helpers will be tried. - + CREDENTIAL CONTEXTS Git considers each credential to have a context defined by a URL. This context is used to look up context-specific configuration, and is passed to any @@ -159,7 +157,7 @@ compares hostnames exactly, without considering whether two hosts are part of the same domain. Likewise, a config entry for http://example.com would not match: git compares the protocols exactly. - + CONFIGURATION OPTIONS Options for a credential context can be configured either in credential.* (which applies to all credentials), or @@ -208,14 +206,14 @@ useHttpPath - + CUSTOM HELPERS You can write your own custom helpers to interface with any system in which you keep credentials. See the documentation for git's link:technical/api-credentials.html[credentials API] for details. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitcvs-migration.xml b/doc/source/en/TortoiseGit/git_doc/gitcvs-migration.xml index afcec5081..bb5abbfd1 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitcvs-migration.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitcvs-migration.xml @@ -1,24 +1,22 @@ - + -
- + gitcvs-migration(7) gitcvs-migration(7) - - + NAME gitcvs-migration - git for CVS users - + SYNOPSIS
git cvsimport *
- + DESCRIPTION Git differs from CVS in that every working tree contains a repository with a full copy of the project history, and no repository is inherently more @@ -29,7 +27,7 @@ this document explains how to do that. and should be sufficient. - + Developing against a shared repository Suppose a shared repository is set up in /pub/repo.git on the host foo.com. Then as an individual committer you can clone the shared @@ -63,7 +61,7 @@ $ git push foo.com:/pub/project.git/ as long as the shared repository does not have any branches other than master. - + Setting Up a Shared Repository We assume you have already created a git repository for your project, possibly created from scratch or from a tarball (see @@ -87,7 +85,7 @@ writable by that group: Make sure committers have a umask of at most 027, so that the directories they create are writable and searchable by other group members. - + Importing a CVS archive First, install version 2.1 or higher of cvsps from link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make @@ -114,7 +112,7 @@ of the imported directory, as described above. Then treat the imported directory as another development clone for purposes of merging incremental imports. - + Advanced Shared Repository Management Git allows you to specify scripts called "hooks" to be run at certain points. You can use these, for example, to send all commits to the shared @@ -123,13 +121,13 @@ repository to a mailing list. See . link:howto/update-hook-example.txt[Controlling access to branches using update hooks]. - + Providing CVS Access to a git Repository It is also possible to provide true CVS access to a git repository, so that developers can still use CVS; see for details. - + Alternative Development Models CVS users are accustomed to giving a group of developers commit access to a common repository. As we've seen, this is also possible with git. @@ -147,7 +145,7 @@ variants of this model. With a small group, developers may just pull changes from each other's repositories without the need for a central maintainer. - + SEE ALSO , , @@ -156,8 +154,8 @@ repositories without the need for a central maintainer. link:everyday.html[Everyday Git], link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitdiffcore.xml b/doc/source/en/TortoiseGit/git_doc/gitdiffcore.xml index 7c31b3c6f..da2e163dd 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitdiffcore.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitdiffcore.xml @@ -1,24 +1,22 @@ - + -
- + gitdiffcore(7) gitdiffcore(7) - - + NAME gitdiffcore - Tweaking diff output - + SYNOPSIS
git diff *
- + DESCRIPTION The diff commands git diff-index, git diff-files, and git diff-tree can be told to manipulate differences they find in @@ -27,7 +25,7 @@ is collectively called "diffcore transformation". This short note describes what they are and how to use them to produce diff output that is easier to understand than the conventional kind. - + The chain of operation The git diff-* family works by first comparing two sets of files: @@ -108,7 +106,7 @@ output routine and generates either diff-raw format (see Output format sections of the manual for git diff-* commands) or diff-patch format. - + diffcore-break: For Splitting Up "Complete Rewrites" The second transformation in the chain is diffcore-break, and is controlled by the -B option to the git diff-* commands. This is @@ -133,7 +131,7 @@ the result is used; if the edit lengthens the file, the size of the original is used), and can be customized by giving a number after "-B" option (e.g. "-B75" to tell it to use 75%). - + diffcore-rename: For Detection Renames and Copies This transformation is used to detect renames and copies, and is controlled by the -M option (to detect renames) and the -C option @@ -172,7 +170,7 @@ the expense of making it slower. Without --find-copies-hardergit diff-* commands can detect copies only if the file that was copied happened to have been modified in the same changeset. - + diffcore-merge-broken: For Putting "Complete Rewrites" Back Together This transformation is used to merge filepairs broken by diffcore-break, and not transformed into rename/copy by @@ -217,7 +215,7 @@ a complete rewrite by showing the entire contents of old version prefixed with -, followed by the entire contents of new version prefixed with +. - + diffcore-pickaxe: For Detecting Addition/Deletion of Specified String This transformation is used to find filepairs that represent changes that touch a specified string, and is controlled by the @@ -236,7 +234,7 @@ output empty otherwise. The latter behaviour is designed to make reviewing of the changes in the context of the whole changeset easier. - + diffcore-order: For Sorting the Output Based on Filenames This is used to reorder the filepairs according to the user's (or project's) taste, and is controlled by the -O option to the @@ -254,7 +252,7 @@ Documentation *.c t - + SEE ALSO , , @@ -265,8 +263,8 @@ t , link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitglossary.xml b/doc/source/en/TortoiseGit/git_doc/gitglossary.xml index 1c2ac2640..9df529941 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitglossary.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitglossary.xml @@ -1,44 +1,42 @@ - + -
- + gitglossary(7) gitglossary(7) - - + NAME gitglossary - A GIT Glossary - + SYNOPSIS * - + DESCRIPTION -alternate object database +alternate object database - Via the alternates mechanism, a repository - can inherit part of its object database + Via the alternates mechanism, a repository + can inherit part of its object database from another object database, which is called "alternate". -bare repository +bare repository A bare repository is normally an appropriately - named directory with a .git suffix that does not + named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the git administrative and control files that would normally be present in the @@ -51,61 +49,61 @@ -blob object +blob object - Untyped object, e.g. the contents of a file. + Untyped object, e.g. the contents of a file. -branch +branch A "branch" is an active line of development. The most recent - commit on a branch is referred to as the tip of + commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch - head, which moves forward as additional development + head, which moves forward as additional development is done on the branch. A single git - repository can track an arbitrary number of - branches, but your working tree is + repository can track an arbitrary number of + branches, but your working tree is associated with just one of them (the "current" or "checked out" - branch), and HEAD points to that branch. + branch), and HEAD points to that branch. -cache +cache - Obsolete for: index. + Obsolete for: index. -chain +chain - A list of objects, where each object in the list contains + A list of objects, where each object in the list contains a reference to its successor (for example, the successor of a - commit could be one of its parents). + commit could be one of its parents). -changeset +changeset - BitKeeper/cvsps speak for "commit". Since git does not + BitKeeper/cvsps speak for "commit". Since git does not store changes, but states, it really does not make sense to use the term "changesets" with git. @@ -113,49 +111,49 @@ -checkout +checkout The action of updating all or part of the - working tree with a tree object - or blob from the - object database, and updating the - index and HEAD if the whole working tree has - been pointed at a new branch. + working tree with a tree object + or blob from the + object database, and updating the + index and HEAD if the whole working tree has + been pointed at a new branch. -cherry-picking +cherry-picking - In SCM jargon, "cherry pick" means to choose a subset of + In SCM jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In GIT, this is performed by the "git cherry-pick" command to extract the change introduced - by an existing commit and to record it based on the tip - of the current branch as a new commit. + by an existing commit and to record it based on the tip + of the current branch as a new commit. -clean +clean - A working tree is clean, if it - corresponds to the revision referenced by the current - head. Also see "dirty". + A working tree is clean, if it + corresponds to the revision referenced by the current + head. Also see "dirty". -commit +commit @@ -164,31 +162,31 @@ set of interrelated commits. The word "commit" is often used by git in the same places other revision control systems use the words "revision" or "version". Also used as a short - hand for commit object. + hand for commit object. As a verb: The action of storing a new snapshot of the project's state in the git history, by creating a new commit representing the current -state of the index and advancing HEAD +state of the index and advancing HEAD to point at the new commit. -commit object +commit object - An object which contains the information about a - particular revision, such as parents, committer, - author, date and the tree object which corresponds - to the top directory of the stored + An object which contains the information about a + particular revision, such as parents, committer, + author, date and the tree object which corresponds + to the top directory of the stored revision. -core git +core git @@ -199,56 +197,56 @@ to point at the new commit. -DAG +DAG - Directed acyclic graph. The commit objects form a + Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents (directed), and the - graph of commit objects is acyclic (there is no chain - which begins and ends with the same object). + graph of commit objects is acyclic (there is no chain + which begins and ends with the same object). -dangling object +dangling object - An unreachable object which is not - reachable even from other unreachable objects; a + An unreachable object which is not + reachable even from other unreachable objects; a dangling object has no references to it from any - reference or object in the repository. + reference or object in the repository. -detached HEAD +detached HEAD - Normally the HEAD stores the name of a - branch. However, git also allows you to check out - an arbitrary commit that isn't necessarily the tip of any + Normally the HEAD stores the name of a + branch. However, git also allows you to check out + an arbitrary commit that isn't necessarily the tip of any particular branch. In this case HEAD is said to be "detached". -dircache +dircache - You are waaaaay behind. See index. + You are waaaaay behind. See index. -directory +directory @@ -258,73 +256,73 @@ to point at the new commit. -dirty +dirty - A working tree is said to be "dirty" if - it contains modifications which have not been committed to the current - branch. + A working tree is said to be "dirty" if + it contains modifications which have not been committed to the current + branch. -ent +ent - Favorite synonym to "tree-ish" by some total geeks. See - http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth + Favorite synonym to "tree-ish" by some total geeks. See + http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth explanation. Avoid this term, not to confuse people. -evil merge +evil merge - An evil merge is a merge that introduces changes that - do not appear in any parent. + An evil merge is a merge that introduces changes that + do not appear in any parent. -fast-forward +fast-forward - A fast-forward is a special type of merge where you have a - revision and you are "merging" another - branch's changes that happen to be a descendant of what - you have. In such these cases, you do not make a new merge - commit but instead just update to his + A fast-forward is a special type of merge where you have a + revision and you are "merging" another + branch's changes that happen to be a descendant of what + you have. In such these cases, you do not make a new merge + commit but instead just update to his revision. This will happen frequently on a - remote-tracking branch of a remote - repository. + remote-tracking branch of a remote + repository. -fetch +fetch - Fetching a branch means to get the - branch's head ref from a remote - repository, to find out which objects are - missing from the local object database, + Fetching a branch means to get the + branch's head ref from a remote + repository, to find out which objects are + missing from the local object database, and to get them, too. See also . -file system +file system @@ -336,23 +334,23 @@ to point at the new commit. -git archive +git archive - Synonym for repository (for arch people). + Synonym for repository (for arch people). -grafts +grafts Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way - you can make git pretend the set of parents a commit has + you can make git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file. @@ -360,22 +358,22 @@ to point at the new commit. -hash +hash - In git's context, synonym to object name. + In git's context, synonym to object name. -head +head - A named reference to the commit at the tip of a - branch. Heads are stored in a file in + A named reference to the commit at the tip of a + branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs. (See .) @@ -383,31 +381,31 @@ to point at the new commit. -HEAD +HEAD - The current branch. In more detail: Your working tree is normally derived from the state of the tree + The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the - heads in your repository, except when using a - detached HEAD, in which case it directly + heads in your repository, except when using a + detached HEAD, in which case it directly references an arbitrary commit. -head ref +head ref - A synonym for head. + A synonym for head. -hook +hook @@ -424,39 +422,39 @@ to point at the new commit. -index +index A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your - working tree. Truth be told, it can also contain a second, and even + working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used - when merging. + when merging. -index entry +index entry The information regarding a particular file, stored in the - index. An index entry can be unmerged, if a - merge was started, but not yet finished (i.e. if + index. An index entry can be unmerged, if a + merge was started, but not yet finished (i.e. if the index contains multiple versions of that file). -master +master - The default development branch. Whenever you - create a git repository, a branch named + The default development branch. Whenever you + create a git repository, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required. @@ -465,112 +463,112 @@ to point at the new commit. -merge +merge As a verb: To bring the contents of another - branch (possibly from an external - repository) into the current branch. In the + branch (possibly from an external + repository) into the current branch. In the case where the merged-in branch is from a different repository, - this is done by first fetching the remote branch + this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a - pull. Merging is performed by an automatic process + pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge. -As a noun: unless it is a fast-forward, a -successful merge results in the creation of a new commit +As a noun: unless it is a fast-forward, a +successful merge results in the creation of a new commit representing the result of the merge, and having as -parents the tips of the merged branches. +parents the tips of the merged branches. This commit is referred to as a "merge commit", or sometimes just a "merge". -object +object The unit of storage in git. It is uniquely identified by the - SHA1 of its contents. Consequently, an + SHA1 of its contents. Consequently, an object can not be changed. -object database +object database - Stores a set of "objects", and an individual object is - identified by its object name. The objects usually + Stores a set of "objects", and an individual object is + identified by its object name. The objects usually live in $GIT_DIR/objects/. -object identifier +object identifier - Synonym for object name. + Synonym for object name. -object name +object name - The unique identifier of an object. The hash + The unique identifier of an object. The hash of the object's contents using the Secure Hash Algorithm 1 and usually represented by the 40 character hexadecimal encoding of - the hash of the object. + the hash of the object. -object type +object type - One of the identifiers "commit", - "tree", "tag" or - "blob" describing the type of an - object. + One of the identifiers "commit", + "tree", "tag" or + "blob" describing the type of an + object. -octopus +octopus - To merge more than two branches. Also denotes an + To merge more than two branches. Also denotes an intelligent predator. -origin +origin - The default upstream repository. Most projects have + The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates - will be fetched into remote remote-tracking branches named + will be fetched into remote remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r. @@ -578,7 +576,7 @@ This commit is referred to as a "merge commit", or sometimes just a -pack +pack @@ -589,19 +587,19 @@ This commit is referred to as a "merge commit", or sometimes just a -pack index +pack index The list of identifiers, and other information, of the objects in a - pack, to assist in efficiently accessing the contents of a + pack, to assist in efficiently accessing the contents of a pack. -pathspec +pathspec @@ -675,11 +673,11 @@ should not be combined with other pathspec. -parent +parent - A commit object contains a (possibly empty) list + A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents. @@ -687,108 +685,108 @@ should not be combined with other pathspec. -pickaxe +pickaxe - The term pickaxe refers to an option to the diffcore + The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the --pickaxe-all option, it can be used to view the full - changeset that introduced or removed, say, a + changeset that introduced or removed, say, a particular line of text. See . -plumbing +plumbing - Cute name for core git. + Cute name for core git. -porcelain +porcelain Cute name for programs and program suites depending on - core git, presenting a high level access to - core git. Porcelains expose more of a SCM - interface than the plumbing. + core git, presenting a high level access to + core git. Porcelains expose more of a SCM + interface than the plumbing. -pull +pull - Pulling a branch means to fetch it and - merge it. See also . + Pulling a branch means to fetch it and + merge it. See also . -push +push - Pushing a branch means to get the branch's - head ref from a remote repository, + Pushing a branch means to get the branch's + head ref from a remote repository, find out if it is a direct ancestor to the branch's local head ref, and in that case, putting all - objects, which are reachable from the local + objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote - object database, and updating the remote - head ref. If the remote head is not an + object database, and updating the remote + head ref. If the remote head is not an ancestor to the local head, the push fails. -reachable +reachable - All of the ancestors of a given commit are said to be + All of the ancestors of a given commit are said to be "reachable" from that commit. More - generally, one object is reachable from - another if we can reach the one from the other by a chain - that follows tags to whatever they tag, - commits to their parents or trees, and - trees to the trees or blobs + generally, one object is reachable from + another if we can reach the one from the other by a chain + that follows tags to whatever they tag, + commits to their parents or trees, and + trees to the trees or blobs that they contain. -rebase +rebase - To reapply a series of changes from a branch to a - different base, and reset the head of that branch + To reapply a series of changes from a branch to a + different base, and reset the head of that branch to the result. -ref +ref - A 40-byte hex representation of a SHA1 or a name that - denotes a particular object. They may be stored in + A 40-byte hex representation of a SHA1 or a name that + denotes a particular object. They may be stored in a file under $GIT_DIR/refs/ directory, or in the $GIT_DIR/packed-refs file. @@ -796,7 +794,7 @@ should not be combined with other pathspec. -reflog +reflog @@ -809,17 +807,17 @@ should not be combined with other pathspec. -refspec +refspec - A "refspec" is used by fetch and - push to describe the mapping between remote - ref and local ref. They are combined with a colon in + A "refspec" is used by fetch and + push to describe the mapping between remote + ref and local ref. They are combined with a colon in the format <src>:<dst>, preceded by an optional plus sign, +. For example: git fetch $URL refs/heads/master:refs/heads/origin means "grab the master - branch head from the $URL and store + 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 branch at $URL". See also @@ -829,71 +827,71 @@ should not be combined with other pathspec. -remote-tracking branch +remote-tracking branch - A regular git branch that is used to follow changes from - another repository. A remote-tracking + A regular git branch that is used to follow changes from + another repository. A remote-tracking branch should not contain direct modifications or have local commits made to it. A remote-tracking branch can usually be - identified as the right-hand-side ref in a Pull: - refspec. + identified as the right-hand-side ref in a Pull: + refspec. -repository +repository - A collection of refs together with an - object database containing all objects - which are reachable from the refs, possibly - accompanied by meta data from one or more porcelains. A + A collection of refs together with an + object database containing all objects + which are reachable from the refs, possibly + accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories - via alternates mechanism. + via alternates mechanism. -resolve +resolve The action of fixing up manually what a failed automatic - merge left behind. + merge left behind. -revision +revision A particular state of files and directories which was stored in the - object database. It is referenced by a - commit object. + object database. It is referenced by a + commit object. -rewind +rewind To throw away part of the development, i.e. to assign the - head to an earlier revision. + head to an earlier revision. -SCM +SCM @@ -903,24 +901,24 @@ should not be combined with other pathspec. -SHA1 +SHA1 - Synonym for object name. + Synonym for object name. -shallow repository +shallow repository - A shallow repository has an incomplete - history some of whose commits have parents cauterized away (in other + 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 + 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 the --depth option to , and @@ -930,14 +928,14 @@ should not be combined with other pathspec. -symref +symref - Symbolic reference: instead of containing the SHA1 + Symbolic reference: instead of containing the SHA1 id itself, it is of the format ref: refs/some/thing and when referenced, it recursively dereferences to this reference. - HEAD is a prime example of a symref. Symbolic + HEAD is a prime example of a symref. Symbolic references are manipulated with the command. @@ -945,41 +943,41 @@ should not be combined with other pathspec. -tag +tag - A ref under refs/tags/ namespace that points to an + A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a - tag or a commit object). - In contrast to a head, a tag is not updated by + tag or a commit object). + In contrast to a head, a tag is not updated by the commit command. A git tag has nothing to do with a Lisp - tag (which would be called an object type + tag (which would be called an object type in git's context). A tag is most typically used to mark a particular - point in the commit ancestry chain. + point in the commit ancestry chain. -tag object +tag object - An object containing a ref pointing to + An object containing a ref pointing to another object, which can contain a message just like a - commit object. It can also contain a (PGP) + commit object. It can also contain a (PGP) signature, in which case it is called a "signed tag object". -topic branch +topic branch - A regular git branch that is used by a developer to + A regular git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet @@ -989,66 +987,66 @@ should not be combined with other pathspec. -tree +tree - Either a working tree, or a tree object together with the dependent blob and tree objects + Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree). -tree object +tree object - An object containing a list of file names and modes along + An object containing a list of file names and modes along with refs to the associated blob and/or tree objects. A - tree is equivalent to a directory. + tree is equivalent to a directory. -tree-ish +tree-ish - A ref pointing to either a commit object, a tree object, or a tag object pointing to a tag or commit or tree object. + A ref pointing to either a commit object, a tree object, or a tag object pointing to a tag or commit or tree object. -unmerged index +unmerged index - An index which contains unmerged - index entries. + An index which contains unmerged + index entries. -unreachable object +unreachable object - An object which is not reachable from a - branch, tag, or any other reference. + An object which is not reachable from a + branch, tag, or any other reference. -upstream branch +upstream branch - The default branch that is merged into the branch in + The default branch that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of A is origin/B sometimes we say "A is tracking origin/B". @@ -1057,19 +1055,19 @@ should not be combined with other pathspec. -working tree +working tree The tree of actual checked out files. The working tree normally - contains the contents of the HEAD commit's tree, + contains the contents of the HEAD commit's tree, plus any local changes that you have made but not yet committed. - + SEE ALSO , , @@ -1077,8 +1075,8 @@ should not be combined with other pathspec. link:everyday.html[Everyday git], link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/githooks.xml b/doc/source/en/TortoiseGit/git_doc/githooks.xml index 4a45a45c5..eceadfdc6 100644 --- a/doc/source/en/TortoiseGit/git_doc/githooks.xml +++ b/doc/source/en/TortoiseGit/git_doc/githooks.xml @@ -1,22 +1,20 @@ - + -
- + githooks(5) githooks(5) - - + NAME githooks - Hooks used by git - + SYNOPSIS $GIT_DIR/hooks/* - + DESCRIPTION Hooks are little scripts you can place in $GIT_DIR/hooks directory to trigger action at certain points. When @@ -29,9 +27,9 @@ However - in a freshly initialized repository - the .sample executable by default. This document describes the currently defined hooks. - + HOOKS -
+
applypatch-msg This hook is invoked by git am script. It takes a single parameter, the name of the file that holds the proposed commit @@ -44,7 +42,7 @@ the commit after inspecting the message file. The default applypatch-msg hook, when enabled, runs the commit-msg hook, if the latter is enabled.
-
+
pre-applypatch This hook is invoked by git am. It takes no parameter, and is invoked after the patch is applied, but before a commit is made. @@ -55,14 +53,14 @@ make a commit if it does not pass certain test. The default pre-applypatch hook, when enabled, runs the pre-commit hook, if the latter is enabled.
-
+
post-applypatch This hook is invoked by git am. It takes no parameter, and is invoked after the patch is applied and a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of git am.
-
+
pre-commit This hook is invoked by git commit, and can be bypassed with --no-verify option. It takes no parameter, and is @@ -76,7 +74,7 @@ such a line is found. variable GIT_EDITOR=: if the command will not bring up an editor to modify the commit message.
-
+
prepare-commit-msg This hook is invoked by git commit right after preparing the default log message, and before the editor is started. @@ -96,7 +94,7 @@ be used as replacement for pre-commit hook. The sample prepare-commit-msg hook that comes with git comments out the Conflicts: part of a merge's commit message.
-
+
commit-msg This hook is invoked by git commit, and can be bypassed with --no-verify option. It takes a single parameter, the @@ -110,19 +108,19 @@ the commit after inspecting the message file. The default commit-msg hook, when enabled, detects duplicate "Signed-off-by" lines, and aborts the commit if one is found.
-
+
post-commit This hook is invoked by git commit. It takes no parameter, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of git commit.
-
+
pre-rebase This hook is called by git rebase and can be used to prevent a branch from getting rebased.
-
+
post-checkout This hook is invoked when a git checkout is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, @@ -137,7 +135,7 @@ ref of the new HEAD and the flag is always 1. differences from the previous HEAD if different, or set working dir metadata properties.
-
+
post-merge This hook is invoked by git merge, which happens when a git pull is done on a local repository. The hook takes a single parameter, a status @@ -149,7 +147,7 @@ save and restore any form of metadata associated with the working tree (eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl for an example of how to do this.
-
+
pre-receive This hook is invoked by git-receive-pack on the remote repository, which happens when a git push is done on a local repository. @@ -166,12 +164,12 @@ input a line of the format: When creating a new ref, <old-value> is 40 0. If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can -still be prevented by the update hook. +still be prevented by the update hook. Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.
-
+
update This hook is invoked by git-receive-pack on the remote repository, which happens when a git push is done on a local repository. @@ -207,7 +205,7 @@ That is, to enforce a "fast-forward only" policy. It could also be used to log the old..new status. However, it does not know the entire set of branches, so it would end up firing one e-mail per ref when used naively, though. The -post-receive hook is more suited to that. +post-receive hook is more suited to that. Another use suggested on the mailing list is to use this hook to implement access control which is finer grained than the one based on filesystem group. @@ -218,7 +216,7 @@ for the user. hooks.allowunannotated config option unset or set to false--prevents unannotated tags to be pushed.
-
+
post-receive This hook is invoked by git-receive-pack on the remote repository, which happens when a git push is done on a local repository. @@ -226,11 +224,11 @@ It executes on the remote repository once after all the refs have been updated. This hook executes once for the receive operation. It takes no arguments, but gets the same information as the -pre-receive +pre-receive hook does on its standard input. This hook does not affect the outcome of git-receive-pack, as it is called after the real work is done. -This supersedes the post-update hook in that it gets +This supersedes the post-update hook in that it gets both old and new values of all the refs in addition to their names. Both standard output and standard error output are forwarded to @@ -241,7 +239,7 @@ a sample script post-receive-email provided in the
-
+
post-update This hook is invoked by git-receive-pack on the remote repository, which happens when a git push is done on a local repository. @@ -254,7 +252,7 @@ the outcome of git-receive-pack. The post-update hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, so it is a poor place to do log old..new. The -post-receive hook does get both original and +post-receive hook does get both original and updated values of the refs. You might consider it instead if you need them. When enabled, the default post-update hook runs @@ -266,13 +264,13 @@ probably enable this hook. git send-pack on the other end, so you can simply echo messages for the user.
-
+
pre-auto-gc This hook is invoked by git gc --auto. It takes no parameter, and exiting with non-zero status from this script causes the git gc --auto to abort.
-
+
post-rewrite This hook is invoked by commands that rewrite commits (git commit --amend, git-rebase; currently git-filter-branch does not call @@ -308,8 +306,8 @@ processed by rebase.
- + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitignore.xml b/doc/source/en/TortoiseGit/git_doc/gitignore.xml index 71fe8f7c5..48f393ed1 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitignore.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitignore.xml @@ -1,22 +1,20 @@ - + -
- + gitignore(5) gitignore(5) - - + NAME gitignore - Specifies intentionally untracked files to ignore - + SYNOPSIS $GIT_DIR/info/exclude, .gitignore - + DESCRIPTION A gitignore file specifies intentionally untracked files that git should ignore. @@ -59,16 +57,35 @@ Patterns read from the file specified by the configuration Which file to place a pattern in depends on how the pattern is meant to -be used. Patterns which should be version-controlled and distributed to -other repositories via clone (i.e., files that all developers will want -to ignore) should go into a .gitignore file. Patterns which are -specific to a particular repository but which do not need to be shared -with other related repositories (e.g., auxiliary files that live inside -the repository but are specific to one user's workflow) should go into -the $GIT_DIR/info/exclude file. Patterns which a user wants git to -ignore in all situations (e.g., backup or temporary files generated by -the user's editor of choice) generally go into a file specified by -core.excludesfile in the user's ~/.gitconfig. +be used. + + + +Patterns which should be version-controlled and distributed to + other repositories via clone (i.e., files that all developers will want + to ignore) should go into a .gitignore file. + + + + +Patterns which are + specific to a particular repository but which do not need to be shared + with other related repositories (e.g., auxiliary files that live inside + the repository but are specific to one user's workflow) should go into + the $GIT_DIR/info/exclude file. + + + + +Patterns which a user wants git to + ignore in all situations (e.g., backup or temporary files generated by + the user's editor of choice) generally go into a file specified by + core.excludesfile in the user's ~/.gitconfig. Its default value is + $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or + empty, $HOME/.config/git/ignore is used instead. + + + The underlying git plumbing tools, such as git ls-files and git read-tree, read gitignore patterns specified by command-line options, or from @@ -76,7 +93,7 @@ files specified by command-line options. Higher-level git tools, such as git status and git add, use patterns from the sources specified above. - + PATTERN FORMAT @@ -88,14 +105,18 @@ A blank line matches no files, so it can serve as a separator A line starting with # serves as a comment. + Put a backslash ("\") in front of the first hash for patterns + that begin with a hash. -An optional prefix ! which negates the pattern; any +An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. + Put a backslash ("\") in front of the first "!" for patterns + that begin with a literal "!", for example, "\!important!.txt". @@ -136,7 +157,7 @@ A leading slash matches the beginning of the pathname. - + NOTES The purpose of gitignore files is to ensure that certain files not tracked by git remain untracked. @@ -145,7 +166,7 @@ use git update-index --assume-unchanged. To stop tracking a file that is currently tracked, use git rm --cached. - + EXAMPLES $ git status [...] @@ -180,13 +201,13 @@ use git update-index --assume-unchanged. The second .gitignore prevents git from ignoring arch/foo/kernel/vmlinux.lds.S. - + SEE ALSO , , - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitk.xml b/doc/source/en/TortoiseGit/git_doc/gitk.xml index fe7ff3272..06cd55887 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitk.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitk.xml @@ -1,24 +1,22 @@ - + -
- + gitk(1) gitk(1) - - + NAME gitk - The git repository browser - + SYNOPSIS
gitk [<option>…] [<revs>] [--] [<path>…]
- + DESCRIPTION Displays changes in a repository or a selected set of commits. This includes visualizing the commit graph, showing information related to each commit, and @@ -27,7 +25,7 @@ the files in the trees of each revision. and started off in a separate repository but was later merged into the main git repository. - + OPTIONS To control which revisions to show, the command takes options applicable to the git rev-list command (see ). @@ -144,7 +142,7 @@ frequently used options. - + Examples @@ -183,12 +181,12 @@ gitk --max-count=100 --all -- Makefile - + Files Gitk creates the .gitk file in your $HOME directory to store preferences such as display options, font, and colors. - + SEE ALSO @@ -225,8 +223,8 @@ such as display options, font, and colors. - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitmodules.xml b/doc/source/en/TortoiseGit/git_doc/gitmodules.xml index 7f591e91a..410704f52 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitmodules.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitmodules.xml @@ -1,28 +1,28 @@ - + -
- + gitmodules(5) gitmodules(5) - - + NAME gitmodules - defining submodule properties - + SYNOPSIS $GIT_WORK_DIR/.gitmodules - + DESCRIPTION The .gitmodules file, located in the top-level directory of a git working tree, is a text file with a syntax matching the requirements of . The file contains one subsection per submodule, and the subsection value -is the name of the submodule. Each submodule section also contains the +is the name of the submodule. The name is set to the path where the +submodule has been added unless it was customized with the --name +option of git submodule add. Each submodule section also contains the following required keys: @@ -110,7 +110,7 @@ submodule.<name>.ignore - + EXAMPLES Consider the following .gitmodules file: [submodule "libfoo"] @@ -123,12 +123,12 @@ submodule.<name>.ignore be checked out in the paths include/foo and include/bar, and for both submodules a URL is specified which can be used for cloning the submodules. - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitnamespaces.xml b/doc/source/en/TortoiseGit/git_doc/gitnamespaces.xml index b86ae416e..eb3a06a06 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitnamespaces.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitnamespaces.xml @@ -1,25 +1,23 @@ - + -
- + gitnamespaces(7) gitnamespaces(7) - - + NAME gitnamespaces - Git namespaces - + SYNOPSIS
GIT_NAMESPACE=<namespace> git upload-pack GIT_NAMESPACE=<namespace> git receive-pack
- + DESCRIPTION Git supports dividing the refs of a single repository into multiple namespaces, each of which has its own branches, tags, and HEAD. Git can @@ -58,7 +56,7 @@ repository namespaces as repositories. For a simple local test, you can use : git clone ext::'git --namespace=foo %s /tmp/prefixed.git' - + SECURITY Anyone with access to any namespace within a repository can potentially access objects from any other namespace stored in the same repository. @@ -84,4 +82,4 @@ if everyone who may read one namespace may also read everything in every other namespace (for instance, if everyone in an organization has read permission to every repository). -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitrepository-layout.xml b/doc/source/en/TortoiseGit/git_doc/gitrepository-layout.xml index aab15afb9..961573b41 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitrepository-layout.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitrepository-layout.xml @@ -1,22 +1,20 @@ - + -
- + gitrepository-layout(5) gitrepository-layout(5) - - + NAME gitrepository-layout - Git Repository Layout - + SYNOPSIS $GIT_DIR/* - + DESCRIPTION You may find these things in your git repository (.git directory for a repository associated with your working tree, or @@ -187,6 +185,19 @@ refs/remotes/name +refs/replace/<obj-sha1> + + + + records the SHA1 of the object that replaces <obj-sha1>. + This is similar to info/grafts and is internally used and + maintained by . Such refs can be exchanged + between repositories while grafts are not. + + + + + packed-refs @@ -380,7 +391,7 @@ shallow - + SEE ALSO , , @@ -391,8 +402,8 @@ shallow , link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitrevisions.xml b/doc/source/en/TortoiseGit/git_doc/gitrevisions.xml index b2b87a61c..86edd257d 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitrevisions.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitrevisions.xml @@ -1,22 +1,20 @@ - + -
- + gitrevisions(7) gitrevisions(7) - - + NAME gitrevisions - specifying revisions and ranges for git - + SYNOPSIS gitrevisions - + DESCRIPTION Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which @@ -27,7 +25,7 @@ range of revisions explicitly. revision parameters which denote other objects than commits, e.g. blobs ("files") or trees ("directories of files"). - + SPECIFYING REVISIONS A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called an extended SHA1 @@ -71,20 +69,20 @@ blobs contained in a commit. object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean. - When ambiguous, a <name> is disambiguated by taking the + When ambiguous, a <refname> is disambiguated by taking the first match in the following rules: -If $GIT_DIR/<name> exists, that is what you mean (this is usually +If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD); -otherwise, refs/<name> if it exists; +otherwise, refs/<refname> if it exists; @@ -94,17 +92,17 @@ otherwise, refs/tags/<refname> if it exists; -otherwise, refs/heads/<name> if it exists; +otherwise, refs/heads/<refname> if it exists; -otherwise, refs/remotes/<name> if it exists; +otherwise, refs/remotes/<refname> if it exists; -otherwise, refs/remotes/<name>/HEAD if it exists. +otherwise, refs/remotes/<refname>/HEAD if it exists. HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a remote repository @@ -118,7 +116,9 @@ when you run git merge. CHERRY_PICK_HEAD records the commit which you are cherry-picking when you run git cherry-pick. Note that any of the refs/* cases above may come either from -the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. +the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. +While the ref name encoding is unspecified, UTF-8 is prefered as +some output processing may assume ref names in UTF-8. @@ -342,7 +342,7 @@ H = D^2 = B^^2 = A^^^2 = A~2^2 I = F^ = B^3^ = A^^3^ J = F^2 = B^3^2 = A^^3^2 - + SPECIFYING RANGES History traversing commands such as git log operate on a set of commits, not just a single commit. To these commands, @@ -362,26 +362,106 @@ of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable from either one of r1 or r2 but not from both. +In these two shorthands, you can omit one end and let it default to HEAD. +For example, origin.. is a shorthand for origin..HEAD and asks "What +did I do since I forked from the origin branch?" Similarly, ..origin +is a shorthand for HEAD..origin and asks "What did the origin do since +I forked from them?" Note that .. would mean HEAD..HEAD which is an +empty range that is both reachable and unreachable from HEAD. Two other shorthands for naming a set that is formed by a commit and its parent commits exist. The r1^@ notation means all parents of r1. r1^! includes commit r1 but excludes all of its parents. +To summarize: + + + +<rev> + + + + Include commits that are reachable from (i.e. ancestors of) + <rev>. + + + + + +^<rev> + + + + Exclude commits that are reachable from (i.e. ancestors of) + <rev>. + + + + + +<rev1>..<rev2> + + + + Include commits that are reachable from <rev2> but exclude + those that are reachable from <rev1>. + + + + + +<rev1>...<rev2> + + + + Include commits that are reachable from either <rev1> or + <rev2> but exclude those that are reachable from both. + + + + + +<rev>^@, e.g. HEAD^@ + + + + A suffix ^ followed by an at sign is the same as listing + all parents of <rev> (meaning, include anything reachable from + its parents, but not the commit itself). + + + + + +<rev>^!, e.g. HEAD^! + + + + A suffix ^ followed by an exclamation mark is the same + as giving commit <rev> and then all its parents prefixed with + ^ to exclude them (and their ancestors). + + + + Here are a handful of examples: D G H D D F G H I J D F ^G D H D ^D B E I J F B +B..C C B...C G H D E B C ^D B C E I J F B C +C I J F C C^@ I J F +C^! C F^! D G H D F - + SEE ALSO - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gittutorial-2.xml b/doc/source/en/TortoiseGit/git_doc/gittutorial-2.xml index e9a0bd112..ae16f0572 100644 --- a/doc/source/en/TortoiseGit/git_doc/gittutorial-2.xml +++ b/doc/source/en/TortoiseGit/git_doc/gittutorial-2.xml @@ -1,24 +1,22 @@ - + -
- + gittutorial-2(7) gittutorial-2(7) - - + NAME gittutorial-2 - A tutorial introduction to git: part two - + SYNOPSIS
git *
- + DESCRIPTION You should work through before reading this tutorial. The goal of this tutorial is to introduce two fundamental pieces of @@ -26,7 +24,7 @@ git's architecture--the object database and the index file--and to provide the reader with everything necessary to understand the rest of the git documentation. - + The git object database Let's start a new project and create a small amount of history: $ mkdir test-project @@ -191,7 +189,7 @@ tree, etc.--and most such commands can accept any of these names. In command synopses, the word "tree-ish" is sometimes used to designate such an argument. - + The index file The primary tool we've been using to create commits is git-commit -a, which creates a commit including every change you've made to @@ -324,7 +322,7 @@ branch, and is used to hold the trees involved in a merge operation. See and the relevant man pages for details. - + What next? At this point you should know everything necessary to read the man pages for any of the git commands; one good place to start would be @@ -341,7 +339,7 @@ link:howto-index.html[howtos]. into detail on the lower-level git mechanisms involved in, for example, creating a new commit. - + SEE ALSO , , @@ -351,8 +349,8 @@ example, creating a new commit. link:everyday.html[Everyday git], link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gittutorial.xml b/doc/source/en/TortoiseGit/git_doc/gittutorial.xml index 691d693e4..48c608e84 100644 --- a/doc/source/en/TortoiseGit/git_doc/gittutorial.xml +++ b/doc/source/en/TortoiseGit/git_doc/gittutorial.xml @@ -1,24 +1,22 @@ - + -
- + gittutorial(7) gittutorial(7) - - + NAME gittutorial - A tutorial introduction to git (for version 1.5.1 or newer) - + SYNOPSIS
git *
- + DESCRIPTION This tutorial explains how to import a new project into git, make changes to it, and share changes with other developers. @@ -38,7 +36,7 @@ way to do so is: $ git config --global user.name "Your Name Comes Here" $ git config --global user.email you@yourdomain.example.com - + Importing a new project Assume you have a tarball project.tar.gz with your initial work. You can place it under git revision control as follows. @@ -59,7 +57,7 @@ repository with git commit: This will prompt you for a commit message. You've now stored the first version of your project in git. - + Making changes Modify some files, then add their updated contents to the index: $ git add file1 file2 file3 @@ -90,11 +88,13 @@ them to the index, and commit, all in one step. A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more -thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the -commit in the body. +thorough description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout git. For example, turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body. - + Git tracks content not files Many revision control systems provide an add command that tells the system to start tracking changes to a new file. Git's add command @@ -103,7 +103,7 @@ and newly modified files, and in both cases it takes a snapshot of the given files and stages that content in the index, ready for inclusion in the next commit. - + Viewing project history At any point you can view the history of your changes using $ git log @@ -113,7 +113,7 @@ the next commit. each step $ git log --stat --summary - + Managing branches A single git repository can maintain multiple branches of development. To create a new branch named "experimental", use @@ -160,7 +160,7 @@ delete the branch with Branches are cheap and easy, so this is a good way to try something out. - + Using git for collaboration Suppose that Alice has started a new project with a git repository in /home/alice/project, and that Bob, who has a home directory on the @@ -266,7 +266,7 @@ see for details. that various users push changes to; see and . - + Exploring history Git history is represented as a series of interrelated commits. We have already seen that the git log command can list those commits. @@ -360,7 +360,7 @@ of the file: You can also use git show to see any such file: $ git show v2.5:Makefile - + Next Steps This tutorial should be enough to perform basic distributed revision control for your projects. However, to fully understand the depth @@ -424,7 +424,7 @@ link:everyday.html[Everyday GIT with 20 Commands Or So] - + SEE ALSO , , @@ -435,8 +435,8 @@ link:everyday.html[Everyday GIT with 20 Commands Or So] link:everyday.html[Everyday git], link:user-manual.html[The Git User's Manual] - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitweb.conf.xml b/doc/source/en/TortoiseGit/git_doc/gitweb.conf.xml index 207ce10be..df0ed3c65 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitweb.conf.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitweb.conf.xml @@ -1,22 +1,20 @@ - + -
- + gitweb.conf(5) gitweb.conf(5) - - + NAME gitweb.conf - Gitweb (git web interface) configuration file - + SYNOPSIS /etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl - + DESCRIPTION The gitweb CGI script for viewing Git repositories over the web uses a perl script fragment as its configuration file. You can set variables @@ -39,7 +37,7 @@ the use of symlinks. gitweb-wide basis: see "Per-repository gitweb configuration" subsection on manpage. - + DISCUSSION Gitweb reads configuration data from the following sources in the following order: @@ -97,13 +95,13 @@ some optional features will not be present unless explicitly enabled using the configurable %features variable (see also "Configuring gitweb features" section below). - + CONFIGURATION VARIABLES Some configuration variables have their default values (embedded in the CGI script) set during building gitweb -- if that is the case, this fact is put in their description. See gitweb's INSTALL file for instructions on building and installing gitweb. -
+
Location of repositories The configuration variables described below control how gitweb finds git repositories, and how repositories are displayed and accessed. @@ -223,7 +221,7 @@ $strict_export
-
+
Finding files The following configuration variables tell gitweb where to find files. The values of these variables are paths on the filesystem. @@ -271,7 +269,7 @@ $highlight_bin By default set to highlight; set it to full path to highlight executable if it is not installed on your web server's PATH. Note that highlight feature must be set for gitweb to actually - use syntax hightlighting. + use syntax highlighting. NOTE: if you want to add support for new file type (supported by "highlight" but not used by gitweb), you need to modify %highlight_ext @@ -289,7 +287,7 @@ $highlight_ext{'phtml'} = 'php';
-
+
Links and their targets The configuration variables described below configure some of gitweb links: their target and their look (text or image), and where to find page @@ -417,7 +415,7 @@ $logo_label
-
+
Changing gitweb's look You can adjust how pages generated by gitweb look using the variables described below. You can change the site name, add common headers and footers for all @@ -525,7 +523,7 @@ $default_projects_order
-
+
Changing gitweb's behavior These configuration variables control internal gitweb behavior. @@ -587,7 +585,7 @@ involve file copies ('-C') or criss-cross renames ('-B').
-
+
Some optional features and policies Most of features are configured via %feature hash; however some of extra gitweb features can be turned on and configured using variables described @@ -679,6 +677,27 @@ The default value is 300. +$omit_age_column + + + + If true, omit the column with date of the most current commit on the + projects list page. It can save a bit of I/O and a fork per repository. + + + + + +$omit_owner + + + + If true prevents displaying information about repository owner. + + + + + $per_request_config @@ -705,7 +724,7 @@ FastCGI or Plackup.
-
+
Other variables Usually you should not need to change (adjust) any of configuration variables described below; they should be automatically set by gitweb to @@ -761,7 +780,7 @@ $base_url
- + CONFIGURING GITWEB FEATURES Many gitweb features can be enabled (or disabled) and configured using the %feature hash. Names of gitweb features are keys of this hash. @@ -831,7 +850,7 @@ sub -
+
Features in <emphasis>%feature</emphasis> The gitweb features that are configurable via %feature hash are listed below. This should be a complete list, but ultimately the authoritative @@ -1103,7 +1122,7 @@ timezones in the form of "+/-HHMM", such as "+0200".
- + EXAMPLES To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and "zip" snapshots), while allowing individual projects to turn them off, put @@ -1122,7 +1141,7 @@ adding the following lines to your gitweb configuration file: $known_snapshot_formats{'zip'}{'disabled'} = 1; $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6']; - + ENVIRONMENT The location of per-instance and system-wide configuration files can be overridden using the following environment variables: @@ -1160,7 +1179,7 @@ GITWEB_CONFIG_COMMON - + FILES @@ -1199,13 +1218,13 @@ gitweb_config.perl - + SEE ALSO , gitweb/README, gitweb/INSTALL - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitweb.xml b/doc/source/en/TortoiseGit/git_doc/gitweb.xml index 4ab931287..d9e5e25da 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitweb.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitweb.xml @@ -1,24 +1,22 @@ - + -
- + gitweb(1) gitweb(1) - - + NAME gitweb - Git web interface (web frontend to Git repositories) - + SYNOPSIS To get started with gitweb, run from a git repository. This would configure and start your web server, and run web browser pointing to gitweb. - + DESCRIPTION Gitweb provides a web interface to git repositories. Its features include: @@ -70,12 +68,12 @@ Finding commits which commit messages matches given search term. http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, browsed using gitweb itself. - + CONFIGURATION Various aspects of gitweb's behavior can be controlled through the configuration file gitweb_config.perl or /etc/gitweb.conf. See the for details. -
+
Repositories Gitweb can show information from one or more Git repositories. These repositories have to be all on local filesystem, and have to share common @@ -94,7 +92,7 @@ to showing "bare" repositories). database) relative to $projectroot. Therefore the repository $repo can be found at "$projectroot/$repo".
-
+
Projects list file format Instead of having gitweb find repositories by scanning filesystem starting from $projectroot, you can provide a pre-generated list of @@ -175,7 +173,7 @@ a gitweb URL. By setting $strict_export configuration vari repositories also shown on the overview page (i.e. only projects explicitly listed in projects list file will be accessible).
-
+
Generating projects list using gitweb We assume that GITWEB_CONFIG has its default Makefile value, namely gitweb_config.perl. Put the following in gitweb_make_index.perl file: @@ -197,7 +195,7 @@ perl -- /var/www/cgi-bin/gitweb.cgi as projects list file, which means that you can set $projects_list to its filename.
-
+
Controlling access to git repositories By default all git repositories under $projectroot are visible and available to gitweb. You can however configure how gitweb controls access @@ -250,7 +248,7 @@ authorized to read the files:
-
+
Per-repository gitweb configuration You can configure individual repositories shown in gitweb by creating file in the GIT_DIR of git repository, or by setting some repo configuration @@ -354,7 +352,7 @@ various gitweb.* config variables (in config)
- + ACTIONS, AND URLS Gitweb can use path_info (component) based URLs, or it can pass all necessary information via query parameters. The typical gitweb URLs are broken down in to @@ -425,7 +423,7 @@ hash. Some actions are disabled by default, and must be turned on via feature mechanism. For example to enable blame view add the following to gitweb configuration file: $feature{'blame'}{'default'} = [1]; -
+
Actions: The standard actions are: @@ -608,14 +606,14 @@ atom
- + WEBSERVER CONFIGURATION This section explains how to configure some common webservers to run gitweb. In all cases, /path/to/gitweb in the examples is the directory you ran installed gitweb in, and contains gitweb_config.perl. If you've configured a web server that isn't listed here for gitweb, please send in the instructions so they can be included in a future release. -
+
Apache as CGI Apache must be configured to support CGI scripts in the directory in which gitweb is installed. Let's assume that it is /var/www/cgi-bin @@ -631,7 +629,7 @@ directory. With that configuration the full path to browse repositories would be: http://server/cgi-bin/gitweb.cgi
-
+
Apache with mod_perl, via ModPerl::Registry You can use mod_perl with gitweb. You must install Apache::Registry (for mod_perl 1.x) or ModPerl::Registry (for mod_perl 2.x) to enable @@ -652,7 +650,7 @@ Apache configuration (for mod_perl 2.x) is suitable. With that configuration the full path to browse repositories would be: http://server/perl/gitweb.cgi
-
+
Apache with FastCGI Gitweb works with Apache and FastCGI. First you need to rename, copy or symlink gitweb.cgi to gitweb.fcgi. Let's assume that gitweb is @@ -669,11 +667,11 @@ Alias /gitweb/static /usr/share/gitweb/static http://server/gitweb
- + ADVANCED WEB SERVER SETUP All of those examples use request rewriting, and need mod_rewrite (or equivalent; examples below are written for Apache). -
+
Single URL for gitweb and for fetching If you want to have one URL for both gitweb and your http:// repositories, you can configure Apache like this: @@ -714,7 +712,7 @@ $per_request_config = 1; Nowadays though gitweb should create HTML base tag when needed (to set base URI for relative links), so it should work automatically.
-
+
Webserver configuration with multiple projects' root If you want to use gitweb with several project roots you can edit your Apache virtual host and gitweb configuration files in the following way. @@ -775,7 +773,7 @@ through http://git.example.org/scm/ and http://gi You can add as many project roots as you want by adding rewrite rules like the third and the fourth.
-
+
PATH_INFO usage If you enable PATH_INFO usage in gitweb by putting $feature{'pathinfo'}{'default'} = [1]; @@ -843,18 +841,18 @@ a named ref (branch, tag) starting with git/, then paths su will fail with a 404 error.
- + BUGS Please report any bugs or feature requests to git@vger.kernel.org, putting "gitweb" in the subject of email. - + SEE ALSO , gitweb/README, gitweb/INSTALL - + GIT Part of the suite -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/gitworkflows.xml b/doc/source/en/TortoiseGit/git_doc/gitworkflows.xml index 618fa947c..5a286491a 100644 --- a/doc/source/en/TortoiseGit/git_doc/gitworkflows.xml +++ b/doc/source/en/TortoiseGit/git_doc/gitworkflows.xml @@ -1,24 +1,22 @@ - + -
- + gitworkflows(7) gitworkflows(7) - - + NAME gitworkflows - An overview of recommended workflows with git - + SYNOPSIS
git *
- + DESCRIPTION This document attempts to write down and motivate some of the workflow elements used for git.git itself. Many ideas apply in general, @@ -29,7 +27,7 @@ tries to motivate each of them. Do not always take them literally; you should value good reasons for your actions higher than manpages such as this one. - + SEPARATE CHANGES As a general rule, you should try to split your changes into small logical steps, and commit each of them. They should be consistent, @@ -46,7 +44,7 @@ publish them. You can use git stash save --keep-index to r test suite independent of other uncommitted changes; see the EXAMPLES section of . - + MANAGING BRANCHES There are two main tools that can be used to include changes from one branch on another: and @@ -63,7 +61,7 @@ understand because a merge commit is a "promise" that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. The following subsections discuss the important points. -
+
Graduation As a given feature goes from experimental to stable, it also "graduates" between the corresponding branches of the software. @@ -103,7 +101,7 @@ above it. or pu), and "graduates" to master for the next release once it is considered stable enough.
-
+
Merging upwards The "downwards graduation" discussed above cannot be done by actually merging downwards, however, since that would merge all changes on @@ -120,7 +118,7 @@ you will need to cherry-pick it (using ) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently.
-
+
Topic branches Any nontrivial feature will require several patches to implement, and may get extra bugfixes or improvements during its lifetime. @@ -184,7 +182,7 @@ of a file will have to find out whether that merge affected the topic in development. An upstream might even inadvertently be merged into a "more stable" branch. And so on.
-
+
Throw-away integration If you followed the last paragraph, you will now have many small topic branches, and occasionally wonder how they interact. Perhaps the @@ -204,7 +202,7 @@ to give the testers a chance to work with it, or other developers a chance to see if their in-progress work will be compatible. git.git has such an official throw-away integration branch called pu.
-
+
Branch management for a release Assuming you are using the merge approach discussed above, when you are releasing your project you will need to do some additional branch @@ -237,7 +235,7 @@ release tarballs and preformatted documentation pages. to be released. Therefore, in the steps above simply tag and push maint rather than master.
-
+
Maintenance branch management after a feature release After a feature release, you need to manage your maintenance branches. First, if you wish to continue to release maintenance fixes for the @@ -272,7 +270,7 @@ possible some fixes on maint were missed in the feature rel This will not happen if the content of the branches was verified as described in the previous section.
-
+
Branch management for next and pu after a feature release After a feature release, the integration branch next may optionally be rewound and rebuilt from the tip of master using the surviving @@ -322,7 +320,7 @@ announcement is not necessary since pu is a throw-away bran described above.
- + DISTRIBUTED WORKFLOWS After the last section, you should know how to manage topics. In general, you will not be the only person working on the project, so @@ -336,7 +334,7 @@ the merge workflow, while everyone else sends patches. "Signed-off-by" requirements, that all commits/patches submitted for inclusion must adhere to. Consult your project's documentation for more information. -
+
Merge workflow The merge workflow works by copying branches between upstream and downstream. Upstream can merge contributions into the official @@ -397,7 +395,7 @@ do the merge and resolve the conflicts themselves (perhaps they will know better how to resolve them). It is one of the rare cases where downstream should merge from upstream.
-
+
Patch workflow If you are a contributor that sends changes upstream in the form of emails, you should use topic branches as usual (see above). Then use @@ -445,7 +443,7 @@ in patches to figure out the merge base. See for other options.
- + SEE ALSO , , @@ -456,8 +454,8 @@ other options. , - + GIT Part of the suite. -
+ diff --git a/doc/source/en/TortoiseGit/git_doc/user-manual.xml b/doc/source/en/TortoiseGit/git_doc/user-manual.xml index 3f979111e..d8930de89 100644 --- a/doc/source/en/TortoiseGit/git_doc/user-manual.xml +++ b/doc/source/en/TortoiseGit/git_doc/user-manual.xml @@ -1,19 +1,17 @@ - + -
- + Git User's Manual (for version 1.5.3 or newer) - Git is a fast distributed revision control system. This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git. - and explain how + and explain how to fetch and study a project using git--read these chapters to learn how to build and test a particular version of a software project, search for regressions, and so on. People needing to do actual development will also want to read - and . + and . Further chapters cover more specialized topics. Comprehensive reference documentation is available through the man pages, or command. For example, for the command @@ -23,13 +21,13 @@ pages, or command. For example, for the command $ git help clone With the latter, you can use the manual viewer of your choice; see for more information. -See also for a brief overview of git commands, +See also for a brief overview of git commands, without any explanation. -Finally, see for ways that you can help make this manual more +Finally, see for ways that you can help make this manual more complete. -
+
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. @@ -45,22 +43,22 @@ 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, -called the working tree, together with a special +called the working tree, together with a special top-level directory named ".git", which contains all the information about the history of the project.
-
+
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 of the project's contents. In git each such -version is called a commit. +version is called a commit. Those snapshots aren't necessarily all arranged in a single line from oldest to newest; instead, work may simultaneously proceed along -parallel lines of development, called branches, which may +parallel lines of development, called branches, which may merge and diverge. A single git repository can track development on multiple branches. It -does this by keeping a list of heads which reference the +does this by keeping a list of heads which reference the latest commit on each branch; the command shows you the list of branch heads: $ git branch @@ -68,7 +66,7 @@ you the list of branch heads: A freshly cloned repository contains a single branch head, by default named "master", with the working directory initialized to the state of the project referred to by that branch head. -Most projects also use tags. Tags, like heads, are +Most projects also use tags. Tags, like heads, are references into the project's history, and can be listed using the command: $ git tag -l @@ -101,7 +99,7 @@ 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 command shows the most recent commit on the @@ -140,10 +138,10 @@ commit in their repository that it does in yours (assuming their repository has that commit at all). Since the object name is computed as a hash over the contents of the commit, you are guaranteed that the commit can never change without its name also changing. -In fact, in we shall see that everything stored in git +In fact, in we shall see that everything stored in git history, including file data and directory contents, is stored in an object with a name that is a hash of its contents. -
+
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. @@ -163,7 +161,7 @@ if commit X is an ancestor of commit Y. Equivalently, you could say that Y is a descendant 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 @@ -176,7 +174,7 @@ lines drawn with - / and \. Time goes left to right: 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? When we need to be precise, we will use the word "branch" to mean a line of development, and "branch head" (or just "head") to mean a reference @@ -188,7 +186,7 @@ the line of three commits leading up to that point as all being part of "branch" both for branches and for branch heads.
-
+
Manipulating branches Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands: @@ -281,7 +279,7 @@ remember which branch is current: $ cat .git/HEAD ref: refs/heads/master
-
+
Examining an old version without creating a new branch The git checkout command normally expects a branch head, but will also accept an arbitrary commit; for example, you can check out the commit @@ -304,7 +302,7 @@ $ git branch make up a name for the new branch. You can still create a new branch (or tag) for this version later if you decide to.
-
+
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 @@ -326,16 +324,16 @@ for short. The branches of this repository are called "remote branches" from our point of view. The remote-tracking branches listed above were created based on the remote branches at clone time and will be updated by "git fetch" (hence "git pull") and "git push". See - for details. + for details. You might want to build on one of these remote-tracking branches on a branch of your own, just as you would for a tag: $ git checkout -b my-todo-copy origin/todo You can also check out "origin/todo" directly to examine it or -write a one-off patch. See detached head. +write a one-off patch. See detached head. Note that the name "origin" is just the name that git uses by default to refer to the repository that you cloned from.
-
+
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 @@ -372,7 +370,7 @@ 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 .
-
+
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 @@ -382,7 +380,7 @@ 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 : @@ -411,7 +409,7 @@ text editor. (See the "CONFIGURATION FILE" section of 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 @@ -421,7 +419,7 @@ the relationships between these snapshots. 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 @@ -474,7 +472,7 @@ test script that can tell a good from a bad commit. See for more information about this and other "git bisect" features.
-
+
Naming commits We have seen several ways of naming commits already: @@ -493,7 +491,7 @@ branch name: refers to the commit at the head of the given tag name: refers to the commit pointed to by the given tag (we've seen branches and tags are special cases of - references). + references). @@ -534,7 +532,7 @@ 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 @@ -545,7 +543,7 @@ comment with the tag, and possibly sign it cryptographically, then you should create a tag object instead; see the man page for details.
-
+
Browsing revisions The command can show lists of commits. On its own, it shows all commits reachable from the parent commit; but you @@ -572,7 +570,7 @@ 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 : @@ -587,7 +585,7 @@ use : will generate a file with a patch for each commit reachable from test but not from master.
-
+
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 @@ -597,9 +595,9 @@ anything out; this command does that: Before the colon may be anything that names a commit, and after it may be any path to a file tracked by git.
-
+
Examples -
+
Counting the number of commits on a branch Suppose you want to know how many commits you've made on "mybranch" since it diverged from "origin": @@ -609,7 +607,7 @@ lower-level command , which just lists the SHA of all the given commits: $ git rev-list origin..mybranch | wc -l
-
+
Check whether two branches point at the same history Suppose you want to check whether two branches point at the same point in history. @@ -628,7 +626,7 @@ 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 @@ -678,7 +676,7 @@ 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.
-
+
Showing commits unique to a given branch Suppose you would like to see all the commits reachable from the branch head named "master" but not from any other head in your repository. @@ -707,7 +705,7 @@ commits reachable from some head but not from any tag in the repository:(See for explanations of commit-selecting syntax such as --not.)
-
+
Creating a changelog and tarball for a software release The command can create a tar or zip archive from any version of a project; for example: @@ -734,7 +732,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"and then he just cut-and-pastes the output commands after verifying that they look OK.
-
+
Finding commits referencing a file with given content Somebody hands you a copy of a file, and asks which commits modified a file such that it contained the given content either before or after the @@ -747,9 +745,9 @@ student. The ,
-
+
Developing with git -
+
Telling git your name Before creating any commits, you should introduce yourself to git. The easiest way to do so is to make sure the following lines appear in a @@ -760,7 +758,7 @@ file named .gitconfig in your home directory: (See the "CONFIGURATION FILE" section of for details on the configuration file.)
-
+
Creating a new repository Creating a new repository from scratch is very easy: $ mkdir project @@ -773,7 +771,7 @@ $ git init $ git add . # include everything below ./ in the first commit: $ git commit
-
+
How to make a commit Creating a new commit takes three steps: @@ -843,16 +841,18 @@ the index and the working tree files, and individually select diff hunks for inclusion in the index (by right-clicking on the diff hunk and choosing "Stage Hunk For Commit").
-
+
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. +description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout git. For example, turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body.
-
+
Ignoring files A project will often generate files that you do not want to track with git. This typically includes files generated by a build process or temporary @@ -886,7 +886,7 @@ specified by the core.excludesfile configuration variable. commands can also take exclude patterns directly on the command line. See for the details.
-
+
How to merge You can rejoin two diverging branches of development using : @@ -905,7 +905,7 @@ and if you don't, then can take these changes away while you're doing the merge, and reapply them afterwards. If the changes are independent enough, Git will automatically complete the merge and commit the result (or reuse an existing commit in case -of fast-forward, see below). On the other hand, +of fast-forward, see below). On the other hand, 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: @@ -922,7 +922,7 @@ creating a new file. has two parents, one pointing to the top of the current branch, and one to the top of the other branch.
-
+
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 @@ -948,7 +948,7 @@ default message unchanged, but you may add additional commentary of your own if desired. The above is all you need to know to resolve a simple merge. But git also provides more information to help resolve conflicts: -
+
Getting conflict-resolution help during a merge All of the changes that git was able to merge automatically are already added to the index file, so shows only @@ -1021,7 +1021,7 @@ unmerged files using external tools such as Emacs or kdiff3. git diff will (by default) no longer show diffs for that file.
-
+
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 @@ -1033,7 +1033,7 @@ 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 @@ -1045,7 +1045,7 @@ just performs a "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 @@ -1071,7 +1071,7 @@ You can go back and modify the old commit. You should -
+
Fixing a mistake with a new commit Creating a new commit that reverts an earlier change is very easy; just pass the command a reference to the bad @@ -1084,16 +1084,16 @@ will be given a chance to edit the commit message for the new commit. 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. +conflicts manually, just as in the case of resolving a merge.
-
+
Fixing a mistake by rewriting history If the problematic commit is the most recent commit, and you have not yet made that commit public, then you may just -destroy it using git reset. +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 create a new commit, then run +mistake, just as if you were going to 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. @@ -1102,9 +1102,9 @@ been merged into another branch; use instead in that case. It is also possible to replace commits further back in the history, but this is an advanced topic to be left for -another chapter. +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 @@ -1120,7 +1120,7 @@ modifying the working directory, you can do that with $ git show HEAD^:path/to/file which will display the given version of the file.
-
+
Temporarily setting aside work in progress While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it @@ -1139,7 +1139,7 @@ $ git commit -a -m "blorpl: typofix" $ git stash pop
-
+
Ensuring good performance On large repositories, git depends on compression to keep the history information from taking up too much space on disk or in memory. @@ -1149,9 +1149,9 @@ should occasionally run : 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 command runs a number of self-consistency checks on the repository, and reports on any problems. This may take some @@ -1169,10 +1169,10 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f You will see informational messages on dangling objects. They are objects that still exist in the repository but are no longer referenced by any of your branches, and can (and will) be removed after a while with "gc". -You can run git fsck --no-dangling to supress these messages, and still +You can run git fsck --no-dangling to suppress these messages, and still view real errors.
-
+
Recovering lost changes
Reflogs @@ -1212,7 +1212,7 @@ suppose you delete a branch, then realize you need the history it contained. 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 in the dangling objects that git fsck reports. See - for the details. + for the details. $ git fsck dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 @@ -1237,14 +1237,14 @@ dangling objects can arise in other situations.
-
+
Sharing development with others -
+
Getting updates with git pull After you clone a repository and commit 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 how to keep remote-tracking branches up to date with , +We have already seen how to keep remote-tracking branches up to date with , and how to merge two branches. So you can merge in changes from the original repository's master branch with: $ git fetch @@ -1270,7 +1270,7 @@ branch.<name>.remote and branch.<name>.merge options in 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-forward; instead, your branch will just be +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 @@ -1279,7 +1279,7 @@ the commands $ 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: @@ -1287,13 +1287,19 @@ just be to send them as patches in email: $ 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. +git format-patch can include an initial "cover letter". You can insert +commentary on individual patches after the three dash line which +format-patch places after the commit message but before the patch +itself. If you use git notes to track your cover letter material, +git format-patch --notes will include the commit's notes in a similar +manner. 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 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 (am stands for "apply mailbox"), for importing such an emailed series of patches. @@ -1302,7 +1308,7 @@ 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". (The "-3" option tells +"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 @@ -1314,11 +1320,11 @@ remaining patches from the mailbox. the original mailbox, with authorship and commit log message each taken from the message containing each patch.
-
+
Public git repositories Another way to submit changes to a project is to tell the maintainer of that project to pull the changes from your repository using -. In the section "Getting updates with git pull" we described this as a way to get +. In the section "Getting updates with git pull" we described this as a way to get updates from the "main" repository, but it works just as well in the other direction. If you and the maintainer both have accounts on the same machine, then @@ -1351,7 +1357,7 @@ your personal repo ------------------> your public repo | they push V their public repo <------------------- their repo We explain how to do this in the following sections. -
+
Setting up a public repository Assume your personal repository is in the directory ~/proj. We first create a new clone of the repository and tell git daemon that it @@ -1365,13 +1371,13 @@ around it. public repository. You can use scp, rsync, or whatever is most convenient.
-
+
Exporting a git repository via the git protocol This is the preferred method. If someone else administers the server, they should tell you what directory to put the repository in, and what git:// URL it will appear at. You can then skip to the section -"Pushing changes to a public repository", below. +"Pushing changes to a public repository", below. Otherwise, all you need to do is start ; it will listen on port 9418. By default, it will allow access to any directory that looks like a git directory and contains the magic file @@ -1381,7 +1387,7 @@ arguments will further restrict the exports to those paths. man page for details. (See especially the examples section.)
-
+
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. @@ -1402,10 +1408,10 @@ 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.)
-
+
Pushing changes to a public repository Note that the two techniques outlined above (exporting via -http or git) allow other +http or 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. @@ -1416,10 +1422,10 @@ branch named "master", run 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-forward; see the following section for details on +fast-forward; see the following section for details on handling this case. Note that the target of a "push" is normally a -bare repository. You can also push to a +bare repository. You can also push to a repository that has a checked-out working tree, but the working tree will not be updated by the push. This may lead to unexpected results if the branch you push to is the currently checked-out branch! @@ -1435,9 +1441,9 @@ EOF and remote.<name>.push options in for details.
-
+
What to do when a push fails -If a push would not result in a fast-forward of the +If a push would not result in a fast-forward of the remote branch, then it will fail with an error like: error: remote 'refs/heads/master' is not an ancestor of local 'refs/heads/master'. @@ -1453,13 +1459,13 @@ use git reset --hard to remove already-published commits, o use git commit --amend to replace already-published commits - (as in ), or + (as in ), or use git rebase to rebase any already-published commits (as - in ). + in ). @@ -1469,7 +1475,7 @@ branch name with a plus sign: Normally whenever a branch head in a public repository is modified, it is modified to point to a descendant of the commit that it pointed to before. By forcing a push in this situation, you break that convention. -(See .) +(See .) Nevertheless, this is a common practice for people that need a simple way to publish a work-in-progress patch series, and it is an acceptable compromise as long as you warn other developers that this is how you @@ -1478,10 +1484,10 @@ intend to manage the branch. the right to push to the same repository. In that case, the correct solution is to retry the push after first updating your work: either by a pull, or by a fetch followed by a rebase; see the -next section and +next section and for more.
-
+
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 @@ -1522,16 +1528,16 @@ The lack of a central group of "committers" means there is
-
+
Allowing 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/INSTALL in the git source tree for instructions on setting it up.
-
+
Examples -
+
Maintaining topic branches for a Linux subsystem maintainer This describes how Tony Luck uses git in his role as maintainer of the IA64 architecture for the Linux kernel. @@ -1563,7 +1569,7 @@ $ cd work and can be updated using ; you can track other public trees using to set up a "remote" and to keep them up-to-date; see -. +. Now create the branches in which you are going to work; these start out at the current tip of origin/master branch, and should be set up (using the --track option to ) to merge changes in from @@ -1582,7 +1588,7 @@ will become part of the permanent history when you ask Linus to pull from the release branch. A few configuration variables (see ) can make it easy to push both branches to your public tree. (See -.) +.) $ cat >> .git/config <<EOF [remote "mytree"] url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git @@ -1750,14 +1756,14 @@ done
-
+
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 @@ -1798,7 +1804,7 @@ The complete series produces the same end result as your own 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 that you create a branch "mywork" on a remote-tracking branch "origin", and create some commits on top of it: @@ -1845,9 +1851,9 @@ running git commit, just run return mywork to the state it had before you started the rebase: $ git rebase --abort
-
+
Rewriting a single commit -We saw in that you can replace the +We saw in that you can replace the most recent commit using $ git commit --amend which will replace the old commit by a new commit incorporating your @@ -1860,7 +1866,7 @@ with (Either gitk or git log may be useful for finding the commit.) Then check out that commit, edit it, and rebase the rest of the series on top of it (note that we could check out the commit on a temporary -branch, but instead we're using a detached head): +branch, but instead we're using a detached head): $ git checkout bad $ # make changes here and update the index $ git commit --amend @@ -1873,7 +1879,7 @@ then clean up with "modified" existing commits; instead, you have replaced the old commits with new commits having new object names.
-
+
Reordering or selecting from a patch series Given one existing commit, the command allows you to apply the change introduced by that commit and create a @@ -1894,13 +1900,13 @@ $ git reset --hard origin Then modify, reorder, or eliminate patches as preferred before applying them again with .
-
+
Other tools There are numerous other tools, such as StGit, which exist for the purpose of maintaining a patch series. These are outside 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 @@ -1933,7 +1939,7 @@ branches into their own work. For true distributed development that supports proper merging, published branches should never be rewritten.
-
+
Why bisecting merge commits can be harder than bisecting linear history The command correctly handles history that includes merge commits. However, when the commit that it finds is a @@ -1983,9 +1989,9 @@ linear by rebasing against the latest upstream version before publishing.
-
+
Advanced branch management -
+
Fetching individual branches Instead of using , you can also choose just to update one branch at a time, and to store it locally under an @@ -2000,16 +2006,16 @@ store it locally under the name refs/heads/my-todo-work. 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 +fast-forward to the commit given by example.com's master branch. In more detail:
-
+
git fetch and 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. +commit. Git calls this process a fast-forward. A fast-forward looks something like this: o--o--o--o <-- old head of the branch \ @@ -2028,7 +2034,7 @@ 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: @@ -2039,7 +2045,7 @@ flag to force updates of all the fetched branches, as in: Be aware that commits that the old version of example/master pointed at may be lost, as we saw in the previous section.
-
+
Configuring remote-tracking branches We saw above that "origin" is just a shortcut to refer to the repository that you originally cloned from. This information is @@ -2067,7 +2073,7 @@ $ git fetch example master:refs/remotes/example/master $ git fetch example master:refs/remotes/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 +$ git config remote.example.fetch +master:refs/remotes/example/master Don't do this unless you're sure you won't mind "git fetch" possibly throwing away commits on example/master. Also note that all of the above configuration can be performed by @@ -2077,15 +2083,15 @@ directly editing the file .git/config instead of using options mentioned above.
-
+
Git concepts Git is built on a small number of simple but powerful ideas. While it is possible to get things done without understanding them, you will find git much more intuitive if you do. -We start with the most important, the object database and the index. -
+We start with the most important, the object database and the index. +
The Object Database -We already saw in that all commits are stored +We already saw in that all commits are stored under a 40-digit "object name". In fact, all the information needed to represent the history of a project is stored in objects with such names. In each case the name is calculated by taking the SHA-1 hash of the @@ -2114,27 +2120,27 @@ Git can detect errors when it reads an object, by checking that the -(See for the details of the object formatting and +(See for the details of the object formatting and SHA-1 calculation.) There are four different types of objects: "blob", "tree", "commit", and "tag". -A "blob" object is used to store file data. +A "blob" object is used to store file data. -A "tree" object ties one or more +A "tree" object 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 directed acyclic graph of revisions--each +A "commit" object ties such directory hierarchies + together into a directed acyclic graph of revisions--each commit contains the object name of exactly one tree designating the directory hierarchy at the time of the commit. In addition, a commit refers to "parent" commit objects that describe the history of how we @@ -2143,7 +2149,7 @@ A "commit" object ties such directory h -A "tag" object symbolically identifies and can be +A "tag" object symbolically identifies and can be used to sign other objects. It contains the object name and type of another object, a symbolic name (of course!) and, optionally, a signature. @@ -2151,7 +2157,7 @@ A "tag" object symbolically identifies and The object types in some more detail: -
+
Commit Object The "commit" object links a physical state of a tree with a description of how we got there and why. Use the --pretty=raw option to @@ -2177,7 +2183,7 @@ a tree: The SHA-1 name of a tree object (as defined below), representing -parent(s): The SHA-1 name of some number of commits which represent the +parent(s): The SHA-1 name(s) of some number of commits which represent the immediately previous step(s) in the history of the project. The example above has one parent; merge commits may have more than one. A commit with no parents is called a "root" commit, and @@ -2217,7 +2223,7 @@ file data at changing paths suggests a rename. (See, for example, the commit whose parent is normally the current HEAD, and whose tree is taken from the content currently stored in the index.
-
+
Tree Object The ever-versatile command can also be used to examine tree objects, but will give you more @@ -2244,11 +2250,11 @@ are identical. This allows git to quickly determine the differences between two related tree objects, since it can ignore any entries with identical object names. (Note: in the presence of submodules, trees may also have commits as -entries. See for documentation.) +entries. See for documentation.) Note that the files all have mode 644 or 755: git actually only pays attention to the executable bit.
-
+
Blob Object You can use to examine the contents of a blob; take, for example, the blob in the entry for "COPYING" from the tree above: @@ -2270,7 +2276,7 @@ renaming a file does not change the object that file is associated with.
-
+
Trust If you receive the SHA-1 name of a blob from one source, and its contents from another (possibly untrusted) source, you can still trust that those @@ -2294,7 +2300,7 @@ 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 A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain @@ -2318,7 +2324,7 @@ objects. (Note that can also be used to create "lightweight tags", which are not tag objects at all, but just simple references whose names begin with "refs/tags/").
-
+
How git stores objects efficiently: pack files Newly created objects are initially created in a file named after the object's SHA-1 hash (stored in .git/objects). @@ -2357,13 +2363,13 @@ objects will work exactly as they did before. The command performs packing, pruning, and more for you, so is normally the only high-level command you need.
-
+
Dangling objects The 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 -. In that case, the old head of the original +. In that case, the old head of the original branch still exists, as does everything it pointed to. The branch pointer itself just doesn't, since you replaced it with another one. There are also other situations that cause dangling objects. For @@ -2418,7 +2424,7 @@ 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).
-
+
Recovering from repository corruption By design, git treats data trusted to it with caution. However, even in the absence of bugs in git itself, it is still possible that hardware or @@ -2481,8 +2487,8 @@ Date: ... :100644 100644 oldsha... 4b9458b... M somedirectory/myfile -This tells you that the immediately preceding version of the file was -"newsha", and that the immediately following version was "oldsha". +This tells you that the immediately following version of the file was +"newsha", and that the immediately preceding version was "oldsha". You also know the commit messages that went with the change from oldsha to 4b9458b and with the change from 4b9458b to newsha. If you've been committing small enough changes, you may now have a good @@ -2497,7 +2503,7 @@ whole thing. It's up to you - git does have a just missing one particular blob version.
-
+
The index The index is a binary file (generally kept in .git/index) containing a sorted list of path names, each with permissions and the SHA-1 of a blob @@ -2544,7 +2550,7 @@ 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. -We saw in that during a merge the index can +We saw in that during a merge the index can store multiple versions of a single file (called "stages"). The third column in the output above is the stage number, and will take on values other than 0 for files with merge @@ -2557,7 +2563,7 @@ a tree which you are in the process of working on. information as long as you have the name of the tree that it described.
-
+
Submodules Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution's source tree would include every @@ -2698,7 +2704,7 @@ $ git commit -m "Updated submodule a." $ git push You have to run git submodule update after git pull if you want to update submodules, too. -
+
Pitfalls with submodules Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, @@ -2751,13 +2757,13 @@ module a This is not the case if you did not commit your changes.
-
+
Low-level git operations Many of the higher-level commands were originally implemented as shell scripts using a smaller core of low-level git commands. These can still be useful when doing unusual things with git, or just as a way to understand its inner workings. -
+
Object access and manipulation The command can show the contents of any object, though the higher-level is usually more useful. @@ -2770,7 +2776,7 @@ accessed by . Two trees can be compared with verified by , though it is normally simpler to use for both.
-
+
The Workflow High-level operations such as , and work by moving data @@ -2782,7 +2788,7 @@ work purely on the index file (showing the cu index), but most operations move data between the index file and either the database or the working directory. Thus there are four main combinations: -
+
working directory → index The command updates the index with information from the working directory. You generally update the @@ -2809,7 +2815,7 @@ an object still matches its old backing store object. The previously introduced is just a wrapper for .
-
+
index → object database You write your current index file to a "tree" object with the program $ git write-tree @@ -2819,7 +2825,7 @@ 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 @@ -2830,7 +2836,7 @@ index. Normal operation is just 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 @@ -2850,7 +2856,7 @@ need to use the "-f" flag (before the "-a" flag or the file 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 @@ -2910,7 +2916,7 @@ various pieces fit together. +-----------+
-
+
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 @@ -2931,7 +2937,7 @@ 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 @@ -2964,7 +2970,7 @@ you have in your current index anyway). 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 @@ -2982,8 +2988,8 @@ $ git ls-files --unmerged Each line of the git ls-files --unmerged output begins with the blob mode bits, blob SHA-1, 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. +came from: stage 1 corresponds to the $orig tree, stage 2 to +the HEAD tree, and stage 3 to the $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 @@ -3015,11 +3021,11 @@ stages to temporary files and calls a "merge" script on it: and that is what higher level git merge -s resolve is implemented with.
-
+
Hacking git This chapter covers internal details of the git implementation which probably only git developers need to understand. -
+
Object storage format All objects have a statically determined "type" which identifies the format of the object (i.e. how it is used, and how it can refer to other @@ -3046,7 +3052,7 @@ the git fsck program, which generates a full dependency gra of all objects, and verifies their internal consistency (in addition to just verifying their superficial consistency through the hash).
-
+
A birds-eye view of Git's source code It is not always easy for new developers to find their way through Git's source code. This section gives you a little guidance to show where to @@ -3057,7 +3063,7 @@ start. today, but is small enough to read in one sitting. Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we -now call a commit. +now call a commit. Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. Remark: Not much reason to change it now, especially since there is no good single name for it anyway, because it is @@ -3078,7 +3084,7 @@ structures in cache.h), and that there are just a couple of (struct object *)commit to achieve the same as &commit->object, i.e. get at the object name and flags). Now is a good point to take a break to let this information sink in. -Next step: get familiar with the object naming. Read . +Next step: get familiar with the object naming. Read . There are quite a few ways to name an object (and not only revisions!). All of these are handled in sha1_name.c. Just have a quick look at the function get_sha1(). A lot of the special handling is done by @@ -3220,29 +3226,29 @@ builtin: itself!
-
+
Git Glossary -alternate object database +alternate object database - Via the alternates mechanism, a repository - can inherit part of its object database + Via the alternates mechanism, a repository + can inherit part of its object database from another object database, which is called "alternate". -bare repository +bare repository A bare repository is normally an appropriately - named directory with a .git suffix that does not + named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the git administrative and control files that would normally be present in the @@ -3255,61 +3261,61 @@ itself! -blob object +blob object - Untyped object, e.g. the contents of a file. + Untyped object, e.g. the contents of a file. -branch +branch A "branch" is an active line of development. The most recent - commit on a branch is referred to as the tip of + commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch - head, which moves forward as additional development + head, which moves forward as additional development is done on the branch. A single git - repository can track an arbitrary number of - branches, but your working tree is + repository can track an arbitrary number of + branches, but your working tree is associated with just one of them (the "current" or "checked out" - branch), and HEAD points to that branch. + branch), and HEAD points to that branch. -cache +cache - Obsolete for: index. + Obsolete for: index. -chain +chain - A list of objects, where each object in the list contains + A list of objects, where each object in the list contains a reference to its successor (for example, the successor of a - commit could be one of its parents). + commit could be one of its parents). -changeset +changeset - BitKeeper/cvsps speak for "commit". Since git does not + BitKeeper/cvsps speak for "commit". Since git does not store changes, but states, it really does not make sense to use the term "changesets" with git. @@ -3317,49 +3323,49 @@ itself! -checkout +checkout The action of updating all or part of the - working tree with a tree object - or blob from the - object database, and updating the - index and HEAD if the whole working tree has - been pointed at a new branch. + working tree with a tree object + or blob from the + object database, and updating the + index and HEAD if the whole working tree has + been pointed at a new branch. -cherry-picking +cherry-picking - In SCM jargon, "cherry pick" means to choose a subset of + In SCM jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In GIT, this is performed by the "git cherry-pick" command to extract the change introduced - by an existing commit and to record it based on the tip - of the current branch as a new commit. + by an existing commit and to record it based on the tip + of the current branch as a new commit. -clean +clean - A working tree is clean, if it - corresponds to the revision referenced by the current - head. Also see "dirty". + A working tree is clean, if it + corresponds to the revision referenced by the current + head. Also see "dirty". -commit +commit @@ -3368,31 +3374,31 @@ itself! set of interrelated commits. The word "commit" is often used by git in the same places other revision control systems use the words "revision" or "version". Also used as a short - hand for commit object. + hand for commit object. As a verb: The action of storing a new snapshot of the project's state in the git history, by creating a new commit representing the current -state of the index and advancing HEAD +state of the index and advancing HEAD to point at the new commit. -commit object +commit object - An object which contains the information about a - particular revision, such as parents, committer, - author, date and the tree object which corresponds - to the top directory of the stored + An object which contains the information about a + particular revision, such as parents, committer, + author, date and the tree object which corresponds + to the top directory of the stored revision. -core git +core git @@ -3403,56 +3409,56 @@ to point at the new commit. -DAG +DAG - Directed acyclic graph. The commit objects form a + Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents (directed), and the - graph of commit objects is acyclic (there is no chain - which begins and ends with the same object). + graph of commit objects is acyclic (there is no chain + which begins and ends with the same object). -dangling object +dangling object - An unreachable object which is not - reachable even from other unreachable objects; a + An unreachable object which is not + reachable even from other unreachable objects; a dangling object has no references to it from any - reference or object in the repository. + reference or object in the repository. -detached HEAD +detached HEAD - Normally the HEAD stores the name of a - branch. However, git also allows you to check out - an arbitrary commit that isn't necessarily the tip of any + Normally the HEAD stores the name of a + branch. However, git also allows you to check out + an arbitrary commit that isn't necessarily the tip of any particular branch. In this case HEAD is said to be "detached". -dircache +dircache - You are waaaaay behind. See index. + You are waaaaay behind. See index. -directory +directory @@ -3462,73 +3468,73 @@ to point at the new commit. -dirty +dirty - A working tree is said to be "dirty" if - it contains modifications which have not been committed to the current - branch. + A working tree is said to be "dirty" if + it contains modifications which have not been committed to the current + branch. -ent +ent - Favorite synonym to "tree-ish" by some total geeks. See - http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth + Favorite synonym to "tree-ish" by some total geeks. See + http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth explanation. Avoid this term, not to confuse people. -evil merge +evil merge - An evil merge is a merge that introduces changes that - do not appear in any parent. + An evil merge is a merge that introduces changes that + do not appear in any parent. -fast-forward +fast-forward - A fast-forward is a special type of merge where you have a - revision and you are "merging" another - branch's changes that happen to be a descendant of what - you have. In such these cases, you do not make a new merge - commit but instead just update to his + A fast-forward is a special type of merge where you have a + revision and you are "merging" another + branch's changes that happen to be a descendant of what + you have. In such these cases, you do not make a new merge + commit but instead just update to his revision. This will happen frequently on a - remote-tracking branch of a remote - repository. + remote-tracking branch of a remote + repository. -fetch +fetch - Fetching a branch means to get the - branch's head ref from a remote - repository, to find out which objects are - missing from the local object database, + Fetching a branch means to get the + branch's head ref from a remote + repository, to find out which objects are + missing from the local object database, and to get them, too. See also . -file system +file system @@ -3540,23 +3546,23 @@ to point at the new commit. -git archive +git archive - Synonym for repository (for arch people). + Synonym for repository (for arch people). -grafts +grafts Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way - you can make git pretend the set of parents a commit has + you can make git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file. @@ -3564,22 +3570,22 @@ to point at the new commit. -hash +hash - In git's context, synonym to object name. + In git's context, synonym to object name. -head +head - A named reference to the commit at the tip of a - branch. Heads are stored in a file in + A named reference to the commit at the tip of a + branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs. (See .) @@ -3587,31 +3593,31 @@ to point at the new commit. -HEAD +HEAD - The current branch. In more detail: Your working tree is normally derived from the state of the tree + The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the - heads in your repository, except when using a - detached HEAD, in which case it directly + heads in your repository, except when using a + detached HEAD, in which case it directly references an arbitrary commit. -head ref +head ref - A synonym for head. + A synonym for head. -hook +hook @@ -3628,39 +3634,39 @@ to point at the new commit. -index +index A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your - working tree. Truth be told, it can also contain a second, and even + working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used - when merging. + when merging. -index entry +index entry The information regarding a particular file, stored in the - index. An index entry can be unmerged, if a - merge was started, but not yet finished (i.e. if + index. An index entry can be unmerged, if a + merge was started, but not yet finished (i.e. if the index contains multiple versions of that file). -master +master - The default development branch. Whenever you - create a git repository, a branch named + The default development branch. Whenever you + create a git repository, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required. @@ -3669,112 +3675,112 @@ to point at the new commit. -merge +merge As a verb: To bring the contents of another - branch (possibly from an external - repository) into the current branch. In the + branch (possibly from an external + repository) into the current branch. In the case where the merged-in branch is from a different repository, - this is done by first fetching the remote branch + this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a - pull. Merging is performed by an automatic process + pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge. -As a noun: unless it is a fast-forward, a -successful merge results in the creation of a new commit +As a noun: unless it is a fast-forward, a +successful merge results in the creation of a new commit representing the result of the merge, and having as -parents the tips of the merged branches. +parents the tips of the merged branches. This commit is referred to as a "merge commit", or sometimes just a "merge". -object +object The unit of storage in git. It is uniquely identified by the - SHA1 of its contents. Consequently, an + SHA1 of its contents. Consequently, an object can not be changed. -object database +object database - Stores a set of "objects", and an individual object is - identified by its object name. The objects usually + Stores a set of "objects", and an individual object is + identified by its object name. The objects usually live in $GIT_DIR/objects/. -object identifier +object identifier - Synonym for object name. + Synonym for object name. -object name +object name - The unique identifier of an object. The hash + The unique identifier of an object. The hash of the object's contents using the Secure Hash Algorithm 1 and usually represented by the 40 character hexadecimal encoding of - the hash of the object. + the hash of the object. -object type +object type - One of the identifiers "commit", - "tree", "tag" or - "blob" describing the type of an - object. + One of the identifiers "commit", + "tree", "tag" or + "blob" describing the type of an + object. -octopus +octopus - To merge more than two branches. Also denotes an + To merge more than two branches. Also denotes an intelligent predator. -origin +origin - The default upstream repository. Most projects have + The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates - will be fetched into remote remote-tracking branches named + will be fetched into remote remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r. @@ -3782,7 +3788,7 @@ This commit is referred to as a "merge commit", or sometimes just a -pack +pack @@ -3793,19 +3799,19 @@ This commit is referred to as a "merge commit", or sometimes just a -pack index +pack index The list of identifiers, and other information, of the objects in a - pack, to assist in efficiently accessing the contents of a + pack, to assist in efficiently accessing the contents of a pack. -pathspec +pathspec @@ -3879,11 +3885,11 @@ should not be combined with other pathspec. -parent +parent - A commit object contains a (possibly empty) list + A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents. @@ -3891,108 +3897,108 @@ should not be combined with other pathspec. -pickaxe +pickaxe - The term pickaxe refers to an option to the diffcore + The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the --pickaxe-all option, it can be used to view the full - changeset that introduced or removed, say, a + changeset that introduced or removed, say, a particular line of text. See . -plumbing +plumbing - Cute name for core git. + Cute name for core git. -porcelain +porcelain Cute name for programs and program suites depending on - core git, presenting a high level access to - core git. Porcelains expose more of a SCM - interface than the plumbing. + core git, presenting a high level access to + core git. Porcelains expose more of a SCM + interface than the plumbing. -pull +pull - Pulling a branch means to fetch it and - merge it. See also . + Pulling a branch means to fetch it and + merge it. See also . -push +push - Pushing a branch means to get the branch's - head ref from a remote repository, + Pushing a branch means to get the branch's + head ref from a remote repository, find out if it is a direct ancestor to the branch's local head ref, and in that case, putting all - objects, which are reachable from the local + objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote - object database, and updating the remote - head ref. If the remote head is not an + object database, and updating the remote + head ref. If the remote head is not an ancestor to the local head, the push fails. -reachable +reachable - All of the ancestors of a given commit are said to be + All of the ancestors of a given commit are said to be "reachable" from that commit. More - generally, one object is reachable from - another if we can reach the one from the other by a chain - that follows tags to whatever they tag, - commits to their parents or trees, and - trees to the trees or blobs + generally, one object is reachable from + another if we can reach the one from the other by a chain + that follows tags to whatever they tag, + commits to their parents or trees, and + trees to the trees or blobs that they contain. -rebase +rebase - To reapply a series of changes from a branch to a - different base, and reset the head of that branch + To reapply a series of changes from a branch to a + different base, and reset the head of that branch to the result. -ref +ref - A 40-byte hex representation of a SHA1 or a name that - denotes a particular object. They may be stored in + A 40-byte hex representation of a SHA1 or a name that + denotes a particular object. They may be stored in a file under $GIT_DIR/refs/ directory, or in the $GIT_DIR/packed-refs file. @@ -4000,7 +4006,7 @@ should not be combined with other pathspec. -reflog +reflog @@ -4013,17 +4019,17 @@ should not be combined with other pathspec. -refspec +refspec - A "refspec" is used by fetch and - push to describe the mapping between remote - ref and local ref. They are combined with a colon in + A "refspec" is used by fetch and + push to describe the mapping between remote + ref and local ref. They are combined with a colon in the format <src>:<dst>, preceded by an optional plus sign, +. For example: git fetch $URL refs/heads/master:refs/heads/origin means "grab the master - branch head from the $URL and store + 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 branch at $URL". See also @@ -4033,71 +4039,71 @@ should not be combined with other pathspec. -remote-tracking branch +remote-tracking branch - A regular git branch that is used to follow changes from - another repository. A remote-tracking + A regular git branch that is used to follow changes from + another repository. A remote-tracking branch should not contain direct modifications or have local commits made to it. A remote-tracking branch can usually be - identified as the right-hand-side ref in a Pull: - refspec. + identified as the right-hand-side ref in a Pull: + refspec. -repository +repository - A collection of refs together with an - object database containing all objects - which are reachable from the refs, possibly - accompanied by meta data from one or more porcelains. A + A collection of refs together with an + object database containing all objects + which are reachable from the refs, possibly + accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories - via alternates mechanism. + via alternates mechanism. -resolve +resolve The action of fixing up manually what a failed automatic - merge left behind. + merge left behind. -revision +revision A particular state of files and directories which was stored in the - object database. It is referenced by a - commit object. + object database. It is referenced by a + commit object. -rewind +rewind To throw away part of the development, i.e. to assign the - head to an earlier revision. + head to an earlier revision. -SCM +SCM @@ -4107,24 +4113,24 @@ should not be combined with other pathspec. -SHA1 +SHA1 - Synonym for object name. + Synonym for object name. -shallow repository +shallow repository - A shallow repository has an incomplete - history some of whose commits have parents cauterized away (in other + 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 + 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 the --depth option to , and @@ -4134,14 +4140,14 @@ should not be combined with other pathspec. -symref +symref - Symbolic reference: instead of containing the SHA1 + Symbolic reference: instead of containing the SHA1 id itself, it is of the format ref: refs/some/thing and when referenced, it recursively dereferences to this reference. - HEAD is a prime example of a symref. Symbolic + HEAD is a prime example of a symref. Symbolic references are manipulated with the command. @@ -4149,41 +4155,41 @@ should not be combined with other pathspec. -tag +tag - A ref under refs/tags/ namespace that points to an + A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a - tag or a commit object). - In contrast to a head, a tag is not updated by + tag or a commit object). + In contrast to a head, a tag is not updated by the commit command. A git tag has nothing to do with a Lisp - tag (which would be called an object type + tag (which would be called an object type in git's context). A tag is most typically used to mark a particular - point in the commit ancestry chain. + point in the commit ancestry chain. -tag object +tag object - An object containing a ref pointing to + An object containing a ref pointing to another object, which can contain a message just like a - commit object. It can also contain a (PGP) + commit object. It can also contain a (PGP) signature, in which case it is called a "signed tag object". -topic branch +topic branch - A regular git branch that is used by a developer to + A regular git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet @@ -4193,66 +4199,66 @@ should not be combined with other pathspec. -tree +tree - Either a working tree, or a tree object together with the dependent blob and tree objects + Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree). -tree object +tree object - An object containing a list of file names and modes along + An object containing a list of file names and modes along with refs to the associated blob and/or tree objects. A - tree is equivalent to a directory. + tree is equivalent to a directory. -tree-ish +tree-ish - A ref pointing to either a commit object, a tree object, or a tag object pointing to a tag or commit or tree object. + A ref pointing to either a commit object, a tree object, or a tag object pointing to a tag or commit or tree object. -unmerged index +unmerged index - An index which contains unmerged - index entries. + An index which contains unmerged + index entries. -unreachable object +unreachable object - An object which is not reachable from a - branch, tag, or any other reference. + An object which is not reachable from a + branch, tag, or any other reference. -upstream branch +upstream branch - The default branch that is merged into the branch in + The default branch that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of A is origin/B sometimes we say "A is tracking origin/B". @@ -4261,23 +4267,23 @@ should not be combined with other pathspec. -working tree +working tree The tree of actual checked out files. The working tree normally - contains the contents of the HEAD commit's tree, + contains the contents of the HEAD commit's tree, plus any local changes that you have made but not yet committed.
- + Git Quick Reference This is a quick summary of the major commands; the previous chapters explain how these work in more detail. -
+
Creating a new repository From a tarball: $ tar xzf project.tar.gz @@ -4290,7 +4296,7 @@ $ git commit $ git clone git://example.com/pub/project.git $ cd project
-
+
Managing branches $ git branch # list all local branches in this repo $ git checkout test # switch working directory to branch "test" @@ -4330,7 +4336,7 @@ $ git remote show example # get details $ 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 @@ -4358,7 +4364,7 @@ $ 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 @@ -4376,14 +4382,14 @@ $ git commit $ 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 @@ -4404,15 +4410,15 @@ branch with your commits: $ 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
- - + + Notes and todo list for this manual This is a work in progress. The basic requirements: @@ -4479,5 +4485,5 @@ CVS, Subversion, and just imports of series of release tarballs. More on recovery from repository corruption. See: http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2 http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2 - -
+ + -- 2.11.4.GIT