From 1a4e841b439ba014b365999c3a6b9e2be3740bd8 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 27 Dec 2005 00:17:23 -0800 Subject: [PATCH] Autogenerated HTML docs for 36de72aa9dc3b7daf8cf2770c840f39bb0d2ae70 --- cvs-migration.html | 525 ++++++++ cvs-migration.txt | 248 ++++ diff-format.txt | 148 +++ diff-options.txt | 70 ++ diffcore.html | 554 +++++++++ diffcore.txt | 275 +++++ everyday.html | 815 +++++++++++++ everyday.txt | 441 +++++++ fetch-options.txt | 24 + git-add.html | 378 ++++++ git-add.txt | 75 ++ git-am.html | 414 +++++++ git-am.txt | 96 ++ git-apply.html | 433 +++++++ git-apply.txt | 104 ++ git-applymbox.html | 398 ++++++ git-applymbox.txt | 92 ++ git-applypatch.html | 336 ++++++ git-applypatch.txt | 50 + git-archimport.html | 417 +++++++ git-archimport.txt | 106 ++ git-bisect.html | 392 ++++++ git-bisect.txt | 136 +++ git-branch.html | 371 ++++++ git-branch.txt | 72 ++ git-cat-file.html | 362 ++++++ git-cat-file.txt | 67 ++ git-check-ref-format.html | 347 ++++++ git-check-ref-format.txt | 52 + git-checkout-index.html | 437 +++++++ git-checkout-index.txt | 121 ++ git-checkout.html | 371 ++++++ git-checkout.txt | 83 ++ git-cherry-pick.html | 353 ++++++ git-cherry-pick.txt | 60 + git-cherry.html | 332 +++++ git-cherry.txt | 42 + git-clone-pack.html | 356 ++++++ git-clone-pack.txt | 64 + git-clone.html | 441 +++++++ git-clone.txt | 117 ++ git-commit-tree.html | 409 +++++++ git-commit-tree.txt | 99 ++ git-commit.html | 402 +++++++ git-commit.txt | 81 ++ git-convert-objects.html | 299 +++++ git-convert-objects.txt | 29 + git-count-objects.html | 300 +++++ git-count-objects.txt | 28 + git-cvsexportcommit.html | 339 ++++++ git-cvsexportcommit.txt | 56 + git-cvsimport.html | 455 +++++++ git-cvsimport.txt | 112 ++ git-daemon.html | 400 ++++++ git-daemon.txt | 83 ++ git-diff-files.html | 743 ++++++++++++ git-diff-files.txt | 52 + git-diff-index.html | 844 +++++++++++++ git-diff-index.txt | 133 ++ git-diff-stages.html | 728 +++++++++++ git-diff-stages.txt | 40 + git-diff-tree.html | 873 ++++++++++++++ git-diff-tree.txt | 141 +++ git-diff.html | 422 +++++++ git-diff.txt | 116 ++ git-fetch-pack.html | 375 ++++++ git-fetch-pack.txt | 73 ++ git-fetch.html | 586 +++++++++ git-fetch.txt | 48 + git-fmt-merge-msg.html | 307 +++++ git-fmt-merge-msg.txt | 39 + git-format-patch.html | 437 +++++++ git-format-patch.txt | 113 ++ git-fsck-objects.html | 508 ++++++++ git-fsck-objects.txt | 144 +++ git-get-tar-commit-id.html | 305 +++++ git-get-tar-commit-id.txt | 37 + git-grep.html | 332 +++++ git-grep.txt | 46 + git-hash-object.html | 334 +++++ git-hash-object.txt | 46 + git-http-fetch.html | 354 ++++++ git-http-fetch.txt | 47 + git-http-push.html | 386 ++++++ git-http-push.txt | 89 ++ git-index-pack.html | 320 +++++ git-index-pack.txt | 44 + git-init-db.html | 339 ++++++ git-init-db.txt | 62 + git-local-fetch.html | 345 ++++++ git-local-fetch.txt | 43 + git-log.html | 363 ++++++ git-log.txt | 62 + git-lost-found.html | 345 ++++++ git-lost-found.txt | 78 ++ git-ls-files.html | 631 ++++++++++ git-ls-files.txt | 220 ++++ git-ls-remote.html | 353 ++++++ git-ls-remote.txt | 63 + git-ls-tree.html | 383 ++++++ git-ls-tree.txt | 73 ++ git-mailinfo.html | 367 ++++++ git-mailinfo.txt | 72 ++ git-mailsplit.html | 351 ++++++ git-mailsplit.txt | 52 + git-merge-base.html | 302 +++++ git-merge-base.txt | 33 + git-merge-index.html | 379 ++++++ git-merge-index.txt | 88 ++ git-merge-one-file.html | 301 +++++ git-merge-one-file.txt | 30 + git-merge.html | 560 +++++++++ git-merge.txt | 158 +++ git-mktag.html | 316 +++++ git-mktag.txt | 47 + git-mv.html | 344 ++++++ git-mv.txt | 54 + git-name-rev.html | 348 ++++++ git-name-rev.txt | 66 + git-pack-objects.html | 392 ++++++ git-pack-objects.txt | 93 ++ git-pack-redundant.html | 342 ++++++ git-pack-redundant.txt | 58 + git-parse-remote.html | 331 +++++ git-parse-remote.txt | 48 + git-patch-id.html | 321 +++++ git-patch-id.txt | 43 + git-peek-remote.html | 340 ++++++ git-peek-remote.txt | 52 + git-prune-packed.html | 324 +++++ git-prune-packed.txt | 51 + git-prune.html | 347 ++++++ git-prune.txt | 61 + git-pull.html | 774 ++++++++++++ git-pull.txt | 131 ++ git-push.html | 556 +++++++++ git-push.txt | 50 + git-read-tree.html | 625 ++++++++++ git-read-tree.txt | 310 +++++ git-rebase.html | 320 +++++ git-rebase.txt | 35 + git-receive-pack.html | 373 ++++++ git-receive-pack.txt | 99 ++ git-relink.html | 322 +++++ git-relink.txt | 37 + git-repack.html | 355 ++++++ git-repack.txt | 66 + git-repo-config.html | 483 ++++++++ git-repo-config.txt | 170 +++ git-request-pull.html | 329 +++++ git-request-pull.txt | 40 + git-reset.html | 467 +++++++ git-reset.txt | 159 +++ git-resolve.html | 305 +++++ git-resolve.txt | 36 + git-rev-list.html | 480 ++++++++ git-rev-list.txt | 150 +++ git-rev-parse.html | 543 +++++++++ git-rev-parse.txt | 179 +++ git-revert.html | 350 ++++++ git-revert.txt | 57 + git-send-email.html | 383 ++++++ git-send-email.txt | 80 ++ git-send-pack.html | 417 +++++++ git-send-pack.txt | 110 ++ git-sh-setup.html | 306 +++++ git-sh-setup.txt | 35 + git-shell.html | 305 +++++ git-shell.txt | 35 + git-shortlog.html | 300 +++++ git-shortlog.txt | 30 + git-show-branch.html | 445 +++++++ git-show-branch.txt | 130 ++ git-show-index.html | 303 +++++ git-show-index.txt | 35 + git-ssh-fetch.html | 356 ++++++ git-ssh-fetch.txt | 51 + git-ssh-upload.html | 355 ++++++ git-ssh-upload.txt | 47 + git-status.html | 313 +++++ git-status.txt | 45 + git-stripspace.html | 312 +++++ git-stripspace.txt | 33 + git-svnimport.html | 490 ++++++++ git-svnimport.txt | 134 +++ git-symbolic-ref.html | 321 +++++ git-symbolic-ref.txt | 52 + git-tag.html | 366 ++++++ git-tag.txt | 67 ++ git-tar-tree.html | 307 +++++ git-tar-tree.txt | 38 + git-unpack-file.html | 314 +++++ git-unpack-file.txt | 36 + git-unpack-objects.html | 324 +++++ git-unpack-objects.txt | 42 + git-update-index.html | 584 +++++++++ git-update-index.txt | 233 ++++ git-update-ref.html | 329 +++++ git-update-ref.txt | 58 + git-update-server-info.html | 339 ++++++ git-update-server-info.txt | 58 + git-upload-pack.html | 317 +++++ git-upload-pack.txt | 39 + git-var.html | 375 ++++++ git-var.txt | 61 + git-verify-pack.html | 345 ++++++ git-verify-pack.txt | 54 + git-verify-tag.html | 312 +++++ git-verify-tag.txt | 32 + git-whatchanged.html | 394 ++++++ git-whatchanged.txt | 81 ++ git-write-tree.html | 320 +++++ git-write-tree.txt | 44 + git.html | 2021 +++++++++++++++++++++++++++++++ git.txt | 603 ++++++++++ gitk.html | 344 ++++++ gitk.txt | 51 + glossary.html | 807 +++++++++++++ glossary.txt | 242 ++++ hooks.html | 382 ++++++ hooks.txt | 135 +++ howto-index.html | 359 ++++++ howto-index.txt | 65 + howto/isolate-bugs-with-bisect.txt | 65 + howto/make-dist.txt | 52 + howto/rebase-and-edit.txt | 81 ++ howto/rebase-from-internal-branch.txt | 165 +++ howto/rebuild-from-update-hook.txt | 87 ++ howto/revert-branch-rebase.html | 447 +++++++ howto/revert-branch-rebase.txt | 200 +++ howto/update-hook-example.txt | 172 +++ howto/using-topic-branches.txt | 288 +++++ index.html | 1 + merge-options.txt | 16 + merge-strategies.txt | 35 + pull-fetch-param.txt | 144 +++ repository-layout.html | 500 ++++++++ repository-layout.txt | 128 ++ tutorial.html | 2143 +++++++++++++++++++++++++++++++++ tutorial.txt | 1820 ++++++++++++++++++++++++++++ 240 files changed, 62806 insertions(+) create mode 100644 cvs-migration.html create mode 100644 cvs-migration.txt create mode 100644 diff-format.txt create mode 100644 diff-options.txt create mode 100644 diffcore.html create mode 100644 diffcore.txt create mode 100644 everyday.html create mode 100644 everyday.txt create mode 100644 fetch-options.txt create mode 100644 git-add.html create mode 100644 git-add.txt create mode 100644 git-am.html create mode 100644 git-am.txt create mode 100644 git-apply.html create mode 100644 git-apply.txt create mode 100644 git-applymbox.html create mode 100644 git-applymbox.txt create mode 100644 git-applypatch.html create mode 100644 git-applypatch.txt create mode 100644 git-archimport.html create mode 100644 git-archimport.txt create mode 100644 git-bisect.html create mode 100644 git-bisect.txt create mode 100644 git-branch.html create mode 100644 git-branch.txt create mode 100644 git-cat-file.html create mode 100644 git-cat-file.txt create mode 100644 git-check-ref-format.html create mode 100644 git-check-ref-format.txt create mode 100644 git-checkout-index.html create mode 100644 git-checkout-index.txt create mode 100644 git-checkout.html create mode 100644 git-checkout.txt create mode 100644 git-cherry-pick.html create mode 100644 git-cherry-pick.txt create mode 100644 git-cherry.html create mode 100644 git-cherry.txt create mode 100644 git-clone-pack.html create mode 100644 git-clone-pack.txt create mode 100644 git-clone.html create mode 100644 git-clone.txt create mode 100644 git-commit-tree.html create mode 100644 git-commit-tree.txt create mode 100644 git-commit.html create mode 100644 git-commit.txt create mode 100644 git-convert-objects.html create mode 100644 git-convert-objects.txt create mode 100644 git-count-objects.html create mode 100644 git-count-objects.txt create mode 100644 git-cvsexportcommit.html create mode 100644 git-cvsexportcommit.txt create mode 100644 git-cvsimport.html create mode 100644 git-cvsimport.txt create mode 100644 git-daemon.html create mode 100644 git-daemon.txt create mode 100644 git-diff-files.html create mode 100644 git-diff-files.txt create mode 100644 git-diff-index.html create mode 100644 git-diff-index.txt create mode 100644 git-diff-stages.html create mode 100644 git-diff-stages.txt create mode 100644 git-diff-tree.html create mode 100644 git-diff-tree.txt create mode 100644 git-diff.html create mode 100644 git-diff.txt create mode 100644 git-fetch-pack.html create mode 100644 git-fetch-pack.txt create mode 100644 git-fetch.html create mode 100644 git-fetch.txt create mode 100644 git-fmt-merge-msg.html create mode 100644 git-fmt-merge-msg.txt create mode 100644 git-format-patch.html create mode 100644 git-format-patch.txt create mode 100644 git-fsck-objects.html create mode 100644 git-fsck-objects.txt create mode 100644 git-get-tar-commit-id.html create mode 100644 git-get-tar-commit-id.txt create mode 100644 git-grep.html create mode 100644 git-grep.txt create mode 100644 git-hash-object.html create mode 100644 git-hash-object.txt create mode 100644 git-http-fetch.html create mode 100644 git-http-fetch.txt create mode 100644 git-http-push.html create mode 100644 git-http-push.txt create mode 100644 git-index-pack.html create mode 100644 git-index-pack.txt create mode 100644 git-init-db.html create mode 100644 git-init-db.txt create mode 100644 git-local-fetch.html create mode 100644 git-local-fetch.txt create mode 100644 git-log.html create mode 100644 git-log.txt create mode 100644 git-lost-found.html create mode 100644 git-lost-found.txt create mode 100644 git-ls-files.html create mode 100644 git-ls-files.txt create mode 100644 git-ls-remote.html create mode 100644 git-ls-remote.txt create mode 100644 git-ls-tree.html create mode 100644 git-ls-tree.txt create mode 100644 git-mailinfo.html create mode 100644 git-mailinfo.txt create mode 100644 git-mailsplit.html create mode 100644 git-mailsplit.txt create mode 100644 git-merge-base.html create mode 100644 git-merge-base.txt create mode 100644 git-merge-index.html create mode 100644 git-merge-index.txt create mode 100644 git-merge-one-file.html create mode 100644 git-merge-one-file.txt create mode 100644 git-merge.html create mode 100644 git-merge.txt create mode 100644 git-mktag.html create mode 100644 git-mktag.txt create mode 100644 git-mv.html create mode 100644 git-mv.txt create mode 100644 git-name-rev.html create mode 100644 git-name-rev.txt create mode 100644 git-pack-objects.html create mode 100644 git-pack-objects.txt create mode 100644 git-pack-redundant.html create mode 100644 git-pack-redundant.txt create mode 100644 git-parse-remote.html create mode 100644 git-parse-remote.txt create mode 100644 git-patch-id.html create mode 100644 git-patch-id.txt create mode 100644 git-peek-remote.html create mode 100644 git-peek-remote.txt create mode 100644 git-prune-packed.html create mode 100644 git-prune-packed.txt create mode 100644 git-prune.html create mode 100644 git-prune.txt create mode 100644 git-pull.html create mode 100644 git-pull.txt create mode 100644 git-push.html create mode 100644 git-push.txt create mode 100644 git-read-tree.html create mode 100644 git-read-tree.txt create mode 100644 git-rebase.html create mode 100644 git-rebase.txt create mode 100644 git-receive-pack.html create mode 100644 git-receive-pack.txt create mode 100644 git-relink.html create mode 100644 git-relink.txt create mode 100644 git-repack.html create mode 100644 git-repack.txt create mode 100644 git-repo-config.html create mode 100644 git-repo-config.txt create mode 100644 git-request-pull.html create mode 100644 git-request-pull.txt create mode 100644 git-reset.html create mode 100644 git-reset.txt create mode 100644 git-resolve.html create mode 100644 git-resolve.txt create mode 100644 git-rev-list.html create mode 100644 git-rev-list.txt create mode 100644 git-rev-parse.html create mode 100644 git-rev-parse.txt create mode 100644 git-revert.html create mode 100644 git-revert.txt create mode 100644 git-send-email.html create mode 100644 git-send-email.txt create mode 100644 git-send-pack.html create mode 100644 git-send-pack.txt create mode 100644 git-sh-setup.html create mode 100644 git-sh-setup.txt create mode 100644 git-shell.html create mode 100644 git-shell.txt create mode 100644 git-shortlog.html create mode 100644 git-shortlog.txt create mode 100644 git-show-branch.html create mode 100644 git-show-branch.txt create mode 100644 git-show-index.html create mode 100644 git-show-index.txt create mode 100644 git-ssh-fetch.html create mode 100644 git-ssh-fetch.txt create mode 100644 git-ssh-upload.html create mode 100644 git-ssh-upload.txt create mode 100644 git-status.html create mode 100644 git-status.txt create mode 100644 git-stripspace.html create mode 100644 git-stripspace.txt create mode 100644 git-svnimport.html create mode 100644 git-svnimport.txt create mode 100644 git-symbolic-ref.html create mode 100644 git-symbolic-ref.txt create mode 100644 git-tag.html create mode 100644 git-tag.txt create mode 100644 git-tar-tree.html create mode 100644 git-tar-tree.txt create mode 100644 git-unpack-file.html create mode 100644 git-unpack-file.txt create mode 100644 git-unpack-objects.html create mode 100644 git-unpack-objects.txt create mode 100644 git-update-index.html create mode 100644 git-update-index.txt create mode 100644 git-update-ref.html create mode 100644 git-update-ref.txt create mode 100644 git-update-server-info.html create mode 100644 git-update-server-info.txt create mode 100644 git-upload-pack.html create mode 100644 git-upload-pack.txt create mode 100644 git-var.html create mode 100644 git-var.txt create mode 100644 git-verify-pack.html create mode 100644 git-verify-pack.txt create mode 100644 git-verify-tag.html create mode 100644 git-verify-tag.txt create mode 100644 git-whatchanged.html create mode 100644 git-whatchanged.txt create mode 100644 git-write-tree.html create mode 100644 git-write-tree.txt create mode 100644 git.html create mode 100644 git.txt create mode 100644 gitk.html create mode 100644 gitk.txt create mode 100644 glossary.html create mode 100644 glossary.txt create mode 100644 hooks.html create mode 100644 hooks.txt create mode 100644 howto-index.html create mode 100644 howto-index.txt create mode 100644 howto/isolate-bugs-with-bisect.txt create mode 100644 howto/make-dist.txt create mode 100644 howto/rebase-and-edit.txt create mode 100644 howto/rebase-from-internal-branch.txt create mode 100644 howto/rebuild-from-update-hook.txt create mode 100644 howto/revert-branch-rebase.html create mode 100644 howto/revert-branch-rebase.txt create mode 100644 howto/update-hook-example.txt create mode 100644 howto/using-topic-branches.txt create mode 120000 index.html create mode 100644 merge-options.txt create mode 100644 merge-strategies.txt create mode 100644 pull-fetch-param.txt create mode 100644 repository-layout.html create mode 100644 repository-layout.txt create mode 100644 tutorial.html create mode 100644 tutorial.txt diff --git a/cvs-migration.html b/cvs-migration.html new file mode 100644 index 00000000..d3ccbe14 --- /dev/null +++ b/cvs-migration.html @@ -0,0 +1,525 @@ + + + + + + +git for CVS users + + + +
+
+

Ok, so you're a CVS user. That's ok, it's a treatable condition, and the +first step to recovery is admitting you have a problem. The fact that +you are reading this file means that you may be well on that path +already.

+

The thing about CVS is that it absolutely sucks as a source control +manager, and you'll thus be happy with almost anything else. git, +however, may be a bit too different (read: "good") for your taste, and +does a lot of things differently.

+

One particular suckage of CVS is very hard to work around: CVS is +basically a tool for tracking file history, while git is a tool for +tracking project history. This sometimes causes problems if you are +used to doing very strange things in CVS, in particular if you're doing +things like making branches of just a subset of the project. git can't +track that, since git never tracks things on the level of an individual +file, only on the whole project level.

+

The good news is that most people don't do that, and in fact most sane +people think it's a bug in CVS that makes it tag (and check in changes) +one file at a time. So most projects you'll ever see will use CVS +as if it was sane. In which case you'll find it very easy indeed to +move over to git.

+

First off: this is not a git tutorial. See +Documentation/tutorial.txt for how git +actually works. This is more of a random collection of gotcha's +and notes on converting from CVS to git.

+

Second: CVS has the notion of a "repository" as opposed to the thing +that you're actually working in (your working directory, or your +"checked out tree"). git does not have that notion at all, and all git +working directories are the repositories. However, you can easily +emulate the CVS model by having one special "global repository", which +people can synchronize with. See details later, but in the meantime +just keep in mind that with git, every checked out working tree will +have a full revision control history of its own.

+
+
+

Importing a CVS archive

+
+

Ok, you have an old project, and you want to at least give git a chance +to see how it performs. The first thing you want to do (after you've +gone through the git tutorial, and generally familiarized yourself with +how to commit stuff etc in git) is to create a git'ified version of your +CVS archive.

+

Happily, that's very easy indeed. git will do it for you, although git +will need the help of a program called "cvsps":

+
+
+
http://www.cobite.com/cvsps/
+
+

which is not actually related to git at all, but which makes CVS usage +look almost sane (ie you almost certainly want to have it even if you +decide to stay with CVS). However, git will want at least version 2.1 +of cvsps (available at the address above), and in fact will currently +refuse to work with anything else.

+

Once you've gotten (and installed) cvsps, you may or may not want to get +any more familiar with it, but make sure it is in your path. After that, +the magic command line is

+
+
+
git cvsimport -v -d <cvsroot> -C <destination> <module>
+
+

which will do exactly what you'd think it does: it will create a git +archive of the named CVS module. The new archive will be created in the +subdirectory named <destination>; it'll be created if it doesn't exist. +Default is the local directory.

+

It can take some time to actually do the conversion for a large archive +since it involves checking out from CVS every revision of every file, +and the conversion script is reasonably chatty unless you omit the -v +option, but on some not very scientific tests it averaged about twenty +revisions per second, so a medium-sized project should not take more +than a couple of minutes. For larger projects or remote repositories, +the process may take longer.

+

After the (initial) import is done, the CVS archive's current head +revision will be checked out — thus, you can start adding your own +changes right away.

+

The import is incremental, i.e. if you call it again next month it'll +fetch any CVS updates that have been happening in the meantime. The +cut-off is date-based, so don't change the branches that were imported +from CVS.

+

You can merge those updates (or, in fact, a different CVS branch) into +your main branch:

+
+
+
git resolve HEAD origin "merge with current CVS HEAD"
+
+

The HEAD revision from CVS is named "origin", not "HEAD", because git +already uses "HEAD". (If you don't like origin, use cvsimport's +-o option to change it.)

+
+

Emulating CVS behaviour

+
+

So, by now you are convinced you absolutely want to work with git, but +at the same time you absolutely have to have a central repository. +Step back and think again. Okay, you still need a single central +repository? There are several ways to go about that:

+
    +
  1. +

    +Designate a person responsible to pull all branches. Make the +repository of this person public, and make every team member +pull regularly from it. +

    +
    2. +
  2. +

    +Set up a public repository with read/write access for every team +member. Use "git pull/push" as you used "cvs update/commit". Be +sure that your repository is up to date before pushing, just +like you used to do with "cvs commit"; your push will fail if +what you are pushing is not up to date. +

    +
    3. +
  3. +

    +Make the repository of every team member public. It is the +responsibility of each single member to pull from every other +team member. +

    +
    4. +
+
+

CVS annotate

+
+

So, something has gone wrong, and you don't know whom to blame, and +you're an ex-CVS user and used to do "cvs annotate" to see who caused +the breakage. You're looking for the "git annotate", and it's just +claiming not to find such a script. You're annoyed.

+

Yes, that's right. Core git doesn't do "annotate", although it's +technically possible, and there are at least two specialized scripts out +there that can be used to get equivalent information (see the git +mailing list archives for details).

+

git has a couple of alternatives, though, that you may find sufficient +or even superior depending on your use. One is called "git-whatchanged" +(for obvious reasons) and the other one is called "pickaxe" ("a tool for +the software archeologist").

+

The "git-whatchanged" script is a truly trivial script that can give you +a good overview of what has changed in a file or a directory (or an +arbitrary list of files or directories). The "pickaxe" support is an +additional layer that can be used to further specify exactly what you're +looking for, if you already know the specific area that changed.

+

Let's step back a bit and think about the reason why you would +want to do "cvs annotate a-file.c" to begin with.

+

You would use "cvs annotate" on a file when you have trouble +with a function (or even a single "if" statement in a function) +that happens to be defined in the file, which does not do what +you want it to do. And you would want to find out why it was +written that way, because you are about to modify it to suit +your needs, and at the same time you do not want to break its +current callers. For that, you are trying to find out why the +original author did things that way in the original context.

+

Many times, it may be enough to see the commit log messages of +commits that touch the file in question, possibly along with the +patches themselves, like this:

+
+
+
$ git-whatchanged -p a-file.c
+
+

This will show log messages and patches for each commit that +touches a-file.

+

This, however, may not be very useful when this file has many +modifications that are not related to the piece of code you are +interested in. You would see many log messages and patches that +do not have anything to do with the piece of code you are +interested in. As an example, assuming that you have this piece +of code that you are interested in in the HEAD version:

+
+
+
if (frotz) {
+        nitfol();
+}
+
+

you would use git-rev-list and git-diff-tree like this:

+
+
+
$ git-rev-list HEAD |
+  git-diff-tree --stdin -v -p -S'if (frotz) {
+        nitfol();
+}'
+
+

We have already talked about the "--stdin" form of git-diff-tree +command that reads the list of commits and compares each commit +with its parents (otherwise you should go back and read the tutorial). +The git-whatchanged command internally runs +the equivalent of the above command, and can be used like this:

+
+
+
$ git-whatchanged -p -S'if (frotz) {
+        nitfol();
+}'
+
+

When the -S option is used, git-diff-tree command outputs +differences between two commits only if one tree has the +specified string in a file and the corresponding file in the +other tree does not. The above example looks for a commit that +has the "if" statement in it in a file, but its parent commit +does not have it in the same shape in the corresponding file (or +the other way around, where the parent has it and the commit +does not), and the differences between them are shown, along +with the commit message (thanks to the -v flag). It does not +show anything for commits that do not touch this "if" statement.

+

Also, in the original context, the same statement might have +appeared at first in a different file and later the file was +renamed to "a-file.c". CVS annotate would not help you to go +back across such a rename, but git would still help you in such +a situation. For that, you can give the -C flag to +git-diff-tree, like this:

+
+
+
$ git-whatchanged -p -C -S'if (frotz) {
+        nitfol();
+}'
+
+

When the -C flag is used, file renames and copies are followed. +So if the "if" statement in question happens to be in "a-file.c" +in the current HEAD commit, even if the file was originally +called "o-file.c" and then renamed in an earlier commit, or if +the file was created by copying an existing "o-file.c" in an +earlier commit, you will not lose track. If the "if" statement +did not change across such a rename or copy, then the commit that +does rename or copy would not show in the output, and if the +"if" statement was modified while the file was still called +"o-file.c", it would find the commit that changed the statement +when it was in "o-file.c".

+
+ + + +
+
Note
+		The current version of "git-diff-tree -C" is not eager + enough to find copies, and it will miss the fact that a-file.c + was created by copying o-file.c unless o-file.c was somehow + changed in the same commit.
+
+

You can use the —pickaxe-all flag in addition to the -S flag. +This causes the differences from all the files contained in +those two commits, not just the differences between the files +that contain this changed "if" statement:

+
+
+
$ git-whatchanged -p -C -S'if (frotz) {
+        nitfol();
+}' --pickaxe-all
+
+
+ + + +
+
Note
+		This option is called "—pickaxe-all" because -S + option is internally called "pickaxe", a tool for software + archaeologists.
+
+
+ + + diff --git a/cvs-migration.txt b/cvs-migration.txt new file mode 100644 index 00000000..dc9387b6 --- /dev/null +++ b/cvs-migration.txt @@ -0,0 +1,248 @@ +git for CVS users +================= + +Ok, so you're a CVS user. That's ok, it's a treatable condition, and the +first step to recovery is admitting you have a problem. The fact that +you are reading this file means that you may be well on that path +already. + +The thing about CVS is that it absolutely sucks as a source control +manager, and you'll thus be happy with almost anything else. git, +however, may be a bit 'too' different (read: "good") for your taste, and +does a lot of things differently. + +One particular suckage of CVS is very hard to work around: CVS is +basically a tool for tracking 'file' history, while git is a tool for +tracking 'project' history. This sometimes causes problems if you are +used to doing very strange things in CVS, in particular if you're doing +things like making branches of just a subset of the project. git can't +track that, since git never tracks things on the level of an individual +file, only on the whole project level. + +The good news is that most people don't do that, and in fact most sane +people think it's a bug in CVS that makes it tag (and check in changes) +one file at a time. So most projects you'll ever see will use CVS +'as if' it was sane. In which case you'll find it very easy indeed to +move over to git. + +First off: this is not a git tutorial. See +link:tutorial.html[Documentation/tutorial.txt] for how git +actually works. This is more of a random collection of gotcha's +and notes on converting from CVS to git. + +Second: CVS has the notion of a "repository" as opposed to the thing +that you're actually working in (your working directory, or your +"checked out tree"). git does not have that notion at all, and all git +working directories 'are' the repositories. However, you can easily +emulate the CVS model by having one special "global repository", which +people can synchronize with. See details later, but in the meantime +just keep in mind that with git, every checked out working tree will +have a full revision control history of its own. + + +Importing a CVS archive +----------------------- + +Ok, you have an old project, and you want to at least give git a chance +to see how it performs. The first thing you want to do (after you've +gone through the git tutorial, and generally familiarized yourself with +how to commit stuff etc in git) is to create a git'ified version of your +CVS archive. + +Happily, that's very easy indeed. git will do it for you, although git +will need the help of a program called "cvsps": + + http://www.cobite.com/cvsps/ + +which is not actually related to git at all, but which makes CVS usage +look almost sane (ie you almost certainly want to have it even if you +decide to stay with CVS). However, git will want 'at least' version 2.1 +of cvsps (available at the address above), and in fact will currently +refuse to work with anything else. + +Once you've gotten (and installed) cvsps, you may or may not want to get +any more familiar with it, but make sure it is in your path. After that, +the magic command line is + + git cvsimport -v -d -C + +which will do exactly what you'd think it does: it will create a git +archive of the named CVS module. The new archive will be created in the +subdirectory named ; it'll be created if it doesn't exist. +Default is the local directory. + +It can take some time to actually do the conversion for a large archive +since it involves checking out from CVS every revision of every file, +and the conversion script is reasonably chatty unless you omit the '-v' +option, but on some not very scientific tests it averaged about twenty +revisions per second, so a medium-sized project should not take more +than a couple of minutes. For larger projects or remote repositories, +the process may take longer. + +After the (initial) import is done, the CVS archive's current head +revision will be checked out -- thus, you can start adding your own +changes right away. + +The import is incremental, i.e. if you call it again next month it'll +fetch any CVS updates that have been happening in the meantime. The +cut-off is date-based, so don't change the branches that were imported +from CVS. + +You can merge those updates (or, in fact, a different CVS branch) into +your main branch: + + git resolve HEAD origin "merge with current CVS HEAD" + +The HEAD revision from CVS is named "origin", not "HEAD", because git +already uses "HEAD". (If you don't like 'origin', use cvsimport's +'-o' option to change it.) + + +Emulating CVS behaviour +----------------------- + + +So, by now you are convinced you absolutely want to work with git, but +at the same time you absolutely have to have a central repository. +Step back and think again. Okay, you still need a single central +repository? There are several ways to go about that: + +1. Designate a person responsible to pull all branches. Make the +repository of this person public, and make every team member +pull regularly from it. + +2. Set up a public repository with read/write access for every team +member. Use "git pull/push" as you used "cvs update/commit". Be +sure that your repository is up to date before pushing, just +like you used to do with "cvs commit"; your push will fail if +what you are pushing is not up to date. + +3. Make the repository of every team member public. It is the +responsibility of each single member to pull from every other +team member. + + +CVS annotate +------------ + +So, something has gone wrong, and you don't know whom to blame, and +you're an ex-CVS user and used to do "cvs annotate" to see who caused +the breakage. You're looking for the "git annotate", and it's just +claiming not to find such a script. You're annoyed. + +Yes, that's right. Core git doesn't do "annotate", although it's +technically possible, and there are at least two specialized scripts out +there that can be used to get equivalent information (see the git +mailing list archives for details). + +git has a couple of alternatives, though, that you may find sufficient +or even superior depending on your use. One is called "git-whatchanged" +(for obvious reasons) and the other one is called "pickaxe" ("a tool for +the software archeologist"). + +The "git-whatchanged" script is a truly trivial script that can give you +a good overview of what has changed in a file or a directory (or an +arbitrary list of files or directories). The "pickaxe" support is an +additional layer that can be used to further specify exactly what you're +looking for, if you already know the specific area that changed. + +Let's step back a bit and think about the reason why you would +want to do "cvs annotate a-file.c" to begin with. + +You would use "cvs annotate" on a file when you have trouble +with a function (or even a single "if" statement in a function) +that happens to be defined in the file, which does not do what +you want it to do. And you would want to find out why it was +written that way, because you are about to modify it to suit +your needs, and at the same time you do not want to break its +current callers. For that, you are trying to find out why the +original author did things that way in the original context. + +Many times, it may be enough to see the commit log messages of +commits that touch the file in question, possibly along with the +patches themselves, like this: + + $ git-whatchanged -p a-file.c + +This will show log messages and patches for each commit that +touches a-file. + +This, however, may not be very useful when this file has many +modifications that are not related to the piece of code you are +interested in. You would see many log messages and patches that +do not have anything to do with the piece of code you are +interested in. As an example, assuming that you have this piece +of code that you are interested in in the HEAD version: + + if (frotz) { + nitfol(); + } + +you would use git-rev-list and git-diff-tree like this: + + $ git-rev-list HEAD | + git-diff-tree --stdin -v -p -S'if (frotz) { + nitfol(); + }' + +We have already talked about the "\--stdin" form of git-diff-tree +command that reads the list of commits and compares each commit +with its parents (otherwise you should go back and read the tutorial). +The git-whatchanged command internally runs +the equivalent of the above command, and can be used like this: + + $ git-whatchanged -p -S'if (frotz) { + nitfol(); + }' + +When the -S option is used, git-diff-tree command outputs +differences between two commits only if one tree has the +specified string in a file and the corresponding file in the +other tree does not. The above example looks for a commit that +has the "if" statement in it in a file, but its parent commit +does not have it in the same shape in the corresponding file (or +the other way around, where the parent has it and the commit +does not), and the differences between them are shown, along +with the commit message (thanks to the -v flag). It does not +show anything for commits that do not touch this "if" statement. + +Also, in the original context, the same statement might have +appeared at first in a different file and later the file was +renamed to "a-file.c". CVS annotate would not help you to go +back across such a rename, but git would still help you in such +a situation. For that, you can give the -C flag to +git-diff-tree, like this: + + $ git-whatchanged -p -C -S'if (frotz) { + nitfol(); + }' + +When the -C flag is used, file renames and copies are followed. +So if the "if" statement in question happens to be in "a-file.c" +in the current HEAD commit, even if the file was originally +called "o-file.c" and then renamed in an earlier commit, or if +the file was created by copying an existing "o-file.c" in an +earlier commit, you will not lose track. If the "if" statement +did not change across such a rename or copy, then the commit that +does rename or copy would not show in the output, and if the +"if" statement was modified while the file was still called +"o-file.c", it would find the commit that changed the statement +when it was in "o-file.c". + +NOTE: The current version of "git-diff-tree -C" is not eager + enough to find copies, and it will miss the fact that a-file.c + was created by copying o-file.c unless o-file.c was somehow + changed in the same commit. + +You can use the --pickaxe-all flag in addition to the -S flag. +This causes the differences from all the files contained in +those two commits, not just the differences between the files +that contain this changed "if" statement: + + $ git-whatchanged -p -C -S'if (frotz) { + nitfol(); + }' --pickaxe-all + +NOTE: This option is called "--pickaxe-all" because -S + option is internally called "pickaxe", a tool for software + archaeologists. diff --git a/diff-format.txt b/diff-format.txt new file mode 100644 index 00000000..97756ec0 --- /dev/null +++ b/diff-format.txt @@ -0,0 +1,148 @@ +The output format from "git-diff-index", "git-diff-tree" and +"git-diff-files" are very similar. + +These commands all compare two sets of things; what is +compared differs: + +git-diff-index :: + compares the and the files on the filesystem. + +git-diff-index --cached :: + compares the and the index. + +git-diff-tree [-r] [...]:: + compares the trees named by the two arguments. + +git-diff-files [...]:: + compares the index and the files on the filesystem. + + +An output line is formatted this way: + +------------------------------------------------ +in-place edit :100644 100644 bcd1234... 0123456... M file0 +copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2 +rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3 +create :000000 100644 0000000... 1234567... A file4 +delete :100644 000000 1234567... 0000000... D file5 +unmerged :000000 000000 0000000... 0000000... U file6 +------------------------------------------------ + +That is, from the left to the right: + +. a colon. +. mode for "src"; 000000 if creation or unmerged. +. a space. +. mode for "dst"; 000000 if deletion or unmerged. +. a space. +. sha1 for "src"; 0\{40\} if creation or unmerged. +. a space. +. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree". +. a space. +. status, followed by optional "score" number. +. a tab or a NUL when '-z' option is used. +. path for "src" +. a tab or a NUL when '-z' option is used; only exists for C or R. +. path for "dst"; only exists for C or R. +. an LF or a NUL when '-z' option is used, to terminate the record. + + is shown as all 0's if a file is new on the filesystem +and it is out of sync with the index. + +Example: + +------------------------------------------------ +:100644 100644 5be4a4...... 000000...... M file.c +------------------------------------------------ + +When `-z` option is not used, TAB, LF, and backslash characters +in pathnames are represented as `\t`, `\n`, and `\\`, +respectively. + + +Generating patches with -p +-------------------------- + +When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a '-p' option, they do not produce the output described above; +instead they produce a patch file. + +The patch generation can be customized at two levels. + +1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set, + these commands internally invoke "diff" like this: + + diff -L a/ -L b/ -pu ++ +For added files, `/dev/null` is used for . For removed +files, `/dev/null` is used for ++ +The "diff" formatting options can be customized via the +environment variable 'GIT_DIFF_OPTS'. For example, if you +prefer context diff: + + GIT_DIFF_OPTS=-c git-diff-index -p HEAD + + +2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the + program named by it is called, instead of the diff invocation + described above. ++ +For a path that is added, removed, or modified, +'GIT_EXTERNAL_DIFF' is called with 7 parameters: + + path old-file old-hex old-mode new-file new-hex new-mode ++ +where: + + -file:: are files GIT_EXTERNAL_DIFF can use to read the + contents of , + -hex:: are the 40-hexdigit SHA1 hashes, + -mode:: are the octal representation of the file modes. + ++ +The file parameters can point at the user's working file +(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file` +when a new file is added), or a temporary file (e.g. `old-file` in the +index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the +temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits. + +For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1 +parameter, . + + +git specific extension to diff format +------------------------------------- + +What -p option produces is slightly different from the +traditional diff format. + +1. It is preceeded with a "git diff" header, that looks like + this: + + diff --git a/file1 b/file2 ++ +The `a/` and `b/` filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +`/dev/null` is _not_ used in place of `a/` or `b/` filenames. ++ +When rename/copy is involved, `file1` and `file2` show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively. + +2. It is followed by one or more extended header lines: + + old mode + new mode + deleted file mode + new file mode + copy from + copy to + rename from + rename to + similarity index + dissimilarity index + index .. + +3. TAB, LF, and backslash characters in pathnames are + represented as `\t`, `\n`, and `\\`, respectively. diff --git a/diff-options.txt b/diff-options.txt new file mode 100644 index 00000000..9e574a04 --- /dev/null +++ b/diff-options.txt @@ -0,0 +1,70 @@ +-p:: + Generate patch (see section on generating patches) + +-u:: + Synonym for "-p". + +-z:: + \0 line termination on output + +--name-only:: + Show only names of changed files. + +--name-status:: + Show only names and status of changed files. + +--full-index:: + Instead of the first handful characters, show full + object name of pre- and post-image blob on the "index" + line when generating a patch format output. + +--abbrev[=]:: + Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=. + +-B:: + Break complete rewrite changes into pairs of delete and create. + +-M:: + Detect renames. + +-C:: + Detect copies as well as renames. + +--find-copies-harder:: + For performance reasons, by default, -C option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. + +-l:: + -M and -C options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. + +-S:: + Look for differences that contain the change in . + +--pickaxe-all:: + When -S finds a change, show all the changes in that + changeset, not just the files that contain the change + in . + +-O:: + Output the patch in the order specified in the + , which has one shell glob pattern per line. + +-R:: + Swap two inputs; that is, show differences from index or + on-disk file to tree contents. + +For more detailed explanation on these common options, see also +link:diffcore.html[diffcore documentation]. diff --git a/diffcore.html b/diffcore.html new file mode 100644 index 00000000..4c3b6af7 --- /dev/null +++ b/diffcore.html @@ -0,0 +1,554 @@ + + + + + + +Tweaking diff output + + + +

Introduction

+
+

The diff commands git-diff-index, git-diff-files, git-diff-tree, and +git-diff-stages can be told to manipulate differences they find in +unconventional ways before showing diff(1) output. The manipulation +is collectively called "diffcore transformation". This short note +describes what they are and how to use them to produce diff outputs +that are easier to understand than the conventional kind.

+
+

The chain of operation

+
+

The git-diff-* family works by first comparing two sets of +files:

+
    +
  • +

    +git-diff-index compares contents of a "tree" object and the + working directory (when --cached flag is not used) or a + "tree" object and the index file (when --cached flag is + used); +

    +
    • +
  • +

    +git-diff-files compares contents of the index file and the + working directory; +

    +
    • +
  • +

    +git-diff-tree compares contents of two "tree" objects; +

    +
    • +
  • +

    +git-diff-stages compares contents of blobs at two stages in an + unmerged index file. +

    +
    • +
+

In all of these cases, the commands themselves compare +corresponding paths in the two sets of files. The result of +comparison is passed from these commands to what is internally +called "diffcore", in a format similar to what is output when +the -p option is not used. E.g.

+
+
+
in-place edit  :100644 100644 bcd1234... 0123456... M file0
+create         :000000 100644 0000000... 1234567... A file4
+delete         :100644 000000 1234567... 0000000... D file5
+unmerged       :000000 000000 0000000... 0000000... U file6
+
+

The diffcore mechanism is fed a list of such comparison results +(each of which is called "filepair", although at this point each +of them talks about a single file), and transforms such a list +into another list. There are currently 6 such transformations:

+
    +
  • +

    +diffcore-pathspec +

    +
    • +
  • +

    +diffcore-break +

    +
    • +
  • +

    +diffcore-rename +

    +
    • +
  • +

    +diffcore-merge-broken +

    +
    • +
  • +

    +diffcore-pickaxe +

    +
    • +
  • +

    +diffcore-order +

    +
    • +
+

These are applied in sequence. The set of filepairs git-diff-* +commands find are used as the input to diffcore-pathspec, and +the output from diffcore-pathspec is used as the input to the +next transformation. The final result is then passed to the +output routine and generates either diff-raw format (see Output +format sections of the manual for git-diff-* commands) or +diff-patch format.

+
+

diffcore-pathspec: For Ignoring Files Outside Our Consideration

+
+

The first transformation in the chain is diffcore-pathspec, and +is controlled by giving the pathname parameters to the +git-diff-* commands on the command line. The pathspec is used +to limit the world diff operates in. It removes the filepairs +outside the specified set of pathnames. E.g. If the input set +of filepairs included:

+
+
+
:100644 100644 bcd1234... 0123456... M junkfile
+
+

but the command invocation was "git-diff-files myfile", then the +junkfile entry would be removed from the list because only "myfile" +is under consideration.

+

Implementation note. For performance reasons, git-diff-tree +uses the pathname parameters on the command line to cull set of +filepairs it feeds the diffcore mechanism itself, and does not +use diffcore-pathspec, but the end result is the same.

+
+

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 +used to detect a filepair that represents "complete rewrite" and +break such filepair into two filepairs that represent delete and +create. E.g. If the input contained this filepair:

+
+
+
:100644 100644 bcd1234... 0123456... M file0
+
+

and if it detects that the file "file0" is completely rewritten, +it changes it to:

+
+
+
:100644 000000 bcd1234... 0000000... D file0
+:000000 100644 0000000... 0123456... A file0
+
+

For the purpose of breaking a filepair, diffcore-break examines +the extent of changes between the contents of the files before +and after modification (i.e. the contents that have "bcd1234…" +and "0123456…" as their SHA1 content ID, in the above +example). The amount of deletion of original contents and +insertion of new material are added together, and if it exceeds +the "break score", the filepair is broken into two. The break +score defaults to 50% of the size of the smaller of the original +and the result (i.e. if the edit shrinks the file, the size of +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 +(to detect copies as well) to the git-diff-* commands. If the +input contained these filepairs:

+
+
+
:100644 000000 0123456... 0000000... D fileX
+:000000 100644 0000000... 0123456... A file0
+
+

and the contents of the deleted file fileX is similar enough to +the contents of the created file file0, then rename detection +merges these filepairs and creates:

+
+
+
:100644 100644 0123456... 0123456... R100 fileX file0
+
+

When the "-C" option is used, the original contents of modified files, +and deleted files (and also unmodified files, if the +"--find-copies-harder" option is used) are considered as candidates +of the source files in rename/copy operation. If the input were like +these filepairs, that talk about a modified file fileY and a newly +created file file0:

+
+
+
:100644 100644 0123456... 1234567... M fileY
+:000000 100644 0000000... bcd3456... A file0
+
+

the original contents of fileY and the resulting contents of +file0 are compared, and if they are similar enough, they are +changed to:

+
+
+
:100644 100644 0123456... 1234567... M fileY
+:100644 100644 0123456... bcd3456... C100 fileY file0
+
+

In both rename and copy detection, the same "extent of changes" +algorithm used in diffcore-break is used to determine if two +files are "similar enough", and can be customized to use +a similarity score different from the default of 50% by giving a +number after the "-M" or "-C" option (e.g. "-M8" to tell it to use +8/10 = 80%).

+

Note. When the "-C" option is used with --find-copies-harder +option, git-diff-* commands feed unmodified filepairs to +diffcore mechanism as well as modified ones. This lets the copy +detector consider unmodified files as copy source candidates at +the expense of making it slower. Without --find-copies-harder, +git-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 +diffcore-rename, back into a single modification. This always +runs when diffcore-break is used.

+

For the purpose of merging broken filepairs back, it uses a +different "extent of changes" computation from the ones used by +diffcore-break and diffcore-rename. It counts only the deletion +from the original, and does not count insertion. If you removed +only 10 lines from a 100-line document, even if you added 910 +new lines to make a new 1000-line document, you did not do a +complete rewrite. diffcore-break breaks such a case in order to +help diffcore-rename to consider such filepairs as candidate of +rename/copy detection, but if filepairs broken that way were not +matched with other filepairs to create rename/copy, then this +transformation merges them back into the original +"modification".

+

The "extent of changes" parameter can be tweaked from the +default 80% (that is, unless more than 80% of the original +material is deleted, the broken pairs are merged back into a +single modification) by giving a second number to -B option, +like these:

+
    +
  • +

    +-B50/60 (give 50% "break score" to diffcore-break, use 60% + for diffcore-merge-broken). +

    +
    • +
  • +

    +-B/60 (the same as above, since diffcore-break defaults to 50%). +

    +
    • +
+

Note that earlier implementation left a broken pair as a separate +creation and deletion patches. This was an unnecessary hack and +the latest implementation always merges all the broken pairs +back into modifications, but the resulting patch output is +formatted differently for easier review in case of such +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 +-S option and the --pickaxe-all option to the git-diff-* +commands.

+

When diffcore-pickaxe is in use, it checks if there are +filepairs whose "original" side has the specified string and +whose "result" side does not. Such a filepair represents "the +string appeared in this changeset". It also checks for the +opposite case that loses the specified string.

+

When --pickaxe-all is not in effect, diffcore-pickaxe leaves +only such filepairs that touch the specified string in its +output. When --pickaxe-all is used, diffcore-pickaxe leaves all +filepairs intact if there is such a filepair, or makes the +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 +git-diff-* commands.

+

This takes a text file each of whose lines is a shell glob +pattern. Filepairs that match a glob pattern on an earlier line +in the file are output before ones that match a later line, and +filepairs that do not match any glob pattern are output last.

+

As an example, a typical orderfile for the core git probably +would look like this:

+
+
+
README
+Makefile
+Documentation
+*.h
+*.c
+t
+
+
+ + + diff --git a/diffcore.txt b/diffcore.txt new file mode 100644 index 00000000..cb4e5620 --- /dev/null +++ b/diffcore.txt @@ -0,0 +1,275 @@ +Tweaking diff output +==================== +June 2005 + + +Introduction +------------ + +The diff commands git-diff-index, git-diff-files, git-diff-tree, and +git-diff-stages can be told to manipulate differences they find in +unconventional ways before showing diff(1) output. The manipulation +is collectively called "diffcore transformation". This short note +describes what they are and how to use them to produce diff outputs +that are easier to understand than the conventional kind. + + +The chain of operation +---------------------- + +The git-diff-* family works by first comparing two sets of +files: + + - git-diff-index compares contents of a "tree" object and the + working directory (when '\--cached' flag is not used) or a + "tree" object and the index file (when '\--cached' flag is + used); + + - git-diff-files compares contents of the index file and the + working directory; + + - git-diff-tree compares contents of two "tree" objects; + + - git-diff-stages compares contents of blobs at two stages in an + unmerged index file. + +In all of these cases, the commands themselves compare +corresponding paths in the two sets of files. The result of +comparison is passed from these commands to what is internally +called "diffcore", in a format similar to what is output when +the -p option is not used. E.g. + +------------------------------------------------ +in-place edit :100644 100644 bcd1234... 0123456... M file0 +create :000000 100644 0000000... 1234567... A file4 +delete :100644 000000 1234567... 0000000... D file5 +unmerged :000000 000000 0000000... 0000000... U file6 +------------------------------------------------ + +The diffcore mechanism is fed a list of such comparison results +(each of which is called "filepair", although at this point each +of them talks about a single file), and transforms such a list +into another list. There are currently 6 such transformations: + +- diffcore-pathspec +- diffcore-break +- diffcore-rename +- diffcore-merge-broken +- diffcore-pickaxe +- diffcore-order + +These are applied in sequence. The set of filepairs git-diff-\* +commands find are used as the input to diffcore-pathspec, and +the output from diffcore-pathspec is used as the input to the +next transformation. The final result is then passed to the +output routine and generates either diff-raw format (see Output +format sections of the manual for git-diff-\* commands) or +diff-patch format. + + +diffcore-pathspec: For Ignoring Files Outside Our Consideration +--------------------------------------------------------------- + +The first transformation in the chain is diffcore-pathspec, and +is controlled by giving the pathname parameters to the +git-diff-* commands on the command line. The pathspec is used +to limit the world diff operates in. It removes the filepairs +outside the specified set of pathnames. E.g. If the input set +of filepairs included: + +------------------------------------------------ +:100644 100644 bcd1234... 0123456... M junkfile +------------------------------------------------ + +but the command invocation was "git-diff-files myfile", then the +junkfile entry would be removed from the list because only "myfile" +is under consideration. + +Implementation note. For performance reasons, git-diff-tree +uses the pathname parameters on the command line to cull set of +filepairs it feeds the diffcore mechanism itself, and does not +use diffcore-pathspec, but the end result is the same. + + +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 +used to detect a filepair that represents "complete rewrite" and +break such filepair into two filepairs that represent delete and +create. E.g. If the input contained this filepair: + +------------------------------------------------ +:100644 100644 bcd1234... 0123456... M file0 +------------------------------------------------ + +and if it detects that the file "file0" is completely rewritten, +it changes it to: + +------------------------------------------------ +:100644 000000 bcd1234... 0000000... D file0 +:000000 100644 0000000... 0123456... A file0 +------------------------------------------------ + +For the purpose of breaking a filepair, diffcore-break examines +the extent of changes between the contents of the files before +and after modification (i.e. the contents that have "bcd1234..." +and "0123456..." as their SHA1 content ID, in the above +example). The amount of deletion of original contents and +insertion of new material are added together, and if it exceeds +the "break score", the filepair is broken into two. The break +score defaults to 50% of the size of the smaller of the original +and the result (i.e. if the edit shrinks the file, the size of +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 +(to detect copies as well) to the git-diff-* commands. If the +input contained these filepairs: + +------------------------------------------------ +:100644 000000 0123456... 0000000... D fileX +:000000 100644 0000000... 0123456... A file0 +------------------------------------------------ + +and the contents of the deleted file fileX is similar enough to +the contents of the created file file0, then rename detection +merges these filepairs and creates: + +------------------------------------------------ +:100644 100644 0123456... 0123456... R100 fileX file0 +------------------------------------------------ + +When the "-C" option is used, the original contents of modified files, +and deleted files (and also unmodified files, if the +"\--find-copies-harder" option is used) are considered as candidates +of the source files in rename/copy operation. If the input were like +these filepairs, that talk about a modified file fileY and a newly +created file file0: + +------------------------------------------------ +:100644 100644 0123456... 1234567... M fileY +:000000 100644 0000000... bcd3456... A file0 +------------------------------------------------ + +the original contents of fileY and the resulting contents of +file0 are compared, and if they are similar enough, they are +changed to: + +------------------------------------------------ +:100644 100644 0123456... 1234567... M fileY +:100644 100644 0123456... bcd3456... C100 fileY file0 +------------------------------------------------ + +In both rename and copy detection, the same "extent of changes" +algorithm used in diffcore-break is used to determine if two +files are "similar enough", and can be customized to use +a similarity score different from the default of 50% by giving a +number after the "-M" or "-C" option (e.g. "-M8" to tell it to use +8/10 = 80%). + +Note. When the "-C" option is used with `\--find-copies-harder` +option, git-diff-\* commands feed unmodified filepairs to +diffcore mechanism as well as modified ones. This lets the copy +detector consider unmodified files as copy source candidates at +the expense of making it slower. Without `\--find-copies-harder`, +git-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 +diffcore-rename, back into a single modification. This always +runs when diffcore-break is used. + +For the purpose of merging broken filepairs back, it uses a +different "extent of changes" computation from the ones used by +diffcore-break and diffcore-rename. It counts only the deletion +from the original, and does not count insertion. If you removed +only 10 lines from a 100-line document, even if you added 910 +new lines to make a new 1000-line document, you did not do a +complete rewrite. diffcore-break breaks such a case in order to +help diffcore-rename to consider such filepairs as candidate of +rename/copy detection, but if filepairs broken that way were not +matched with other filepairs to create rename/copy, then this +transformation merges them back into the original +"modification". + +The "extent of changes" parameter can be tweaked from the +default 80% (that is, unless more than 80% of the original +material is deleted, the broken pairs are merged back into a +single modification) by giving a second number to -B option, +like these: + +* -B50/60 (give 50% "break score" to diffcore-break, use 60% + for diffcore-merge-broken). + +* -B/60 (the same as above, since diffcore-break defaults to 50%). + +Note that earlier implementation left a broken pair as a separate +creation and deletion patches. This was an unnecessary hack and +the latest implementation always merges all the broken pairs +back into modifications, but the resulting patch output is +formatted differently for easier review in case of such +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 +-S option and the `\--pickaxe-all` option to the git-diff-* +commands. + +When diffcore-pickaxe is in use, it checks if there are +filepairs whose "original" side has the specified string and +whose "result" side does not. Such a filepair represents "the +string appeared in this changeset". It also checks for the +opposite case that loses the specified string. + +When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves +only such filepairs that touch the specified string in its +output. When `\--pickaxe-all` is used, diffcore-pickaxe leaves all +filepairs intact if there is such a filepair, or makes the +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 +git-diff-* commands. + +This takes a text file each of whose lines is a shell glob +pattern. Filepairs that match a glob pattern on an earlier line +in the file are output before ones that match a later line, and +filepairs that do not match any glob pattern are output last. + +As an example, a typical orderfile for the core git probably +would look like this: + +------------------------------------------------ +README +Makefile +Documentation +*.h +*.c +t +------------------------------------------------ + diff --git a/everyday.html b/everyday.html new file mode 100644 index 00000000..a51a09a6 --- /dev/null +++ b/everyday.html @@ -0,0 +1,815 @@ + + + + + + +Everyday GIT With 20 Commands Or So + + + +
+
+

GIT suite has over 100 commands, and the manual page for each of +them discusses what the command does and how it is used in +detail, but until you know what command should be used in order +to achieve what you want to do, you cannot tell which manual +page to look at, and if you know that already you do not need +the manual.

+

Does that mean you need to know all of them before you can use +git? Not at all. Depending on the role you play, the set of +commands you need to know is slightly different, but in any case +what you need to learn is far smaller than the full set of +commands to carry out your day-to-day work. This document is to +serve as a cheat-sheet and a set of pointers for people playing +various roles.

+

[Basic Repository] commands are needed by people who has a +repository --- that is everybody, because every working tree of +git is a repository.

+

In addition, [Individual Developer (Standalone)] 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 +[Individual Developer (Participant)] section as well.

+

People who play [Integrator] role need to learn some more +commands in addition to the above.

+

[Repository Administration] commands are for system +administrators who are responsible to care and feed git +repositories to support developers.

+
+
+

Basic Repository

+
+

Everybody uses these commands to feed and care git repositories.

+ +

Examples

+
+
+Check health and remove cruft. +
+
+
+
+
$ git fsck-objects (1)
+$ git prune
+$ git count-objects (2)
+$ git repack (3)
+$ git prune (4)
+
+(1) running without "--full" is usually cheap and assures the
+repository health reasonably well.
+(2) check how many loose objects there are and how much
+diskspace is wasted by not repacking.
+(3) without "-a" repacks incrementally.  repacking every 4-5MB
+of loose objects accumulation may be a good rule of thumb.
+(4) after repack, prune removes the duplicate loose objects.
+
+
+
+Repack a small project into single pack. +
+
+
+
+
$ git repack -a -d (1)
+$ git prune
+
+(1) pack all the objects reachable from the refs into one pack
+and remove unneeded other packs
+
+
+
+
+

Individual Developer (Standalone)

+
+

A standalone individual developer does not exchange patches with +other poeple, and works alone in a single repository, using the +following commands.

+ +

Examples

+
+
+Extract a tarball and create a working tree and a new repository to keep track of it. +
+
+
+
+
$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git-init-db
+$ git add . (1)
+$ git commit -m 'import of frotz source tree.'
+$ git tag v2.43 (2)
+
+(1) add everything under the current directory.
+(2) make a lightweight, unannotated tag.
+
+
+
+Create a topic branch and develop. +
+
+
+
+
$ git checkout -b alsa-audio (1)
+$ edit/compile/test
+$ git checkout -- curses/ux_audio_oss.c (2)
+$ git add curses/ux_audio_alsa.c (3)
+$ edit/compile/test
+$ git diff (4)
+$ git commit -a -s (5)
+$ edit/compile/test
+$ git reset --soft HEAD^ (6)
+$ edit/compile/test
+$ git diff ORIG_HEAD (7)
+$ git commit -a -c ORIG_HEAD (8)
+$ git checkout master (9)
+$ git pull . alsa-audio (10)
+$ git log --since='3 days ago' (11)
+$ git log v2.43.. curses/ (12)
+
+(1) create a new topic branch.
+(2) revert your botched changes in "curses/ux_audio_oss.c".
+(3) you need to tell git if you added a new file; removal and
+modification will be caught if you do "commit -a" later.
+(4) to see what changes you are committing.
+(5) commit everything as you have tested, with your sign-off.
+(6) take the last commit back, keeping what is in the working tree.
+(7) look at the changes since the premature commit we took back.
+(8) redo the commit undone in the previous step, using the message
+you originally wrote.
+(9) switch to the master branch.
+(10) merge a topic branch into your master branch
+(11) review commit logs; other forms to limit output can be
+combined and include --max-count=10 (show 10 commits), --until='2005-12-10'.
+(12) view only the changes that touch what's in curses/
+directory, since v2.43 tag.
+
+
+
+
+

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.

+
    +
  • +

    +git-clone(1) from the upstream to prime your local + repository. +

    +
    • +
  • +

    +git-pull(1) and git-fetch(1) from "origin" + to keep up-to-date with the upstream. +

    +
    • +
  • +

    +git-push(1) to shared repository, if you adopt CVS + style shared repository workflow. +

    +
    • +
  • +

    +git-format-patch(1) to prepare e-mail submission, if + you adopt Linux kernel-style public forum workflow. +

    +
    • +
+

Examples

+
+
+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 (1)
+$ git format-patch origin (2)
+$ git pull (3)
+$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 (4)
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (5)
+$ git reset --hard ORIG_HEAD (6)
+$ git prune (7)
+$ git fetch --tags (8)
+
+(1) repeat as needed.
+(2) extract patches from your branch for e-mail submission.
+(3) "pull" fetches from "origin" by default and merges into the
+current branch.
+(4) immediately after pulling, look at the changes done upstream
+since last time we checked, only in the
+area we are interested in.
+(5) fetch from a specific branch from a specific repository and merge.
+(6) revert the pull.
+(7) garbage collect leftover objects from reverted pull.
+(8) from time to time, obtain official tags from the "origin"
+and store them under .git/refs/tags/.
+
+
+
+Push into another repository. +
+
+
+
+
satellite$ git clone mothership:frotz/.git frotz (1)
+satellite$ cd frotz
+satellite$ cat .git/remotes/origin (2)
+URL: mothership:frotz/.git
+Pull: master:origin
+satellite$ echo 'Push: master:satellite' >>.git/remotes/origin (3)
+satellite$ edit/compile/test/commit
+satellite$ git push origin (4)
+
+mothership$ cd frotz
+mothership$ git checkout master
+mothership$ git pull . satellite (5)
+
+(1) mothership machine has a frotz repository under your home
+directory; clone from it to start a repository on the satellite
+machine.
+(2) clone creates this file by default.  It arranges "git pull"
+to fetch and store the master branch head of mothership machine
+to local "origin" branch.
+(3) arrange "git push" to push local "master" branch to
+"satellite" branch of the mothership machine.
+(4) push will stash our work away on "satellite" branch on the
+mothership machine.  You could use this as a back-up method.
+(5) on mothership machine, merge the work done on the satellite
+machine into the master branch.
+
+
+
+Branch off of a specific tag. +
+
+
+
+
$ git checkout -b private2.6.14 v2.6.14 (1)
+$ 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 (2)
+
+(1) create a private branch based on a well known (but somewhat behind)
+tag.
+(2) forward port all changes in private2.6.14 branch to master branch
+without a formal "merging".
+
+
+
+
+

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 +commands in addition to the ones needed by participants.

+
    +
  • +

    +git-am(1) to apply patches e-mailed in from your + contributors. +

    +
    • +
  • +

    +git-pull(1) to merge from your trusted lieutenants. +

    +
    • +
  • +

    +git-format-patch(1) to prepare and send suggested + alternative to contributors. +

    +
    • +
  • +

    +git-revert(1) to undo botched commits. +

    +
    • +
  • +

    +git-push(1) to publish the bleeding edge. +

    +
    • +
+

Examples

+
+
+My typical GIT day. +
+
+
+
+
$ git status (1)
+$ git show-branch (2)
+$ mailx (3)
+& s 2 3 4 5 ./+to-apply
+& s 7 8 ./+hold-linus
+& q
+$ git checkout master
+$ git am -3 -i -s -u ./+to-apply (4)
+$ compile/test
+$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus (5)
+$ git checkout topic/one && git rebase master (6)
+$ git checkout pu && git reset --hard master (7)
+$ git pull . topic/one topic/two && git pull . hold/linus (8)
+$ git checkout maint
+$ git cherry-pick master~4 (9)
+$ compile/test
+$ git tag -s -m 'GIT 0.99.9x' v0.99.9x (10)
+$ git fetch ko && git show-branch master maint 'tags/ko-*' (11)
+$ git push ko (12)
+$ git push ko v0.99.9x (13)
+
+(1) see what I was in the middle of doing, if any.
+(2) see what topic branches I have and think about how ready
+they are.
+(3) read mails, save ones that are applicable, and save others
+that are not quite ready.
+(4) apply them, interactively, with my sign-offs.
+(5) create topic branch as needed and apply, again with my
+sign-offs.
+(6) rebase internal topic branch that has not been merged to the
+master, nor exposed as a part of a stable branch.
+(7) restart "pu" every time from the master.
+(8) and bundle topic branches still cooking.
+(9) backport a critical fix.
+(10) create a signed tag.
+(11) make sure I did not accidentally rewind master beyond what I
+already pushed out.  "ko" shorthand points at the repository I have
+at kernel.org, and looks like this:
+    $ cat .git/remotes/ko
+    URL: kernel.org:/pub/scm/git/git.git
+    Pull: master:refs/tags/ko-master
+    Pull: maint:refs/tags/ko-maint
+    Push: master
+    Push: +pu
+    Push: maint
+In the output from "git show-branch", "master" should have
+everything "ko-master" has.
+(12) push out the bleeding edge.
+(13) push the tag out, too.
+
+
+
+
+

Repository Administration

+
+

A repository administrator uses the following tools to set up +and maintain access to the repository by developers.

+
    +
  • +

    +git-daemon(1) to allow anonymous download from + repository. +

    +
    • +
  • +

    +git-shell(1) can be used as a restricted login shell + for shared central repository users. +

    +
    • +
+

update hook howto has a good +example of managing a shared central repository.

+

Examples

+
+
+Run git-daemon to serve /pub/scm from inetd. +
+
+
+
+
$ grep git /etc/inet.conf
+git     stream  tcp     nowait  nobody \
+  /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
+
+

The actual configuration line should be on one line.

+
+
+Give push/pull only access to developers. +
+
+
+
+
$ grep git /etc/passwd (1)
+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 (2)
+/usr/bin/git-shell
+
+(1) 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.
+(2) in many distributions /etc/shells needs to list what is used
+as the login shell.
+
+
+
+CVS-style shared repository. +
+
+
+
+
$ grep git /etc/group (1)
+git:x:9418:alice,bob,cindy,david
+$ cd /home/devo.git
+$ ls -l (2)
+  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
+  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
+  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
+  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 (3)
+  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
+$ cat info/allowed-users (4)
+refs/heads/master       alice\|cindy
+refs/heads/doc-update   bob
+refs/tags/v[0-9]*       david
+
+(1) place the developers into the same git group.
+(2) and make the shared repository writable by the group.
+(3) use update-hook example by Carl from Documentation/howto/
+for branch policy control.
+(4) 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
+create and push version tags.
+
+
+
+HTTP server to support dumb protocol transfer. +
+
+
+
+
dev$ git update-server-info (1)
+dev$ ftp user@isp.example.com (2)
+ftp> cp -r .git /home/user/myproject.git
+
+(1) make sure your info/refs and objects/info/packs are up-to-date
+(2) upload to public HTTP server hosted by your ISP.
+
+
+
+
+ + + diff --git a/everyday.txt b/everyday.txt new file mode 100644 index 00000000..3ab9b916 --- /dev/null +++ b/everyday.txt @@ -0,0 +1,441 @@ +Everyday GIT With 20 Commands Or So +=================================== + +GIT suite has over 100 commands, and the manual page for each of +them discusses what the command does and how it is used in +detail, but until you know what command should be used in order +to achieve what you want to do, you cannot tell which manual +page to look at, and if you know that already you do not need +the manual. + +Does that mean you need to know all of them before you can use +git? Not at all. Depending on the role you play, the set of +commands you need to know is slightly different, but in any case +what you need to learn is far smaller than the full set of +commands to carry out your day-to-day work. This document is to +serve as a cheat-sheet and a set of pointers for people playing +various roles. + +<> commands are needed by people who has a +repository --- that is everybody, because every working tree of +git is a repository. + +In addition, <> 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 +<> section as well. + +People who play <> role need to learn some more +commands in addition to the above. + +<> commands are for system +administrators who are responsible to care and feed git +repositories to support developers. + + +Basic Repository[[Basic Repository]] +------------------------------------ + +Everybody uses these commands to feed and care git repositories. + + * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a + new repository. + + * gitlink:git-fsck-objects[1] to validate the repository. + + * gitlink:git-prune[1] to garbage collect crufts in the + repository. + + * gitlink:git-repack[1] to pack loose objects for efficiency. + +Examples +~~~~~~~~ + +Check health and remove cruft.:: ++ +------------ +$ git fsck-objects <1> +$ git prune +$ git count-objects <2> +$ git repack <3> +$ git prune <4> + +<1> running without "--full" is usually cheap and assures the +repository health reasonably well. +<2> check how many loose objects there are and how much +diskspace is wasted by not repacking. +<3> without "-a" repacks incrementally. repacking every 4-5MB +of loose objects accumulation may be a good rule of thumb. +<4> after repack, prune removes the duplicate loose objects. +------------ + +Repack a small project into single pack.:: ++ +------------ +$ git repack -a -d <1> +$ git prune + +<1> pack all the objects reachable from the refs into one pack +and remove unneeded other packs +------------ + + +Individual Developer (Standalone)[[Individual Developer (Standalone)]] +---------------------------------------------------------------------- + +A standalone individual developer does not exchange patches with +other poeple, and works alone in a single repository, using the +following commands. + + * gitlink:git-show-branch[1] to see where you are. + + * gitlink:git-log[1] to see what happened. + + * gitlink:git-whatchanged[1] to find out where things have + come from. + + * gitlink:git-checkout[1] and gitlink:git-branch[1] to switch + branches. + + * gitlink:git-add[1] and gitlink:git-update-index[1] to manage + the index file. + + * gitlink:git-diff[1] and gitlink:git-status[1] to see what + you are in the middle of doing. + + * gitlink:git-commit[1] to advance the current branch. + + * gitlink:git-reset[1] and gitlink:git-checkout[1] (with + pathname parameters) to undo changes. + + * gitlink:git-pull[1] with "." as the remote to merge between + local branches. + + * gitlink:git-rebase[1] to maintain topic branches. + + * gitlink:git-tag[1] to mark known point. + +Examples +~~~~~~~~ + +Extract a tarball and create a working tree and a new repository to keep track of it.:: ++ +------------ +$ tar zxf frotz.tar.gz +$ cd frotz +$ git-init-db +$ git add . <1> +$ git commit -m 'import of frotz source tree.' +$ git tag v2.43 <2> + +<1> add everything under the current directory. +<2> make a lightweight, unannotated tag. +------------ + +Create a topic branch and develop.:: ++ +------------ +$ git checkout -b alsa-audio <1> +$ edit/compile/test +$ git checkout -- curses/ux_audio_oss.c <2> +$ git add curses/ux_audio_alsa.c <3> +$ edit/compile/test +$ git diff <4> +$ git commit -a -s <5> +$ edit/compile/test +$ git reset --soft HEAD^ <6> +$ edit/compile/test +$ git diff ORIG_HEAD <7> +$ git commit -a -c ORIG_HEAD <8> +$ git checkout master <9> +$ git pull . alsa-audio <10> +$ git log --since='3 days ago' <11> +$ git log v2.43.. curses/ <12> + +<1> create a new topic branch. +<2> revert your botched changes in "curses/ux_audio_oss.c". +<3> you need to tell git if you added a new file; removal and +modification will be caught if you do "commit -a" later. +<4> to see what changes you are committing. +<5> commit everything as you have tested, with your sign-off. +<6> take the last commit back, keeping what is in the working tree. +<7> look at the changes since the premature commit we took back. +<8> redo the commit undone in the previous step, using the message +you originally wrote. +<9> switch to the master branch. +<10> merge a topic branch into your master branch +<11> review commit logs; other forms to limit output can be +combined and include --max-count=10 (show 10 commits), --until='2005-12-10'. +<12> view only the changes that touch what's in curses/ +directory, since v2.43 tag. +------------ + + +Individual Developer (Participant)[[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. + + * gitlink:git-clone[1] from the upstream to prime your local + repository. + + * gitlink:git-pull[1] and gitlink:git-fetch[1] from "origin" + to keep up-to-date with the upstream. + + * gitlink:git-push[1] to shared repository, if you adopt CVS + style shared repository workflow. + + * gitlink:git-format-patch[1] to prepare e-mail submission, if + you adopt Linux kernel-style public forum workflow. + +Examples +~~~~~~~~ + +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 <1> +$ git format-patch origin <2> +$ git pull <3> +$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <4> +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5> +$ git reset --hard ORIG_HEAD <6> +$ git prune <7> +$ git fetch --tags <8> + +<1> repeat as needed. +<2> extract patches from your branch for e-mail submission. +<3> "pull" fetches from "origin" by default and merges into the +current branch. +<4> immediately after pulling, look at the changes done upstream +since last time we checked, only in the +area we are interested in. +<5> fetch from a specific branch from a specific repository and merge. +<6> revert the pull. +<7> garbage collect leftover objects from reverted pull. +<8> from time to time, obtain official tags from the "origin" +and store them under .git/refs/tags/. +------------ + + +Push into another repository.:: ++ +------------ +satellite$ git clone mothership:frotz/.git frotz <1> +satellite$ cd frotz +satellite$ cat .git/remotes/origin <2> +URL: mothership:frotz/.git +Pull: master:origin +satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <3> +satellite$ edit/compile/test/commit +satellite$ git push origin <4> + +mothership$ cd frotz +mothership$ git checkout master +mothership$ git pull . satellite <5> + +<1> mothership machine has a frotz repository under your home +directory; clone from it to start a repository on the satellite +machine. +<2> clone creates this file by default. It arranges "git pull" +to fetch and store the master branch head of mothership machine +to local "origin" branch. +<3> arrange "git push" to push local "master" branch to +"satellite" branch of the mothership machine. +<4> push will stash our work away on "satellite" branch on the +mothership machine. You could use this as a back-up method. +<5> on mothership machine, merge the work done on the satellite +machine into the master branch. +------------ + +Branch off of a specific tag.:: ++ +------------ +$ git checkout -b private2.6.14 v2.6.14 <1> +$ 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 <2> + +<1> create a private branch based on a well known (but somewhat behind) +tag. +<2> forward port all changes in private2.6.14 branch to master branch +without a formal "merging". +------------ + + +Integrator[[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 +commands in addition to the ones needed by participants. + + * gitlink:git-am[1] to apply patches e-mailed in from your + contributors. + + * gitlink:git-pull[1] to merge from your trusted lieutenants. + + * gitlink:git-format-patch[1] to prepare and send suggested + alternative to contributors. + + * gitlink:git-revert[1] to undo botched commits. + + * gitlink:git-push[1] to publish the bleeding edge. + + +Examples +~~~~~~~~ + +My typical GIT day.:: ++ +------------ +$ git status <1> +$ git show-branch <2> +$ mailx <3> +& s 2 3 4 5 ./+to-apply +& s 7 8 ./+hold-linus +& q +$ git checkout master +$ git am -3 -i -s -u ./+to-apply <4> +$ compile/test +$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5> +$ git checkout topic/one && git rebase master <6> +$ git checkout pu && git reset --hard master <7> +$ git pull . topic/one topic/two && git pull . hold/linus <8> +$ git checkout maint +$ git cherry-pick master~4 <9> +$ compile/test +$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <10> +$ git fetch ko && git show-branch master maint 'tags/ko-*' <11> +$ git push ko <12> +$ git push ko v0.99.9x <13> + +<1> see what I was in the middle of doing, if any. +<2> see what topic branches I have and think about how ready +they are. +<3> read mails, save ones that are applicable, and save others +that are not quite ready. +<4> apply them, interactively, with my sign-offs. +<5> create topic branch as needed and apply, again with my +sign-offs. +<6> rebase internal topic branch that has not been merged to the +master, nor exposed as a part of a stable branch. +<7> restart "pu" every time from the master. +<8> and bundle topic branches still cooking. +<9> backport a critical fix. +<10> create a signed tag. +<11> make sure I did not accidentally rewind master beyond what I +already pushed out. "ko" shorthand points at the repository I have +at kernel.org, and looks like this: + $ cat .git/remotes/ko + URL: kernel.org:/pub/scm/git/git.git + Pull: master:refs/tags/ko-master + Pull: maint:refs/tags/ko-maint + Push: master + Push: +pu + Push: maint +In the output from "git show-branch", "master" should have +everything "ko-master" has. +<12> push out the bleeding edge. +<13> push the tag out, too. +------------ + + +Repository Administration[[Repository Administration]] +------------------------------------------------------ + +A repository administrator uses the following tools to set up +and maintain access to the repository by developers. + + * gitlink:git-daemon[1] to allow anonymous download from + repository. + + * gitlink:git-shell[1] can be used as a 'restricted login shell' + for shared central repository users. + +link:howto/update-hook-example.txt[update hook howto] has a good +example of managing a shared central repository. + + +Examples +~~~~~~~~ + +Run git-daemon to serve /pub/scm from inetd.:: ++ +------------ +$ grep git /etc/inet.conf +git stream tcp nowait nobody \ + /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm +------------ ++ +The actual configuration line should be on one line. + +Give push/pull only access to developers.:: ++ +------------ +$ grep git /etc/passwd <1> +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 <2> +/usr/bin/git-shell + +<1> 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. +<2> in many distributions /etc/shells needs to list what is used +as the login shell. +------------ + +CVS-style shared repository.:: ++ +------------ +$ grep git /etc/group <1> +git:x:9418:alice,bob,cindy,david +$ cd /home/devo.git +$ ls -l <2> + 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 + -rw-rw-r-- 1 david git 58 Dec 4 22:40 description + drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks + -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index + drwxrwsr-x 2 david git 4096 Dec 4 22:40 info + 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 <3> + -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update +$ cat info/allowed-users <4> +refs/heads/master alice\|cindy +refs/heads/doc-update bob +refs/tags/v[0-9]* david + +<1> place the developers into the same git group. +<2> and make the shared repository writable by the group. +<3> use update-hook example by Carl from Documentation/howto/ +for branch policy control. +<4> 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 +create and push version tags. +------------ + +HTTP server to support dumb protocol transfer.:: ++ +------------ +dev$ git update-server-info <1> +dev$ ftp user@isp.example.com <2> +ftp> cp -r .git /home/user/myproject.git + +<1> make sure your info/refs and objects/info/packs are up-to-date +<2> upload to public HTTP server hosted by your ISP. +------------ diff --git a/fetch-options.txt b/fetch-options.txt new file mode 100644 index 00000000..200c9b24 --- /dev/null +++ b/fetch-options.txt @@ -0,0 +1,24 @@ +-a, \--append:: + Append ref names and object names of fetched refs to the + existing contents of `.git/FETCH_HEAD`. Without this + option old data in `.git/FETCH_HEAD` will be overwritten. + +-f, \--force:: + When `git-fetch` is used with `:` + refspec, it refuses to update the local branch + `` unless the remote branch `` it + fetches is a descendant of ``. This option + overrides that check. + +-t, \--tags:: + By default, the git core utilities will not fetch and store + tags under the same name as the remote repository; ask it + to do so using `--tags`. Using this option will bound the + list of objects pulled to the remote tags. Commits in branches + beyond the tags will be ignored. + +-u, \--update-head-ok:: + By default `git-fetch` refuses to update the head which + corresponds to the current branch. This flag disables the + check. Note that fetching into the current branch will not + update the index and working directory, so use it with care. diff --git a/git-add.html b/git-add.html new file mode 100644 index 00000000..875931a9 --- /dev/null +++ b/git-add.html @@ -0,0 +1,378 @@ + + + + + + +git-add(1) + + + +

SYNOPSIS

+
+

git-add [-n] [-v] <file>…

+
+

DESCRIPTION

+
+

A simple wrapper for git-update-index to add files to the index, +for people used to do "cvs add".

+
+

OPTIONS

+
+
+
+<file>… +
+
+

+ Files to add to the index. +

+
+
+-n +
+
+

+ Don't actually add the file(s), just show if they exist. +

+
+
+-v +
+
+

+ Be verbose. +

+
+
+
+

DISCUSSION

+
+

The list of <file> given to the command is fed to git-ls-files +command to list files that are not registerd in the index and +are not ignored/excluded by $GIT_DIR/info/exclude file or +.gitignore file in each directory. This means two things:

+
    +
  1. +

    +You can put the name of a directory on the command line, and + the command will add all files in it and its subdirectories; +

    +
    2. +
  2. +

    +Giving the name of a file that is already in index does not + run git-update-index on that path. +

    +
    3. +
+
+

EXAMPLES

+
+
+
+git-add Documentation/\*.txt +
+
+

+ Adds all *.txt files that are not in the index under + Documentation directory and its subdirectories. +

+

Note that the asterisk * is quoted from the shell in this +example; this lets the command to include the files from +subdirectories of Documentation/ directory.

+
+
+git-add git-*.sh +
+
+

+ Adds all git-*.sh scripts that are not in the index. + Because this example lets shell expand the asterisk + (i.e. you are listing the files explicitly), it does not + add subdir/git-foo.sh to the index. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-add.txt b/git-add.txt new file mode 100644 index 00000000..4cae4126 --- /dev/null +++ b/git-add.txt @@ -0,0 +1,75 @@ +git-add(1) +========== + +NAME +---- +git-add - Add files to the index file. + +SYNOPSIS +-------- +'git-add' [-n] [-v] ... + +DESCRIPTION +----------- +A simple wrapper for git-update-index to add files to the index, +for people used to do "cvs add". + + +OPTIONS +------- +...:: + Files to add to the index. + +-n:: + Don't actually add the file(s), just show if they exist. + +-v:: + Be verbose. + + +DISCUSSION +---------- + +The list of given to the command is fed to `git-ls-files` +command to list files that are not registerd in the index and +are not ignored/excluded by `$GIT_DIR/info/exclude` file or +`.gitignore` file in each directory. This means two things: + +. You can put the name of a directory on the command line, and + the command will add all files in it and its subdirectories; + +. Giving the name of a file that is already in index does not + run `git-update-index` on that path. + + +EXAMPLES +-------- +git-add Documentation/\\*.txt:: + + Adds all `\*.txt` files that are not in the index under + `Documentation` directory and its subdirectories. ++ +Note that the asterisk `\*` is quoted from the shell in this +example; this lets the command to include the files from +subdirectories of `Documentation/` directory. + +git-add git-*.sh:: + + Adds all git-*.sh scripts that are not in the index. + Because this example lets shell expand the asterisk + (i.e. you are listing the files explicitly), it does not + add `subdir/git-foo.sh` to the index. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-am.html b/git-am.html new file mode 100644 index 00000000..83459576 --- /dev/null +++ b/git-am.html @@ -0,0 +1,414 @@ + + + + + + +git-am(1) + + + +

SYNOPSIS

+
+

git-am [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>… +git-am [--skip | --resolved]

+
+

DESCRIPTION

+
+

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

+
+

OPTIONS

+
+
+
+--signoff +
+
+

+ Add Signed-off-by: line to the commit message, using + the committer identity of yourself. +

+
+
+--dotest=<dir> +
+
+

+ Instead of .dotest directory, use <dir> as a working + area to store extracted patches. +

+
+
+--utf8, --keep +
+
+

+ Pass -u and -k flags to git-mailinfo (see + git-mailinfo(1)). +

+
+
+--binary +
+
+

+ Pass --allow-binary-replacement flag to git-apply + (see git-apply(1)). +

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

+
+
+--skip +
+
+

+ Skip the current patch. This is only meaningful when + restarting an aborted patch. +

+
+
+--interactive +
+
+

+ Run interactively, just like git-applymbox. +

+
+
+--resolved +
+
+

+ After a patch failure (e.g. attempting to apply + conflicting patch), the user has applied it by hand and + the index file stores the result of the application. + Make a commit using the authorship and commit log + extracted from the e-mail message and the current index + file, and continue. +

+
+
+
+

DISCUSSION

+
+

When initially invoking it, you give it names of the mailboxes +to crunch. Upon seeing the first patch that does not apply, it +aborts in the middle, just like git-applymbox does. You can +recover from this in one of two ways:

+
    +
  1. +

    +skip the current one by re-running the command with --skip + option. +

    +
    2. +
  2. +

    +hand resolve the conflict in the working directory, and update + the index file to bring it in a state that the patch should + have produced. Then run the command with --resolved option. +

    +
    3. +
+

The command refuses to process new mailboxes while .dotest +directory exists, so if you decide to start over from scratch, +run rm -f .dotest before running the command with mailbox +names.

+
+

SEE ALSO

+
+

git-applymbox(1), git-applypatch(1).

+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-am.txt b/git-am.txt new file mode 100644 index 00000000..a415fe24 --- /dev/null +++ b/git-am.txt @@ -0,0 +1,96 @@ +git-am(1) +========= + +NAME +---- +git-am - Apply a series of patches in a mailbox + + +SYNOPSIS +-------- +'git-am' [--signoff] [--dotest=] [--utf8] [--binary] [--3way] ... +'git-am' [--skip | --resolved] + +DESCRIPTION +----------- +Splits mail messages in a mailbox into commit log message, +authorship information and patches, and applies them to the +current branch. + +OPTIONS +------- +--signoff:: + Add `Signed-off-by:` line to the commit message, using + the committer identity of yourself. + +--dotest=:: + Instead of `.dotest` directory, use as a working + area to store extracted patches. + +--utf8, --keep:: + Pass `-u` and `-k` flags to `git-mailinfo` (see + gitlink:git-mailinfo[1]). + +--binary:: + Pass `--allow-binary-replacement` flag to `git-apply` + (see gitlink:git-apply[1]). + +--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 + locally. + +--skip:: + Skip the current patch. This is only meaningful when + restarting an aborted patch. + +--interactive:: + Run interactively, just like git-applymbox. + +--resolved:: + After a patch failure (e.g. attempting to apply + conflicting patch), the user has applied it by hand and + the index file stores the result of the application. + Make a commit using the authorship and commit log + extracted from the e-mail message and the current index + file, and continue. + +DISCUSSION +---------- + +When initially invoking it, you give it names of the mailboxes +to crunch. Upon seeing the first patch that does not apply, it +aborts in the middle, just like 'git-applymbox' does. You can +recover from this in one of two ways: + +. skip the current one by re-running the command with '--skip' + option. + +. hand resolve the conflict in the working directory, and update + the index file to bring it in a state that the patch should + have produced. Then run the command with '--resolved' option. + +The command refuses to process new mailboxes while `.dotest` +directory exists, so if you decide to start over from scratch, +run `rm -f .dotest` before running the command with mailbox +names. + + +SEE ALSO +-------- +gitlink:git-applymbox[1], gitlink:git-applypatch[1]. + + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Petr Baudis, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-apply.html b/git-apply.html new file mode 100644 index 00000000..7153716a --- /dev/null +++ b/git-apply.html @@ -0,0 +1,433 @@ + + + + + + +git-apply(1) + + + +

SYNOPSIS

+
+

git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [<patch>…]

+
+

DESCRIPTION

+
+

Reads supplied diff output and applies it on a git index file +and a work tree.

+
+

OPTIONS

+
+
+
+<patch>… +
+
+

+ The files to read patch from. - can be used to read + from the standard input. +

+
+
+--stat +
+
+

+ Instead of applying the patch, output diffstat for the + input. Turns off "apply". +

+
+
+--numstat +
+
+

+ Similar to --stat, but shows number of added and + deleted lines in decimal notation and pathname without + abbreviation, to make it more machine friendly. Turns + off "apply". +

+
+
+--summary +
+
+

+ Instead of applying the patch, output a condensed + summary of information obtained from git diff extended + headers, such as creations, renames and mode changes. + Turns off "apply". +

+
+
+--check +
+
+

+ Instead of applying the patch, see if the patch is + applicable to the current work tree and/or the index + file and detects errors. Turns off "apply". +

+
+
+--index +
+
+

+ When --check is in effect, or when applying the patch + (which is the default when none of the options that + disables it is in effect), make sure the patch is + applicable to what the current index file records. If + the file to be patched in the work tree is not + up-to-date, it is flagged as an error. This flag also + causes the index file to be updated. +

+
+
+--index-info +
+
+

+ Newer git-diff output has embedded index information + for each blob to help identify the original version that + the patch applies to. When this flag is given, and if + the original version of the blob is available locally, + outputs information about them to the standard output. +

+
+
+-z +
+
+

+ When showing the index information, do not munge paths, + but use NUL terminated machine readable format. Without + this flag, the pathnames output will have TAB, LF, and + backslash characters replaced with \t, \n, and \\, + respectively. +

+
+
+--apply +
+
+

+ If you use any of the options marked “Turns off + "apply"” above, git-apply reads and outputs the + information you asked without actually applying the + patch. Give this flag after those flags to also apply + the patch. +

+
+
+--no-add +
+
+

+ When applying a patch, ignore additions made by the + patch. This can be used to extract common part between + two files by first running diff on them and applying + the result with this option, which would apply the + deletion part but not addition part. +

+
+
+--allow-binary-replacement +
+
+

+ When applying a patch, which is a git-enhanced patch + that was prepared to record the pre- and post-image object + name in full, and the path being patched exactly matches + the object the patch applies to (i.e. "index" line's + pre-image object name is what is in the working tree), + and the post-image object is available in the object + database, use the post-image object as the patch + result. This allows binary files to be patched in a + very limited way. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

Documentation by Junio C Hamano

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-apply.txt b/git-apply.txt new file mode 100644 index 00000000..626e2815 --- /dev/null +++ b/git-apply.txt @@ -0,0 +1,104 @@ +git-apply(1) +============ + +NAME +---- +git-apply - Apply patch on a git index file and a work tree + + +SYNOPSIS +-------- +'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [...] + +DESCRIPTION +----------- +Reads supplied diff output and applies it on a git index file +and a work tree. + +OPTIONS +------- +...:: + The files to read patch from. '-' can be used to read + from the standard input. + +--stat:: + Instead of applying the patch, output diffstat for the + input. Turns off "apply". + +--numstat:: + Similar to \--stat, but shows number of added and + deleted lines in decimal notation and pathname without + abbreviation, to make it more machine friendly. Turns + off "apply". + +--summary:: + Instead of applying the patch, output a condensed + summary of information obtained from git diff extended + headers, such as creations, renames and mode changes. + Turns off "apply". + +--check:: + Instead of applying the patch, see if the patch is + applicable to the current work tree and/or the index + file and detects errors. Turns off "apply". + +--index:: + When --check is in effect, or when applying the patch + (which is the default when none of the options that + disables it is in effect), make sure the patch is + applicable to what the current index file records. If + the file to be patched in the work tree is not + up-to-date, it is flagged as an error. This flag also + causes the index file to be updated. + +--index-info:: + Newer git-diff output has embedded 'index information' + for each blob to help identify the original version that + the patch applies to. When this flag is given, and if + the original version of the blob is available locally, + outputs information about them to the standard output. + +-z:: + When showing the index information, do not munge paths, + but use NUL terminated machine readable format. Without + this flag, the pathnames output will have TAB, LF, and + backslash characters replaced with `\t`, `\n`, and `\\`, + respectively. + +--apply:: + If you use any of the options marked ``Turns off + "apply"'' above, git-apply reads and outputs the + information you asked without actually applying the + patch. Give this flag after those flags to also apply + the patch. + +--no-add:: + When applying a patch, ignore additions made by the + patch. This can be used to extract common part between + two files by first running `diff` on them and applying + the result with this option, which would apply the + deletion part but not addition part. + +--allow-binary-replacement:: + When applying a patch, which is a git-enhanced patch + that was prepared to record the pre- and post-image object + name in full, and the path being patched exactly matches + the object the patch applies to (i.e. "index" line's + pre-image object name is what is in the working tree), + and the post-image object is available in the object + database, use the post-image object as the patch + result. This allows binary files to be patched in a + very limited way. + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-applymbox.html b/git-applymbox.html new file mode 100644 index 00000000..9c83ace0 --- /dev/null +++ b/git-applymbox.html @@ -0,0 +1,398 @@ + + + + + + +git-applymbox(1) + + + +

SYNOPSIS

+
+

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

+
+

DESCRIPTION

+
+

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

+
+

OPTIONS

+
+
+
+-q +
+
+

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

+
+
+-k +
+
+

+ Usually the program cleans up the Subject: header line + to extract the title line for the commit log message, + among which (1) remove Re: or re:, (2) leading + whitespaces, (3) [ up to ], typically [PATCH], and + then prepends "[PATCH] ". This flag forbids this + munging, and is most useful when used to read back git + format-patch --mbox output. +

+
+
+-m +
+
+

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

+
+
+-u +
+
+

+ By default, the commit log message, author name and + author email are taken from the e-mail without any + charset conversion, after minimally decoding MIME + transfer encoding. This flag causes the resulting + commit to be encoded in utf-8 by transliterating them. + Note that the patch is always used as is without charset + conversion, even with this flag. +

+
+
+-c .dotest/<num> +
+
+

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

+
+
+<mbox> +
+
+

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

+
+
+<signoff> +
+
+

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

+
+
+
+

SEE ALSO

+
+

git-am(1), git-applypatch(1).

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-applymbox.txt b/git-applymbox.txt new file mode 100644 index 00000000..f74c6a49 --- /dev/null +++ b/git-applymbox.txt @@ -0,0 +1,92 @@ +git-applymbox(1) +================ + +NAME +---- +git-applymbox - Apply a series of patches in a mailbox + + +SYNOPSIS +-------- +'git-applymbox' [-u] [-k] [-q] [-m] ( -c .dotest/ | ) [ ] + +DESCRIPTION +----------- +Splits mail messages in a mailbox into commit log message, +authorship information and patches, and applies them to the +current branch. + + +OPTIONS +------- +-q:: + Apply patches interactively. The user will be given + opportunity to edit the log message and the patch before + attempting to apply it. + +-k:: + Usually the program 'cleans up' the Subject: header line + to extract the title line for the commit log message, + among which (1) remove 'Re:' or 're:', (2) leading + whitespaces, (3) '[' up to ']', typically '[PATCH]', and + then prepends "[PATCH] ". This flag forbids this + munging, and is most useful when used to read back 'git + format-patch --mbox' output. + +-m:: + Patches are applied with `git-apply` command, and unless + it cleanly applies without fuzz, the processing fails. + With this flag, if a tree that the patch applies cleanly + is found in a repository, the patch is applied to the + tree and then a 3-way merge between the resulting tree + and the current tree. + +-u:: + By default, the commit log message, author name and + author email are taken from the e-mail without any + charset conversion, after minimally decoding MIME + transfer encoding. This flag causes the resulting + commit to be encoded in utf-8 by transliterating them. + Note that the patch is always used as is without charset + conversion, even with this flag. + +-c .dotest/:: + When the patch contained in an e-mail does not cleanly + apply, the command exits with an error message. The + patch and extracted message are found in .dotest/, and + you could re-run 'git applymbox' with '-c .dotest/' + flag to restart the process after inspecting and fixing + them. + +:: + The name of the file that contains the e-mail messages + with patches. This file should be in the UNIX mailbox + format. See 'SubmittingPatches' document to learn about + the formatting convention for e-mail submission. + +:: + The name of the file that contains your "Signed-off-by" + line. See 'SubmittingPatches' document to learn what + "Signed-off-by" line means. You can also just say + 'yes', 'true', 'me', or 'please' to use an automatically + generated "Signed-off-by" line based on your committer + identity. + + +SEE ALSO +-------- +gitlink:git-am[1], gitlink:git-applypatch[1]. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-applypatch.html b/git-applypatch.html new file mode 100644 index 00000000..21551645 --- /dev/null +++ b/git-applypatch.html @@ -0,0 +1,336 @@ + + + + + + +git-applypatch(1) + + + +

SYNOPSIS

+
+

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

+
+

DESCRIPTION

+
+

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

+

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

+
+

OPTIONS

+
+
+
+<msg> +
+
+

+ Commit log message (sans the first line, which comes + from e-mail Subject stored in <info>). +

+
+
+<patch> +
+
+

+ The patch to apply. +

+
+
+<info> +
+
+

+ Author and subject information extracted from e-mail, + used on "author" line and as the first line of the + commit log message. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-applypatch.txt b/git-applypatch.txt new file mode 100644 index 00000000..5b9037de --- /dev/null +++ b/git-applypatch.txt @@ -0,0 +1,50 @@ +git-applypatch(1) +================= + +NAME +---- +git-applypatch - Apply one patch extracted from an e-mail. + + +SYNOPSIS +-------- +'git-applypatch' [] + +DESCRIPTION +----------- +Takes three files , , and prepared from an +e-mail message by 'git-mailinfo', and creates a commit. It is +usually not necessary to use this command directly. + +This command can run `applypatch-msg`, `pre-applypatch`, and +`post-applypatch` hooks. See link:hooks.html[hooks] for more +information. + + +OPTIONS +------- +:: + Commit log message (sans the first line, which comes + from e-mail Subject stored in ). + +:: + The patch to apply. + +:: + Author and subject information extracted from e-mail, + used on "author" line and as the first line of the + commit log message. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-archimport.html b/git-archimport.html new file mode 100644 index 00000000..c9046603 --- /dev/null +++ b/git-archimport.html @@ -0,0 +1,417 @@ + + + + + + +git-archimport(1) + + + +

SYNOPSIS

+
+

git-archimport [ -h ] [ -v ] [ -o ] [ -a ] [ -f ] [ -T ] + [ -D depth ] [ -t tempdir ] + <archive/branch> [ <archive/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> +parameters suppplied. If it cannot find the remote branch a merge comes from +it will just import it as a regular commit. If it can find it, it will mark it +as a merge whenever possible (see discussion below).

+

The script expects you to provide the key roots where it can start the import +from an initial import or tag type of Arch commit. It will follow and +import new branches within the provided roots.

+

It expects to be dealing with one project only. If it sees +branches that have different roots, it will refuse to run. In that case, +edit your <archive/branch> parameters to define clearly the scope of the +import.

+

git-archimport uses tla extensively in the background to access the +Arch repository. +Make sure you have a recent version of tla available in the path. tla must +know about the repositories you pass to git-archimport.

+

For the initial import git-archimport expects to find itself in an empty +directory. To follow the development of a project that uses Arch, rerun +git-archimport with the same parameters as the initial import to perform +incremental imports.

+
+

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 +branch incorporates all the commits since the point they forked. The end result +is that git will have a good idea of how far branches have diverged. So the +import process does lose some patch-trading metadata.

+

Fortunately, when you try and merge branches imported from Arch, +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

+
+
+
+-h +
+
+

+ Display usage. +

+
+
+-v +
+
+

+ Verbose output. +

+
+
+-T +
+
+

+ Many tags. Will create a tag for every commit, reflecting the commit + name in the Arch repository. +

+
+
+-f +
+
+

+ Use the fast patchset import strategy. This can be significantly + faster for large trees, but cannot handle directory renames or + permissions changes. The default strategy is slow and safe. +

+
+
+-o +
+
+

+ Use this for compatibility with old-style branch names used by + earlier versions of git-archimport. Old-style branch names + were category--branch, whereas new-style branch names are + archive,category--branch--version. +

+
+
+-D <depth> +
+
+

+ Follow merge ancestry and attempt to import trees that have been + merged from. Specify a depth greater than 1 if patch logs have been + pruned. +

+
+
+-a +
+
+

+ Attempt to auto-register archives at http://mirrors.sourcecontrol.net + This is particularly useful with the -D option. +

+
+
+-t <tmpdir> +
+
+

+ Override the default tempdir. +

+
+
+<archive/branch> +
+
+

+ Archive/branch identifier in a format that tla log understands. +

+
+
+
+

Author

+
+

Written by Martin Langhoff <martin@catalyst.net.nz>.

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-archimport.txt b/git-archimport.txt new file mode 100644 index 00000000..a2bd788f --- /dev/null +++ b/git-archimport.txt @@ -0,0 +1,106 @@ +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 ] + [ ] + +DESCRIPTION +----------- +Imports a project from one or more Arch repositories. It will follow branches +and repositories within the namespaces defined by the +parameters suppplied. If it cannot find the remote branch a merge comes from +it will just import it as a regular commit. If it can find it, it will mark it +as a merge whenever possible (see discussion below). + +The script expects you to provide the key roots where it can start the import +from an 'initial import' or 'tag' type of Arch commit. It will follow and +import new branches within the provided roots. + +It expects to be dealing with one project only. If it sees +branches that have different roots, it will refuse to run. In that case, +edit your parameters to define clearly the scope of the +import. + +`git-archimport` uses `tla` extensively in the background to access the +Arch repository. +Make sure you have a recent version of `tla` available in the path. `tla` must +know about the repositories you pass to `git-archimport`. + +For the initial import `git-archimport` expects to find itself in an empty +directory. To follow the development of a project that uses Arch, rerun +`git-archimport` with the same parameters as the initial import to perform +incremental imports. + +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 +branch incorporates all the commits since the point they forked. The end result +is that git will have a good idea of how far branches have diverged. So the +import process does lose some patch-trading metadata. + +Fortunately, when you try and merge branches imported from Arch, +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 +------- + +-h:: + Display usage. + +-v:: + Verbose output. + +-T:: + Many tags. Will create a tag for every commit, reflecting the commit + name in the Arch repository. + +-f:: + Use the fast patchset import strategy. This can be significantly + faster for large trees, but cannot handle directory renames or + permissions changes. The default strategy is slow and safe. + +-o:: + Use this for compatibility with old-style branch names used by + earlier versions of git-archimport. Old-style branch names + were category--branch, whereas new-style branch names are + archive,category--branch--version. + +-D :: + Follow merge ancestry and attempt to import trees that have been + merged from. Specify a depth greater than 1 if patch logs have been + pruned. + +-a:: + Attempt to auto-register archives at http://mirrors.sourcecontrol.net + This is particularly useful with the -D option. + +-t :: + Override the default tempdir. + + +:: + Archive/branch identifier in a format that `tla log` understands. + + +Author +------ +Written by Martin Langhoff . + +Documentation +-------------- +Documentation by Junio C Hamano, Martin Langhoff and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-bisect.html b/git-bisect.html new file mode 100644 index 00000000..36659105 --- /dev/null +++ b/git-bisect.html @@ -0,0 +1,392 @@ + + + + + + +git-bisect(1) + + + +

SYNOPSIS

+
+

git bisect <subcommand> <options>

+
+

DESCRIPTION

+
+

The command takes various subcommands, and different options +depending on the subcommand:

+
+
+
git bisect start [<paths>...]
+git bisect bad <rev>
+git bisect good <rev>
+git bisect reset [<branch>]
+git bisect visualize
+git bisect replay <logfile>
+git bisect log
+
+

This command uses git-rev-list --bisect option to help drive +the binary search process to find which change introduced a bug, +given an old "good" commit object name and a later "bad" commit +object name.

+

The way you use it is:

+
+
+
$ git bisect start
+$ git bisect bad                        # Current version is bad
+$ git bisect good v2.6.13-rc2           # v2.6.13-rc2 was the last version
+                                        # tested that was good
+
+

When you give at least one bad and one good versions, it will +bisect the revision tree and say something like:

+
+
+
Bisecting: 675 revisions left to test after this
+
+

and check out the state in the middle. Now, compile that kernel, and boot +it. Now, let's say that this booted kernel works fine, then just do

+
+
+
$ git bisect good                       # this one is good
+
+

which will now say

+
+
+
Bisecting: 337 revisions left to test after this
+
+

and you continue along, compiling that one, testing it, and depending on +whether it is good or bad, you say "git bisect good" or "git bisect bad", +and ask for the next bisection.

+

Until you have no more left, and you'll have been left with the first bad +kernel rev in "refs/bisect/bad".

+

Oh, and then after you want to reset to the original head, do a

+
+
+
$ git bisect reset
+
+

to get back to the master branch, instead of being in one of the bisection +branches ("git bisect start" will do that for you too, actually: it will +reset the bisection state, and before it does that it checks that you're +not using some old bisection branch).

+

During the bisection process, you can say

+
+
+
$ git bisect visualize
+
+

to see the currently remaining suspects in gitk.

+

The good/bad input is logged, and git bisect +log shows what you have done so far. You can truncate its +output somewhere and save it in a file, and run

+
+
+
$ git bisect replay that-file
+
+

if you find later you made a mistake telling good/bad about a +revision.

+

If in a middle of bisect session, you know what the bisect +suggested to try next is not a good one to test (e.g. the change +the commit introduces is known not to work in your environment +and you know it does not have anything to do with the bug you +are chasing), you may want to find a near-by commit and try that +instead. It goes something like this:

+
+
+
$ git bisect good/bad                   # previous round was good/bad.
+Bisecting: 337 revisions left to test after this
+$ git bisect visualize                  # oops, that is uninteresting.
+$ git reset --hard HEAD~3               # try 3 revs before what
+                                        # was suggested
+
+

Then compile and test the one you chose to try. After that, +tell bisect what the result was as usual.

+

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 giving paths parameters when you say bisect start, +like this:

+
+
+
$ git bisect start arch/i386 include/asm-i386
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-bisect.txt b/git-bisect.txt new file mode 100644 index 00000000..ac4b4965 --- /dev/null +++ b/git-bisect.txt @@ -0,0 +1,136 @@ +git-bisect(1) +============= + +NAME +---- +git-bisect - Find the change that introduced a bug + + +SYNOPSIS +-------- +'git bisect' + +DESCRIPTION +----------- +The command takes various subcommands, and different options +depending on the subcommand: + + git bisect start [...] + git bisect bad + git bisect good + git bisect reset [] + git bisect visualize + git bisect replay + git bisect log + +This command uses 'git-rev-list --bisect' option to help drive +the binary search process to find which change introduced a bug, +given an old "good" commit object name and a later "bad" commit +object name. + +The way you use it is: + +------------------------------------------------ +$ git bisect start +$ git bisect bad # Current version is bad +$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version + # tested that was good +------------------------------------------------ + +When you give at least one bad and one good versions, it will +bisect the revision tree and say something like: + +------------------------------------------------ +Bisecting: 675 revisions left to test after this +------------------------------------------------ + +and check out the state in the middle. Now, compile that kernel, and boot +it. Now, let's say that this booted kernel works fine, then just do + +------------------------------------------------ +$ git bisect good # this one is good +------------------------------------------------ + +which will now say + +------------------------------------------------ +Bisecting: 337 revisions left to test after this +------------------------------------------------ + +and you continue along, compiling that one, testing it, and depending on +whether it is good or bad, you say "git bisect good" or "git bisect bad", +and ask for the next bisection. + +Until you have no more left, and you'll have been left with the first bad +kernel rev in "refs/bisect/bad". + +Oh, and then after you want to reset to the original head, do a + +------------------------------------------------ +$ git bisect reset +------------------------------------------------ + +to get back to the master branch, instead of being in one of the bisection +branches ("git bisect start" will do that for you too, actually: it will +reset the bisection state, and before it does that it checks that you're +not using some old bisection branch). + +During the bisection process, you can say + +------------ +$ git bisect visualize +------------ + +to see the currently remaining suspects in `gitk`. + +The good/bad input is logged, and `git bisect +log` shows what you have done so far. You can truncate its +output somewhere and save it in a file, and run + +------------ +$ git bisect replay that-file +------------ + +if you find later you made a mistake telling good/bad about a +revision. + +If in a middle of bisect session, you know what the bisect +suggested to try next is not a good one to test (e.g. the change +the commit introduces is known not to work in your environment +and you know it does not have anything to do with the bug you +are chasing), you may want to find a near-by commit and try that +instead. It goes something like this: + +------------ +$ git bisect good/bad # previous round was good/bad. +Bisecting: 337 revisions left to test after this +$ git bisect visualize # oops, that is uninteresting. +$ git reset --hard HEAD~3 # try 3 revs before what + # was suggested +------------ + +Then compile and test the one you chose to try. After that, +tell bisect what the result was as usual. + +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 giving paths parameters when you say `bisect start`, +like this: + +------------ +$ git bisect start arch/i386 include/asm-i386 +------------ + + +Author +------ +Written by Linus Torvalds + +Documentation +------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-branch.html b/git-branch.html new file mode 100644 index 00000000..fb41e087 --- /dev/null +++ b/git-branch.html @@ -0,0 +1,371 @@ + + + + + + +git-branch(1) + + + +

SYNOPSIS

+
+

git-branch [-d | -D] [<branchname> [start-point]]

+
+

DESCRIPTION

+
+

If no argument is provided, show available branches and mark current +branch with star. Otherwise, create a new branch of name <branchname>.

+

If a starting point is also specified, that will be where the branch is +created, otherwise it will be created at the current HEAD.

+
+

OPTIONS

+
+
+
+-d +
+
+

+ Delete a branch. The branch must be fully merged. +

+
+
+-D +
+
+

+ Delete a branch irrespective of its index status. +

+
+
+<branchname> +
+
+

+ The name of the branch to create or delete. +

+
+
+start-point +
+
+

+ Where to create the branch; defaults to HEAD. This + option has no meaning with -d and -D. +

+
+
+

Examples

+
+
+Start development off of a know 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 (1)
+$ git checkout my2.6.14
+
+(1) These two steps are the same as "checkout -b my2.6.14 v2.6.14".
+
+
+
+Delete unneeded branch +
+
+
+
+
$ git clone git://git.kernel.org/.../git.git my.git
+$ cd my.git
+$ git branch -D todo (1)
+
+(1) delete todo branch even if the "master" branch does not have all
+commits from todo branch.
+
+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-branch.txt b/git-branch.txt new file mode 100644 index 00000000..d20b4757 --- /dev/null +++ b/git-branch.txt @@ -0,0 +1,72 @@ +git-branch(1) +============= + +NAME +---- +git-branch - Create a new branch, or remove an old one. + +SYNOPSIS +-------- +'git-branch' [-d | -D] [ [start-point]] + +DESCRIPTION +----------- +If no argument is provided, show available branches and mark current +branch with star. Otherwise, create a new branch of name . + +If a starting point is also specified, that will be where the branch is +created, otherwise it will be created at the current HEAD. + +OPTIONS +------- +-d:: + Delete a branch. The branch must be fully merged. + +-D:: + Delete a branch irrespective of its index status. + +:: + The name of the branch to create or delete. + +start-point:: + Where to create the branch; defaults to HEAD. This + option has no meaning with -d and -D. + + +Examples +~~~~~~~~ + +Start development off of a know 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 <1> +$ git checkout my2.6.14 + +<1> These two steps are the same as "checkout -b my2.6.14 v2.6.14". +------------ + +Delete unneeded branch:: ++ +------------ +$ git clone git://git.kernel.org/.../git.git my.git +$ cd my.git +$ git branch -D todo <1> + +<1> delete todo branch even if the "master" branch does not have all +commits from todo branch. +------------ + +Author +------ +Written by Linus Torvalds and Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-cat-file.html b/git-cat-file.html new file mode 100644 index 00000000..00b05e3b --- /dev/null +++ b/git-cat-file.html @@ -0,0 +1,362 @@ + + + + + + +git-cat-file(1) + + + +

SYNOPSIS

+
+

git-cat-file (-t | -s | -e | <type>) <object>

+
+

DESCRIPTION

+
+

Provides content or type of objects in the repository. The type +is required unless -t is used to find the object type, +or -s is used to find the object size.

+
+

OPTIONS

+
+
+
+<object> +
+
+

+ The sha1 identifier of the object. +

+
+
+-t +
+
+

+ Instead of the content, show the object type identified by + <object>. +

+
+
+-s +
+
+

+ Instead of the content, show the object size identified by + <object>. +

+
+
+-e +
+
+

+ Suppress all output; instead exit with zero status if <object> + exists and is a valid object. +

+
+
+<type> +
+
+

+ Typically this matches the real type of <object> but asking + for a type that can trivially be dereferenced from the given + <object> is also permitted. An example is to ask for a + "tree" with <object> being a commit object that contains it, + or to ask for a "blob" with <object> being a tag object that + points at it. +

+
+
+
+

OUTPUT

+
+

If -t is specified, one of the <type>.

+

If -s is specified, the size of the <object> in bytes.

+

If -e is specified, no output.

+

Otherwise the raw (though uncompressed) contents of the <object> will +be returned.

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-cat-file.txt b/git-cat-file.txt new file mode 100644 index 00000000..9a7700fa --- /dev/null +++ b/git-cat-file.txt @@ -0,0 +1,67 @@ +git-cat-file(1) +=============== + +NAME +---- +git-cat-file - Provide content or type information for repository objects + + +SYNOPSIS +-------- +'git-cat-file' (-t | -s | -e | ) + +DESCRIPTION +----------- +Provides content or type of objects in the repository. The type +is required unless '-t' is used to find the object type, +or '-s' is used to find the object size. + +OPTIONS +------- +:: + The sha1 identifier of the object. + +-t:: + Instead of the content, show the object type identified by + . + +-s:: + Instead of the content, show the object size identified by + . + +-e:: + Suppress all output; instead exit with zero status if + exists and is a valid object. + +:: + Typically this matches the real type of but asking + for a type that can trivially be dereferenced from the given + is also permitted. An example is to ask for a + "tree" with being a commit object that contains it, + or to ask for a "blob" with being a tag object that + points at it. + +OUTPUT +------ +If '-t' is specified, one of the . + +If '-s' is specified, the size of the in bytes. + +If '-e' is specified, no output. + +Otherwise the raw (though uncompressed) contents of the will +be returned. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-check-ref-format.html b/git-check-ref-format.html new file mode 100644 index 00000000..fe0b6cad --- /dev/null +++ b/git-check-ref-format.html @@ -0,0 +1,347 @@ + + + + + + +git-check-ref-format(1) + + + +

SYNOPSIS

+
+

git-check-ref-format <refname>

+
+

DESCRIPTION

+
+

Checks if a given refname is acceptable, and exits non-zero if +it is not.

+

A reference is used in git to specify branches and tags. A +branch head is stored under $GIT_DIR/refs/heads directory, and +a tag is stored under $GIT_DIR/refs/tags directory. git +imposes the following rules on how refs are named:

+
    +
  1. +

    +It could be named hierarchically (i.e. separated with slash + /), but each of its component cannot begin with a dot .; +

    +
    2. +
  2. +

    +It cannot have two consecutive dots .. anywhere; +

    +
    3. +
  3. +

    +It cannot have ASCII control character (i.e. bytes whose + values are lower than \040, or \177 DEL), space, tilde ~, + caret ^, colon :, question-mark ?, asterisk *, + or open bracket [ anywhere; +

    +
    4. +
  4. +

    +It cannot end with a slash /. +

    +
    5. +
+

These rules makes it easy for shell script based tools to parse +refnames, pathname expansion by the shell when a refname is used +unquoted (by mistake), and also avoids ambiguities in certain +refname expressions (see git-rev-parse(1)). Namely:

+
    +
  1. +

    +double-dot .. are often used as in ref1..ref2, and in some + context this notation means ^ref1 ref2 (i.e. not in + ref1 and in ref2). +

    +
    2. +
  2. +

    +tilde ~ and caret ^ are used to introduce postfix + nth parent and peel onion operation. +

    +
    3. +
  3. +

    +colon : is used as in srcref:dstref to mean "use srcref's + value and store it in dstref" in fetch and push operations. +

    +
    4. +
+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-check-ref-format.txt b/git-check-ref-format.txt new file mode 100644 index 00000000..f7f84c64 --- /dev/null +++ b/git-check-ref-format.txt @@ -0,0 +1,52 @@ +git-check-ref-format(1) +======================= + +NAME +---- +git-check-ref-format - Make sure ref name is well formed. + +SYNOPSIS +-------- +'git-check-ref-format' + +DESCRIPTION +----------- +Checks if a given 'refname' is acceptable, and exits non-zero if +it is not. + +A reference is used in git to specify branches and tags. A +branch head is stored under `$GIT_DIR/refs/heads` directory, and +a tag is stored under `$GIT_DIR/refs/tags` directory. git +imposes the following rules on how refs are named: + +. It could be named hierarchically (i.e. separated with slash + `/`), but each of its component cannot begin with a dot `.`; + +. It cannot have two consecutive dots `..` anywhere; + +. It cannot have ASCII control character (i.e. bytes whose + values are lower than \040, or \177 `DEL`), space, tilde `~`, + caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, + or open bracket `[` anywhere; + +. It cannot end with a slash `/`. + +These rules makes it easy for shell script based tools to parse +refnames, pathname expansion by the shell when a refname is used +unquoted (by mistake), and also avoids ambiguities in certain +refname expressions (see gitlink:git-rev-parse[1]). Namely: + +. double-dot `..` are often used as in `ref1..ref2`, and in some + context this notation means `{caret}ref1 ref2` (i.e. not in + ref1 and in ref2). + +. tilde `~` and caret `{caret}` are used to introduce postfix + 'nth parent' and 'peel onion' operation. + +. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s + value and store it in dstref" in fetch and push operations. + + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-checkout-index.html b/git-checkout-index.html new file mode 100644 index 00000000..68483bd3 --- /dev/null +++ b/git-checkout-index.html @@ -0,0 +1,437 @@ + + + + + + +git-checkout-index(1) + + + +

SYNOPSIS

+
+

git-checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] + [--stage=<number>] [--] <file>…

+
+

DESCRIPTION

+
+

Will copy all files listed from the index to the working directory +(not overwriting existing files).

+
+

OPTIONS

+
+
+
+-u|--index +
+
+

+ update stat information for the checked out entries in + the index file. +

+
+
+-q|--quiet +
+
+

+ be quiet if files exist or are not in the index +

+
+
+-f|--force +
+
+

+ forces overwrite of existing files +

+
+
+-a|--all +
+
+

+ checks out all files in the index. Cannot be used + together with explicit filenames. +

+
+
+-n|--no-create +
+
+

+ Don't checkout new files, only refresh files already checked + out. +

+
+
+--prefix=<string> +
+
+

+ When creating files, prepend <string> (usually a directory + including a trailing /) +

+
+
+--stage=<number> +
+
+

+ Instead of checking out unmerged entries, copy out the + files from named stage. <number> must be between 1 and 3. +

+
+
+— +
+
+

+ Do not interpret any more arguments as options. +

+
+
+

The order of the flags used to matter, but not anymore.

+

Just doing git-checkout-index does nothing. You probably meant +git-checkout-index -a. And if you want to force it, you want +git-checkout-index -f -a.

+

Intuitiveness is not the goal here. Repeatability is. The reason for +the "no arguments means no work" behavior is that from scripts you are +supposed to be able to do:

+
+
+
$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+
+

which will force all existing *.h files to be replaced with their +cached copies. If an empty command line implied "all", then this would +force-refresh everything in the index, which was not the point.

+

The -- is just a good idea when you know the rest will be filenames; +it will prevent problems with a filename of, for example, -a. +Using -- is probably a good policy in scripts.

+
+

EXAMPLES

+
+
+
+To update and refresh only the files already checked out +
+
+
+
+
$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+
+
+
+Using git-checkout-index to "export an entire tree" +
+
+

+ The prefix ability basically makes it trivial to use + git-checkout-index as an "export as tree" function. + Just read the desired tree into the index, and do: +

+
+
+
$ git-checkout-index --prefix=git-export-dir/ -a
+
+

git-checkout-index will "export" the index into the specified +directory.

+

The final "/" is important. The exported name is literally just +prefixed with the specified string. Contrast this with the +following example.

+
+
+Export files with a prefix +
+
+
+
+
$ git-checkout-index --prefix=.merged- Makefile
+
+

This will check out the currently cached copy of Makefile +into the file .merged-Makefile.

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-checkout-index.txt b/git-checkout-index.txt new file mode 100644 index 00000000..9f32c65a --- /dev/null +++ b/git-checkout-index.txt @@ -0,0 +1,121 @@ +git-checkout-index(1) +===================== + +NAME +---- +git-checkout-index - Copy files from the index to the working directory + + +SYNOPSIS +-------- +'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=] + [--stage=] [--] ... + +DESCRIPTION +----------- +Will copy all files listed from the index to the working directory +(not overwriting existing files). + +OPTIONS +------- +-u|--index:: + update stat information for the checked out entries in + the index file. + +-q|--quiet:: + be quiet if files exist or are not in the index + +-f|--force:: + forces overwrite of existing files + +-a|--all:: + checks out all files in the index. Cannot be used + together with explicit filenames. + +-n|--no-create:: + Don't checkout new files, only refresh files already checked + out. + +--prefix=:: + When creating files, prepend (usually a directory + including a trailing /) + +--stage=:: + Instead of checking out unmerged entries, copy out the + files from named stage. must be between 1 and 3. + +--:: + Do not interpret any more arguments as options. + +The order of the flags used to matter, but not anymore. + +Just doing `git-checkout-index` does nothing. You probably meant +`git-checkout-index -a`. And if you want to force it, you want +`git-checkout-index -f -a`. + +Intuitiveness is not the goal here. Repeatability is. The reason for +the "no arguments means no work" behavior is that from scripts you are +supposed to be able to do: + +---------------- +$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f -- +---------------- + +which will force all existing `*.h` files to be replaced with their +cached copies. If an empty command line implied "all", then this would +force-refresh everything in the index, which was not the point. + +The `--` is just a good idea when you know the rest will be filenames; +it will prevent problems with a filename of, for example, `-a`. +Using `--` is probably a good policy in scripts. + + +EXAMPLES +-------- +To update and refresh only the files already checked out:: ++ +---------------- +$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh +---------------- + +Using `git-checkout-index` to "export an entire tree":: + The prefix ability basically makes it trivial to use + `git-checkout-index` as an "export as tree" function. + Just read the desired tree into the index, and do: ++ +---------------- +$ git-checkout-index --prefix=git-export-dir/ -a +---------------- ++ +`git-checkout-index` will "export" the index into the specified +directory. ++ +The final "/" is important. The exported name is literally just +prefixed with the specified string. Contrast this with the +following example. + +Export files with a prefix:: ++ +---------------- +$ git-checkout-index --prefix=.merged- Makefile +---------------- ++ +This will check out the currently cached copy of `Makefile` +into the file `.merged-Makefile`. + + +Author +------ +Written by Linus Torvalds + + +Documentation +-------------- +Documentation by David Greaves, +Junio C Hamano and the git-list . + + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-checkout.html b/git-checkout.html new file mode 100644 index 00000000..5c06d7ab --- /dev/null +++ b/git-checkout.html @@ -0,0 +1,371 @@ + + + + + + +git-checkout(1) + + + +

SYNOPSIS

+
+

git-checkout [-f] [-b <new_branch>] [<branch>] [<paths>…]

+
+

DESCRIPTION

+
+

When <paths> are not given, this command switches branches, by +updating the index and working tree to reflect the specified +branch, <branch>, and updating HEAD to be <branch> or, if +specified, <new_branch>.

+

When <paths> are given, this command does not switch +branches. It updates the named paths in the working tree from +the index file (i.e. it runs git-checkout-index -f -u). In +this case, -f and -b options are meaningless and giving +either of them results in an error. <branch> argument can be +used to specify a specific tree-ish to update the index for the +given paths before updating the working tree.

+
+

OPTIONS

+
+
+
+-f +
+
+

+ Force an re-read of everything. +

+
+
+-b +
+
+

+ Create a new branch and start it at <branch>. +

+
+
+<new_branch> +
+
+

+ Name for the new branch. +

+
+
+<branch> +
+
+

+ Branch to checkout; may be any object ID that resolves to a + commit. Defaults to HEAD. +

+
+
+
+

EXAMPLE

+
+

The following sequence checks out the master branch, reverts +the Makefile to two revisions back, deletes hello.c by +mistake, and gets it back from the index.

+
+
+
$ git checkout master (1)
+$ git checkout master~2 Makefile (2)
+$ rm -f hello.c
+$ git checkout hello.c (3)
+
+(1) switch branch
+(2) take out a file out of other commit
+(3) or "git checkout -- hello.c", as in the next example.
+
+

If you have an unfortunate branch that is named hello.c, the +last step above would be confused as an instruction to switch to +that branch. You should instead write:

+
+
+
$ git checkout -- hello.c
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-checkout.txt b/git-checkout.txt new file mode 100644 index 00000000..9442c66b --- /dev/null +++ b/git-checkout.txt @@ -0,0 +1,83 @@ +git-checkout(1) +=============== + +NAME +---- +git-checkout - Checkout and switch to a branch. + +SYNOPSIS +-------- +'git-checkout' [-f] [-b ] [] [...] + +DESCRIPTION +----------- + +When are not given, this command switches branches, by +updating the index and working tree to reflect the specified +branch, , and updating HEAD to be or, if +specified, . + +When are given, this command does *not* switch +branches. It updates the named paths in the working tree from +the index file (i.e. it runs `git-checkout-index -f -u`). In +this case, `-f` and `-b` options are meaningless and giving +either of them results in an error. argument can be +used to specify a specific tree-ish to update the index for the +given paths before updating the working tree. + + +OPTIONS +------- +-f:: + Force an re-read of everything. + +-b:: + Create a new branch and start it at . + +:: + Name for the new branch. + +:: + Branch to checkout; may be any object ID that resolves to a + commit. Defaults to HEAD. + + +EXAMPLE +------- + +The following sequence checks out the `master` branch, reverts +the `Makefile` to two revisions back, deletes hello.c by +mistake, and gets it back from the index. + +------------ +$ git checkout master <1> +$ git checkout master~2 Makefile <2> +$ rm -f hello.c +$ git checkout hello.c <3> + +<1> switch branch +<2> take out a file out of other commit +<3> or "git checkout -- hello.c", as in the next example. +------------ + +If you have an unfortunate branch that is named `hello.c`, the +last step above would be confused as an instruction to switch to +that branch. You should instead write: + +------------ +$ git checkout -- hello.c +------------ + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-cherry-pick.html b/git-cherry-pick.html new file mode 100644 index 00000000..737ef56d --- /dev/null +++ b/git-cherry-pick.html @@ -0,0 +1,353 @@ + + + + + + +git-cherry-pick(1) + + + +

SYNOPSIS

+
+

git-cherry-pick [--edit] [-n] [-r] <commit>

+
+

DESCRIPTION

+
+

Given one existing commit, apply the change the patch introduces, and record a +new commit that records it. This requires your working tree to be clean (no +modifications from the HEAD commit).

+
+

OPTIONS

+
+
+
+<commit> +
+
+

+ Commit to cherry-pick. +

+
+
+-e|--edit +
+
+

+ With this option, git-cherry-pick will let you edit the commit + message prior committing. +

+
+
+-r|--replay +
+
+

+ Usually the command appends which commit was + cherry-picked after the original commit message when + making a commit. This option, --replay, causes it to + use the original commit message intact. This is useful + when you are reordering the patches in your private tree + before publishing. +

+
+
+-n|--no-commit +
+
+

+ Usually the command automatically creates a commit with + a commit log message stating which commit was + cherry-picked. This flag applies the change necessary + to cherry-pick the named commit to your working tree, + but does not make the commit. In addition, when this + option is used, your working tree does not have to match + the HEAD commit. The cherry-pick is done against the + beginning state of your working tree. +

+

This is useful when cherry-picking more than one commits' +effect to your working tree in a row.

+
+
+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-cherry-pick.txt b/git-cherry-pick.txt new file mode 100644 index 00000000..4f323fa4 --- /dev/null +++ b/git-cherry-pick.txt @@ -0,0 +1,60 @@ +git-cherry-pick(1) +================== + +NAME +---- +git-cherry-pick - Apply the change introduced by an existing commit. + +SYNOPSIS +-------- +'git-cherry-pick' [--edit] [-n] [-r] + +DESCRIPTION +----------- +Given one existing commit, apply the change the patch introduces, and record a +new commit that records it. This requires your working tree to be clean (no +modifications from the HEAD commit). + +OPTIONS +------- +:: + Commit to cherry-pick. + +-e|--edit:: + With this option, `git-cherry-pick` will let you edit the commit + message prior committing. + +-r|--replay:: + Usually the command appends which commit was + cherry-picked after the original commit message when + making a commit. This option, '--replay', causes it to + use the original commit message intact. This is useful + when you are reordering the patches in your private tree + before publishing. + +-n|--no-commit:: + Usually the command automatically creates a commit with + a commit log message stating which commit was + cherry-picked. This flag applies the change necessary + to cherry-pick the named commit to your working tree, + but does not make the commit. In addition, when this + option is used, your working tree does not have to match + the HEAD commit. The cherry-pick is done against the + beginning state of your working tree. ++ +This is useful when cherry-picking more than one commits' +effect to your working tree in a row. + + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-cherry.html b/git-cherry.html new file mode 100644 index 00000000..a78b8e0e --- /dev/null +++ b/git-cherry.html @@ -0,0 +1,332 @@ + + + + + + +git-cherry(1) + + + +

SYNOPSIS

+
+

git-cherry [-v] <upstream> [<head>]

+
+

DESCRIPTION

+
+

Each commit between the fork-point and <head> is examined, and compared against +the change each commit between the fork-point and <upstream> introduces. +Commits already included in upstream are prefixed with - (meaning "drop from +my local pull"), while commits missing from upstream are prefixed with + +(meaning "add to the updated upstream").

+
+

OPTIONS

+
+
+
+-v +
+
+

+ Verbose. +

+
+
+<upstream> +
+
+

+ Upstream branch to compare against. +

+
+
+<head> +
+
+

+ Working branch; defaults to HEAD. +

+
+
+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-cherry.txt b/git-cherry.txt new file mode 100644 index 00000000..af87966e --- /dev/null +++ b/git-cherry.txt @@ -0,0 +1,42 @@ +git-cherry(1) +============= + +NAME +---- +git-cherry - Find commits not merged upstream. + +SYNOPSIS +-------- +'git-cherry' [-v] [] + +DESCRIPTION +----------- +Each commit between the fork-point and is examined, and compared against +the change each commit between the fork-point and introduces. +Commits already included in upstream are prefixed with '-' (meaning "drop from +my local pull"), while commits missing from upstream are prefixed with '+' +(meaning "add to the updated upstream"). + +OPTIONS +------- +-v:: + Verbose. + +:: + Upstream branch to compare against. + +:: + Working branch; defaults to HEAD. + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-clone-pack.html b/git-clone-pack.html new file mode 100644 index 00000000..a60c926d --- /dev/null +++ b/git-clone-pack.html @@ -0,0 +1,356 @@ + + + + + + +git-clone-pack(1) + + + +

SYNOPSIS

+
+

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

+
+

DESCRIPTION

+
+

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

+
+

OPTIONS

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

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

+
+
+<host> +
+
+

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

+
+
+<directory> +
+
+

+ The repository to sync from. +

+
+
+<head>… +
+
+

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

+

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

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

Documentation by Junio C Hamano.

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-clone-pack.txt b/git-clone-pack.txt new file mode 100644 index 00000000..39906fc4 --- /dev/null +++ b/git-clone-pack.txt @@ -0,0 +1,64 @@ +git-clone-pack(1) +================= + +NAME +---- +git-clone-pack - Clones a repository by receiving packed objects. + + +SYNOPSIS +-------- +'git-clone-pack' [--exec=] [:] [...] + +DESCRIPTION +----------- +Clones a repository into the current repository by invoking +'git-upload-pack', possibly on the remote host via ssh, in +the named repository, and stores the sent pack in the local +repository. + +OPTIONS +------- +--exec=:: + Use this to specify the path to 'git-upload-pack' on the + remote side, if it is not found on your $PATH. + Installations of sshd ignore the user's environment + setup scripts for login shells (e.g. .bash_profile) and + your privately installed git may not be found on the system + default $PATH. Another workaround suggested is to set + up your $PATH in ".bashrc", but this flag is for people + who do not want to pay the overhead for non-interactive + shells by having a lean .bashrc file (they set most of + the things up in .bash_profile). + +:: + A remote host that houses the repository. When this + part is specified, 'git-upload-pack' is invoked via + ssh. + +:: + The repository to sync from. + +...:: + The heads to update. This is relative to $GIT_DIR + (e.g. "HEAD", "refs/heads/master"). When unspecified, + all heads are updated to match the remote repository. ++ +Usually all the refs from existing repository are stored +under the same name in the new repository. Giving explicit + arguments instead writes the object names and refs to +the standard output, just like get-fetch-pack does. + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano. + + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-clone.html b/git-clone.html new file mode 100644 index 00000000..f83caa18 --- /dev/null +++ b/git-clone.html @@ -0,0 +1,441 @@ + + + + + + +git-clone(1) + + + +

SYNOPSIS

+
+

git-clone [-l [-s]] [-q] [-n] [-o <name>] [-u <upload-pack>] <repository> [<directory>]

+
+

DESCRIPTION

+
+

Clones a repository into a newly created directory. All remote +branch heads are copied under $GIT_DIR/refs/heads/, except +that the remote master is also copied to origin branch.

+

In addition, $GIT_DIR/remotes/origin file is set up to have +this line:

+
+
+
Pull: master:origin
+
+

This is to help the typical workflow of working off of the +remote master branch. Every time git pull without argument +is run, the progress on the remote master branch is tracked by +copying it into the local origin branch, and merged into the +branch you are currently working on. Remote branches other than +master are also added there to be tracked.

+
+

OPTIONS

+
+
+
+--local +
+
+-l +
+
+

+ When the repository to clone from is on a local machine, + this flag bypasses normal "git aware" transport + 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. +

+
+
+--shared +
+
+-s +
+
+

+ When the repository to clone is on the local machine, + instead of using hard links, automatically setup + .git/objects/info/alternatives to share the objects + with the source repository. The resulting repository + starts out without any object of its own. +

+
+
+--quiet +
+
+-q +
+
+

+ Operate quietly. This flag is passed to "rsync" and + "git-clone-pack" commands when given. +

+
+
+-n +
+
+

+ No checkout of HEAD is performed after the clone is complete. +

+
+
+-o <name> +
+
+

+ Instead of using the branch name origin to keep track + of the upstream repository, use <name> instead. Note + that the shorthand name stored in remotes/origin is + not affected, but the local branch name to pull the + remote master branch into is. +

+
+
+--upload-pack <upload-pack> +
+
+-u <upload-pack> +
+
+

+ When given, and the repository to clone from is handled + by git-clone-pack, --exec=<upload-pack> is passed to + the command to specify non-default path for the command + run on the other end. +

+
+
+<repository> +
+
+

+ The (possibly remote) repository to clone from. It can + be any URL git-fetch supports. +

+
+
+<directory> +
+
+

+ The name of a new directory to clone into. The "humanish" + part of the source repository is used if no directory is + explicitly given ("repo" for "/path/to/repo.git" and "foo" + for "host.xz:foo/.git"). Cloning into an existing directory + is not allowed. +

+
+
+

Examples

+
+
+Clone from upstream +
+
+
+
+
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
+$ cd my2.6
+$ make
+
+
+
+Make a local clone that borrows from the current directory, without checking things out +
+
+
+
+
$ git clone -l -s -n . ../copy
+$ cd copy
+$ git show-branch
+
+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-clone.txt b/git-clone.txt new file mode 100644 index 00000000..f943f267 --- /dev/null +++ b/git-clone.txt @@ -0,0 +1,117 @@ +git-clone(1) +============ + +NAME +---- +git-clone - Clones a repository. + + +SYNOPSIS +-------- +'git-clone' [-l [-s]] [-q] [-n] [-o ] [-u ] [] + +DESCRIPTION +----------- +Clones a repository into a newly created directory. All remote +branch heads are copied under `$GIT_DIR/refs/heads/`, except +that the remote `master` is also copied to `origin` branch. + +In addition, `$GIT_DIR/remotes/origin` file is set up to have +this line: + + Pull: master:origin + +This is to help the typical workflow of working off of the +remote `master` branch. Every time `git pull` without argument +is run, the progress on the remote `master` branch is tracked by +copying it into the local `origin` branch, and merged into the +branch you are currently working on. Remote branches other than +`master` are also added there to be tracked. + + +OPTIONS +------- +--local:: +-l:: + When the repository to clone from is on a local machine, + this flag bypasses normal "git aware" transport + 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. + +--shared:: +-s:: + When the repository to clone is on the local machine, + instead of using hard links, automatically setup + .git/objects/info/alternatives to share the objects + with the source repository. The resulting repository + starts out without any object of its own. + +--quiet:: +-q:: + Operate quietly. This flag is passed to "rsync" and + "git-clone-pack" commands when given. + +-n:: + No checkout of HEAD is performed after the clone is complete. + +-o :: + Instead of using the branch name 'origin' to keep track + of the upstream repository, use instead. Note + that the shorthand name stored in `remotes/origin` is + not affected, but the local branch name to pull the + remote `master` branch into is. + +--upload-pack :: +-u :: + When given, and the repository to clone from is handled + by 'git-clone-pack', '--exec=' is passed to + the command to specify non-default path for the command + run on the other end. + +:: + The (possibly remote) repository to clone from. It can + be any URL git-fetch supports. + +:: + The name of a new directory to clone into. The "humanish" + part of the source repository is used if no directory is + explicitly given ("repo" for "/path/to/repo.git" and "foo" + for "host.xz:foo/.git"). Cloning into an existing directory + is not allowed. + +Examples +~~~~~~~~ + +Clone from upstream:: ++ +------------ +$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 +$ cd my2.6 +$ make +------------ + + +Make a local clone that borrows from the current directory, without checking things out:: ++ +------------ +$ git clone -l -s -n . ../copy +$ cd copy +$ git show-branch +------------ + +Author +------ +Written by Linus Torvalds + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-commit-tree.html b/git-commit-tree.html new file mode 100644 index 00000000..6e0bc36a --- /dev/null +++ b/git-commit-tree.html @@ -0,0 +1,409 @@ + + + + + + +git-commit-tree(1) + + + +

SYNOPSIS

+
+

git-commit-tree <tree> [-p <parent commit>]* < changelog

+
+

DESCRIPTION

+
+

Creates a new commit object based on the provided tree object and +emits the new commit object id on stdout. If no parent is given then +it is considered to be an initial tree.

+

A commit object usually has 1 parent (a commit after a change) or up +to 16 parents. More than one parent represents a merge of branches +that led to them.

+

While a tree represents a particular directory state of a working +directory, a commit represents that state in "time", and explains how +to get there.

+

Normally a commit would identify a new "HEAD" state, and while git +doesn't care where you save the note about that state, in practice we +tend to just write the result to the file that is pointed at by +.git/HEAD, so that we can always see what the last committed +state was.

+
+

OPTIONS

+
+
+
+<tree> +
+
+

+ An existing tree object +

+
+
+-p <parent commit> +
+
+

+ Each -p indicates the id of a parent commit object. +

+
+
+
+

Commit Information

+
+

A commit encapsulates:

+
    +
  • +

    +all parent object ids +

    +
    • +
  • +

    +author name, email and date +

    +
    • +
  • +

    +committer name and email and the commit time. +

    +
    • +
+

If not provided, "git-commit-tree" uses your name, hostname and domain to +provide author and committer info. This can be overridden by +either .git/config file, or using the following environment variables.

+
+
+
GIT_AUTHOR_NAME
+GIT_AUTHOR_EMAIL
+GIT_AUTHOR_DATE
+GIT_COMMITTER_NAME
+GIT_COMMITTER_EMAIL
+
+

(nb "<", ">" and "\n"s are stripped)

+

In .git/config file, the following items are used:

+
+
+
[user]
+        name = "Your Name"
+        email = "your@email.address.xz"
+
+

A commit comment is read from stdin (max 999 chars). If a changelog +entry is not provided via "<" redirection, "git-commit-tree" will just wait +for one to be entered and terminated with ^D.

+
+

Diagnostics

+
+
+
+You don't exist. Go away! +
+
+

+ The passwd(5) gecos field couldn't be read +

+
+
+Your parents must have hated you! +
+
+

+ The password(5) gecos field is longer than a giant static buffer. +

+
+
+Your sysadmin must hate you! +
+
+

+ The password(5) name field is longer than a giant static buffer. +

+
+
+
+

See Also

+
+

git-write-tree(1)

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-commit-tree.txt b/git-commit-tree.txt new file mode 100644 index 00000000..a794192d --- /dev/null +++ b/git-commit-tree.txt @@ -0,0 +1,99 @@ +git-commit-tree(1) +================== + +NAME +---- +git-commit-tree - Creates a new commit object + + +SYNOPSIS +-------- +'git-commit-tree' [-p ]\* < changelog + +DESCRIPTION +----------- +Creates a new commit object based on the provided tree object and +emits the new commit object id on stdout. If no parent is given then +it is considered to be an initial tree. + +A commit object usually has 1 parent (a commit after a change) or up +to 16 parents. More than one parent represents a merge of branches +that led to them. + +While a tree represents a particular directory state of a working +directory, a commit represents that state in "time", and explains how +to get there. + +Normally a commit would identify a new "HEAD" state, and while git +doesn't care where you save the note about that state, in practice we +tend to just write the result to the file that is pointed at by +`.git/HEAD`, so that we can always see what the last committed +state was. + +OPTIONS +------- +:: + An existing tree object + +-p :: + Each '-p' indicates the id of a parent commit object. + + +Commit Information +------------------ + +A commit encapsulates: + +- all parent object ids +- author name, email and date +- committer name and email and the commit time. + +If not provided, "git-commit-tree" uses your name, hostname and domain to +provide author and committer info. This can be overridden by +either `.git/config` file, or using the following environment variables. + + GIT_AUTHOR_NAME + GIT_AUTHOR_EMAIL + GIT_AUTHOR_DATE + GIT_COMMITTER_NAME + GIT_COMMITTER_EMAIL + +(nb "<", ">" and "\n"s are stripped) + +In `.git/config` file, the following items are used: + + [user] + name = "Your Name" + email = "your@email.address.xz" + +A commit comment is read from stdin (max 999 chars). If a changelog +entry is not provided via "<" redirection, "git-commit-tree" will just wait +for one to be entered and terminated with ^D. + + +Diagnostics +----------- +You don't exist. Go away!:: + The passwd(5) gecos field couldn't be read +Your parents must have hated you!:: + The password(5) gecos field is longer than a giant static buffer. +Your sysadmin must hate you!:: + The password(5) name field is longer than a giant static buffer. + +See Also +-------- +gitlink:git-write-tree[1] + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-commit.html b/git-commit.html new file mode 100644 index 00000000..7dfc3091 --- /dev/null +++ b/git-commit.html @@ -0,0 +1,402 @@ + + + + + + +git-commit(1) + + + +

SYNOPSIS

+
+

git-commit [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] [-e] [--] <file>…

+
+

DESCRIPTION

+
+

Updates the index file for given paths, or all modified files if +-a is specified, and makes a commit object. The command +VISUAL and EDITOR environment variables to edit the commit log +message.

+

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

+
+

OPTIONS

+
+
+
+-a|--all +
+
+

+ Update all paths in the index file. +

+
+
+-c or -C <commit> +
+
+

+ Take existing commit object, and reuse the log message + and the authorship information (including the timestamp) + when creating the commit. With -C, the editor is not + invoked; with -c the user can further edit the commit + message. +

+
+
+-F <file> +
+
+

+ Take the commit message from the given file. Use - to + read the message from the standard input. +

+
+
+-m <msg> +
+
+

+ Use the given <msg> as the commit message. +

+
+
+-s|--signoff +
+
+

+ Add Signed-off-by line at the end of the commit message. +

+
+
+-v|--verify +
+
+

+ Look for suspicious lines the commit introduces, and + abort committing if there is one. The definition of + suspicious lines is currently the lines that has + trailing whitespaces, and the lines whose indentation + has a SP character immediately followed by a TAB + character. This is the default. +

+
+
+-n|--no-verify +
+
+

+ The opposite of --verify. +

+
+
+-e|--edit +
+
+

+ The message taken from file with -F, command line with + -m, and from file with -C are usually used as the + commit log message unmodified. This option lets you + further edit the message taken from these sources. +

+
+
+— +
+
+

+ Do not interpret any more arguments as options. +

+
+
+<file>… +
+
+

+ Update specified paths in the index file before committing. +

+
+
+

If you make a commit and then found a mistake immediately after +that, you can recover from it with git-reset(1).

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <junkio@cox.net>

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-commit.txt b/git-commit.txt new file mode 100644 index 00000000..8b91f221 --- /dev/null +++ b/git-commit.txt @@ -0,0 +1,81 @@ +git-commit(1) +============= + +NAME +---- +git-commit - Record your changes + +SYNOPSIS +-------- +'git-commit' [-a] [-s] [-v] [(-c | -C) | -F | -m ] [-e] [--] ... + +DESCRIPTION +----------- +Updates the index file for given paths, or all modified files if +'-a' is specified, and makes a commit object. The command +VISUAL and EDITOR environment variables to edit the commit log +message. + +This command can run `commit-msg`, `pre-commit`, and +`post-commit` hooks. See link:hooks.html[hooks] for more +information. + +OPTIONS +------- +-a|--all:: + Update all paths in the index file. + +-c or -C :: + Take existing commit object, and reuse the log message + and the authorship information (including the timestamp) + when creating the commit. With '-C', the editor is not + invoked; with '-c' the user can further edit the commit + message. + +-F :: + Take the commit message from the given file. Use '-' to + read the message from the standard input. + +-m :: + Use the given as the commit message. + +-s|--signoff:: + Add Signed-off-by line at the end of the commit message. + +-v|--verify:: + Look for suspicious lines the commit introduces, and + abort committing if there is one. The definition of + 'suspicious lines' is currently the lines that has + trailing whitespaces, and the lines whose indentation + has a SP character immediately followed by a TAB + character. This is the default. + +-n|--no-verify:: + The opposite of `--verify`. + +-e|--edit:: + The message taken from file with `-F`, command line with + `-m`, and from file with `-C` are usually used as the + commit log message unmodified. This option lets you + further edit the message taken from these sources. + +--:: + Do not interpret any more arguments as options. + +...:: + Update specified paths in the index file before committing. + + +If you make a commit and then found a mistake immediately after +that, you can recover from it with gitlink:git-reset[1]. + + +Author +------ +Written by Linus Torvalds and +Junio C Hamano + + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-convert-objects.html b/git-convert-objects.html new file mode 100644 index 00000000..9d2d35a3 --- /dev/null +++ b/git-convert-objects.html @@ -0,0 +1,299 @@ + + + + + + +git-convert-objects(1) + + + +

SYNOPSIS

+
+

git-convert-objects

+
+

DESCRIPTION

+
+

Converts old-style git repository to the latest format

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-convert-objects.txt b/git-convert-objects.txt new file mode 100644 index 00000000..b1220c06 --- /dev/null +++ b/git-convert-objects.txt @@ -0,0 +1,29 @@ +git-convert-objects(1) +====================== + +NAME +---- +git-convert-objects - Converts old-style git repository + + +SYNOPSIS +-------- +'git-convert-objects' + +DESCRIPTION +----------- +Converts old-style git repository to the latest format + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-count-objects.html b/git-count-objects.html new file mode 100644 index 00000000..b084b6a4 --- /dev/null +++ b/git-count-objects.html @@ -0,0 +1,300 @@ + + + + + + +git-count-objects(1) + + + +

SYNOPSIS

+
+

git-count-objects

+
+

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.

+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-count-objects.txt b/git-count-objects.txt new file mode 100644 index 00000000..36888d98 --- /dev/null +++ b/git-count-objects.txt @@ -0,0 +1,28 @@ +git-count-objects(1) +==================== + +NAME +---- +git-count-objects - Reports on unpacked objects. + +SYNOPSIS +-------- +'git-count-objects' + +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. + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html new file mode 100644 index 00000000..bf23276c --- /dev/null +++ b/git-cvsexportcommit.html @@ -0,0 +1,339 @@ + + + + + + +git-cvsexportcommit(1) + + + +

SYNOPSIS

+
+

git-cvsexportcommmit.perl + [ -h ] [ -v ] [ -c ] [ -p ] [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.

+

Execute it from the root of the CVS working copy. GIT_DIR must be defined.

+

It does its best to do the safe thing, it will check that the files are +unchanged and up to date in the CVS checkout, and it will not autocommit +by default.

+

Supports file additions, removals, and commits that affect binary files.

+

If the commit is a merge commit, you must tell git-cvsapplycommit what parent +should the changeset be done against.

+
+

OPTIONS

+
+
+
+-c +
+
+

+ Commit automatically if the patch applied cleanly. It will not + commit if any hunks fail to apply or there were other problems. +

+
+
+-p +
+
+

+ Be pedantic (paranoid) when applying patches. Invokes patch with + --fuzz=0 +

+
+
+-v +
+
+

+ Verbose. +

+
+
+
+

Author

+
+

Written by Martin Langhoff <martin@catalyst.net.nz>

+
+

Documentation

+
+

Documentation by Martin Langhoff <martin@catalyst.net.nz>

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-cvsexportcommit.txt b/git-cvsexportcommit.txt new file mode 100644 index 00000000..91def2b5 --- /dev/null +++ b/git-cvsexportcommit.txt @@ -0,0 +1,56 @@ +git-cvsexportcommit(1) +====================== + +NAME +---- +git-cvsexportcommit - Export a commit to a CVS checkout + + +SYNOPSIS +-------- +git-cvsexportcommmit.perl + [ -h ] [ -v ] [ -c ] [ -p ] [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. + +Execute it from the root of the CVS working copy. GIT_DIR must be defined. + +It does its best to do the safe thing, it will check that the files are +unchanged and up to date in the CVS checkout, and it will not autocommit +by default. + +Supports file additions, removals, and commits that affect binary files. + +If the commit is a merge commit, you must tell git-cvsapplycommit what parent +should the changeset be done against. + +OPTIONS +------- + +-c:: + Commit automatically if the patch applied cleanly. It will not + commit if any hunks fail to apply or there were other problems. + +-p:: + Be pedantic (paranoid) when applying patches. Invokes patch with + --fuzz=0 + +-v:: + Verbose. + +Author +------ +Written by Martin Langhoff + +Documentation +-------------- +Documentation by Martin Langhoff + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-cvsimport.html b/git-cvsimport.html new file mode 100644 index 00000000..b3974f9a --- /dev/null +++ b/git-cvsimport.html @@ -0,0 +1,455 @@ + + + + + + +git-cvsimport(1) + + + +

SYNOPSIS

+
+

git-cvsimport [ -o <branch-for-HEAD> ] [ -h ] [ -v ] + [ -d <CVSROOT> ] [ -p <options-for-cvsps> ] + [ -C <git_repository> ] [ -i ] [ -P <file> ] [ -k ] + [ -s <subst> ] [ -m ] [ -M regex ] [ <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.

+
+

OPTIONS

+
+
+
+-d <CVSROOT> +
+
+

+ The root of the CVS archive. May be local (a simple path) or remote; + currently, only the :local:, :ext: and :pserver: access methods + are supported. +

+
+
+-C <target-dir> +
+
+

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

+
+
+-i +
+
+

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

+
+
+-k +
+
+

+ Kill keywords: will extract files with -kk from the CVS archive + to avoid noisy changesets. Highly recommended, but off by default + to preserve compatibility with early imported trees. +

+
+
+-u +
+
+

+ Convert underscores in tag and branch names to dots. +

+
+
+-o <branch-for-HEAD> +
+
+

+ The HEAD branch from CVS is imported to the origin branch within + the git repository, as HEAD already has a special meaning for git. + Use this option if you want to import into a different branch. +

+

Use -o master for continuing an import that was initially done by +the old cvs2git tool.

+
+
+-p <options-for-cvsps> +
+
+

+ Additional options for cvsps. + The options -u and -A are implicit and should not be used here. +

+

If you need to pass multiple options, separate them with a comma.

+
+
+-P <cvsps-output-file> +
+
+

+ Instead of calling cvsps, read the provided cvsps output file. Useful + for debugging or when cvsps is being handled outside cvsimport. +

+
+
+-m +
+
+

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

+
+
+-M <regex> +
+
+

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

+
+
+-v +
+
+

+ Verbosity: let cvsimport report what it is doing. +

+
+
+<CVS_module> +
+
+

+ The CVS module you want to import. Relative to <CVSROOT>. +

+
+
+-h +
+
+

+ Print a short usage message and exit. +

+
+
+-z <fuzz> +
+
+

+ Pass the timestamp fuzz factor to cvsps. +

+
+
+-s <subst> +
+
+

+ Substitute the character "/" in branch names with <subst> +

+
+
+
+

OUTPUT

+
+

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

+

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

+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-cvsimport.txt b/git-cvsimport.txt new file mode 100644 index 00000000..f89b251e --- /dev/null +++ b/git-cvsimport.txt @@ -0,0 +1,112 @@ +git-cvsimport(1) +================ + +NAME +---- +git-cvsimport - Import a CVS repository into git + + +SYNOPSIS +-------- +'git-cvsimport' [ -o ] [ -h ] [ -v ] + [ -d ] [ -p ] + [ -C ] [ -i ] [ -P ] [ -k ] + [ -s ] [ -m ] [ -M regex ] [ ] + + +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. + +OPTIONS +------- +-d :: + The root of the CVS archive. May be local (a simple path) or remote; + currently, only the :local:, :ext: and :pserver: access methods + are supported. + +-C :: + The git repository to import to. If the directory doesn't + exist, it will be created. Default is the current directory. + +-i:: + Import-only: don't perform a checkout after importing. This option + ensures the working directory and index remain untouched and will + not create them if they do not exist. + +-k:: + Kill keywords: will extract files with -kk from the CVS archive + to avoid noisy changesets. Highly recommended, but off by default + to preserve compatibility with early imported trees. + +-u:: + Convert underscores in tag and branch names to dots. + +-o :: + The 'HEAD' branch from CVS is imported to the 'origin' branch within + the git repository, as 'HEAD' already has a special meaning for git. + Use this option if you want to import into a different branch. ++ +Use '-o master' for continuing an import that was initially done by +the old cvs2git tool. + +-p :: + Additional options for cvsps. + The options '-u' and '-A' are implicit and should not be used here. ++ +If you need to pass multiple options, separate them with a comma. + +-P :: + Instead of calling cvsps, read the provided cvsps output file. Useful + for debugging or when cvsps is being handled outside cvsimport. + +-m:: + Attempt to detect merges based on the commit message. This option + will enable default regexes that try to capture the name source + branch name from the commit message. + +-M :: + Attempt to detect merges based on the commit message with a custom + regex. It can be used with -m to also see the default regexes. + You must escape forward slashes. + +-v:: + Verbosity: let 'cvsimport' report what it is doing. + +:: + The CVS module you want to import. Relative to . + +-h:: + Print a short usage message and exit. + +-z :: + Pass the timestamp fuzz factor to cvsps. + +-s :: + Substitute the character "/" in branch names with + +OUTPUT +------ +If '-v' is specified, the script reports what it is doing. + +Otherwise, success is indicated the Unix way, i.e. by simply exiting with +a zero exit status. + + +Author +------ +Written by Matthias Urlichs , with help from +various participants of the git-list . + +Documentation +-------------- +Documentation by Matthias Urlichs . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-daemon.html b/git-daemon.html new file mode 100644 index 00000000..7aecf640 --- /dev/null +++ b/git-daemon.html @@ -0,0 +1,400 @@ + + + + + + +git-daemon(1) + + + +

SYNOPSIS

+
+

git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all] + [--timeout=n] [--init-timeout=n] [--strict-paths] [directory…]

+
+

DESCRIPTION

+
+

A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" +aka 9418. It waits for a connection, and will just execute "git-upload-pack" +when it gets one.

+

It's careful in that there's a magic request-line that gives the command and +what directory to upload, and it verifies that the directory is ok.

+

It verifies that the directory has the magic file "git-daemon-export-ok", and +it will refuse to export any git directory that hasn't explicitly been marked +for export this way (unless the --export-all parameter is specified). If you +pass some directory paths as git-daemon arguments, you can further restrict +the offers to a whitelist comprising of those.

+

This is ideally suited for read-only updates, ie pulling from git repositories.

+
+

OPTIONS

+
+
+
+--strict-paths +
+
+

+ Match paths exactly (i.e. don't allow "/foo/repo" when the real path is + "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths. + git-daemon will refuse to start when this option is enabled and no + whitelist is specified. +

+
+
+--export-all +
+
+

+ Allow pulling from all directories that look like GIT repositories + (have the objects and refs subdirectories), even if they + do not have the git-daemon-export-ok file. +

+
+
+--inetd +
+
+

+ Have the server run as an inetd service. Implies --syslog. +

+
+
+--port +
+
+

+ Listen on an alternative port. +

+
+
+--init-timeout +
+
+

+ Timeout between the moment the connection is established and the + client request is received (typically a rather low value, since + that should be basically immediate). +

+
+
+--timeout +
+
+

+ Timeout for specific client sub-requests. This includes the time + it takes for the server to process the sub-request and time spent + waiting for next client's request. +

+
+
+--syslog +
+
+

+ Log to syslog instead of stderr. Note that this option does not imply + --verbose, thus by default only error conditions will be logged. +

+
+
+--verbose +
+
+

+ Log details about the incoming connections and requested files. +

+
+
+<directory> +
+
+

+ A directory to add to the whitelist of allowed directories. Unless + --strict-paths is specified this will also include subdirectories + of each named directory. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki +<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-daemon.txt b/git-daemon.txt new file mode 100644 index 00000000..2a8f371e --- /dev/null +++ b/git-daemon.txt @@ -0,0 +1,83 @@ +git-daemon(1) +============= + +NAME +---- +git-daemon - A really simple server for git repositories. + +SYNOPSIS +-------- +'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all] + [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...] + +DESCRIPTION +----------- +A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" +aka 9418. It waits for a connection, and will just execute "git-upload-pack" +when it gets one. + +It's careful in that there's a magic request-line that gives the command and +what directory to upload, and it verifies that the directory is ok. + +It verifies that the directory has the magic file "git-daemon-export-ok", and +it will refuse to export any git directory that hasn't explicitly been marked +for export this way (unless the '--export-all' parameter is specified). If you +pass some directory paths as 'git-daemon' arguments, you can further restrict +the offers to a whitelist comprising of those. + +This is ideally suited for read-only updates, ie pulling from git repositories. + +OPTIONS +------- +--strict-paths:: + Match paths exactly (i.e. don't allow "/foo/repo" when the real path is + "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths. + git-daemon will refuse to start when this option is enabled and no + whitelist is specified. + +--export-all:: + Allow pulling from all directories that look like GIT repositories + (have the 'objects' and 'refs' subdirectories), even if they + do not have the 'git-daemon-export-ok' file. + +--inetd:: + Have the server run as an inetd service. Implies --syslog. + +--port:: + Listen on an alternative port. + +--init-timeout:: + Timeout between the moment the connection is established and the + client request is received (typically a rather low value, since + that should be basically immediate). + +--timeout:: + Timeout for specific client sub-requests. This includes the time + it takes for the server to process the sub-request and time spent + waiting for next client's request. + +--syslog:: + Log to syslog instead of stderr. Note that this option does not imply + --verbose, thus by default only error conditions will be logged. + +--verbose:: + Log details about the incoming connections and requested files. + +:: + A directory to add to the whitelist of allowed directories. Unless + --strict-paths is specified this will also include subdirectories + of each named directory. + +Author +------ +Written by Linus Torvalds , YOSHIFUJI Hideaki + and the git-list + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-diff-files.html b/git-diff-files.html new file mode 100644 index 00000000..afe19146 --- /dev/null +++ b/git-diff-files.html @@ -0,0 +1,743 @@ + + + + + + +git-diff-files(1) + + + +

SYNOPSIS

+
+

git-diff-files [-q] [<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 "git-diff-index" and "git-diff-tree".

+
+

OPTIONS

+
+
+
+-p +
+
+

+ Generate patch (see section on generating patches) +

+
+
+-u +
+
+

+ Synonym for "-p". +

+
+
+-z +
+
+

+ \0 line termination on output +

+
+
+--name-only +
+
+

+ Show only names of changed files. +

+
+
+--name-status +
+
+

+ Show only names and status of changed files. +

+
+
+--full-index +
+
+

+ Instead of the first handful characters, show full + object name of pre- and post-image blob on the "index" + line when generating a patch format output. +

+
+
+--abbrev[=<n>] +
+
+

+ Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=<n>. +

+
+
+-B +
+
+

+ Break complete rewrite changes into pairs of delete and create. +

+
+
+-M +
+
+

+ Detect renames. +

+
+
+-C +
+
+

+ Detect copies as well as renames. +

+
+
+--find-copies-harder +
+
+

+ For performance reasons, by default, -C option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. +

+
+
+-l<num> +
+
+

+ -M and -C options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. +

+
+
+-S<string> +
+
+

+ Look for differences that contain the change in <string>. +

+
+
+--pickaxe-all +
+
+

+ When -S finds a change, show all the changes in that + changeset, not just the files that contain the change + in <string>. +

+
+
+-O<orderfile> +
+
+

+ Output the patch in the order specified in the + <orderfile>, which has one shell glob pattern per line. +

+
+
+-R +
+
+

+ Swap two inputs; that is, show differences from index or + on-disk file to tree contents. +

+
+
+

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

+
+
+-1 -2 -3 or --base --ours --theirs, and -0 +
+
+

+ Diff against the "base" version, "our branch" or "their + branch" respectively. With these options, diffs for + merged entries are not shown. +

+

The default is to diff against our branch (-2) and the +cleanly resolved paths. The option -0 can be given to +omit diff output for unmerged entries and just show "Unmerged".

+
+
+-q +
+
+

+ Remain silent even on nonexisting files +

+
+
+
+

Output format

+
+

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

+

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

+
+
+git-diff-index <tree-ish> +
+
+

+ compares the <tree-ish> and the files on the filesystem. +

+
+
+git-diff-index --cached <tree-ish> +
+
+

+ compares the <tree-ish> and the index. +

+
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…] +
+
+

+ compares the trees named by the two arguments. +

+
+
+git-diff-files [<pattern>…] +
+
+

+ compares the index and the files on the filesystem. +

+
+
+

An output line is formatted this way:

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

That is, from the left to the right:

+
    +
  1. +

    +a colon. +

    +
    2. +
  2. +

    +mode for "src"; 000000 if creation or unmerged. +

    +
    3. +
  3. +

    +a space. +

    +
    4. +
  4. +

    +mode for "dst"; 000000 if deletion or unmerged. +

    +
    5. +
  5. +

    +a space. +

    +
    6. +
  6. +

    +sha1 for "src"; 0{40} if creation or unmerged. +

    +
    7. +
  7. +

    +a space. +

    +
    8. +
  8. +

    +sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". +

    +
    9. +
  9. +

    +a space. +

    +
    10. +
  10. +

    +status, followed by optional "score" number. +

    +
    11. +
  11. +

    +a tab or a NUL when -z option is used. +

    +
    12. +
  12. +

    +path for "src" +

    +
    13. +
  13. +

    +a tab or a NUL when -z option is used; only exists for C or R. +

    +
    14. +
  14. +

    +path for "dst"; only exists for C or R. +

    +
    15. +
  15. +

    +an LF or a NUL when -z option is used, to terminate the record. +

    +
    16. +
+

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

+

Example:

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

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

+
+

Generating patches with -p

+
+

When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a -p option, they do not produce the output described above; +instead they produce a patch file.

+

The patch generation can be customized at two levels.

+
    +
  1. +

    +When the environment variable GIT_EXTERNAL_DIFF is not set, + these commands internally invoke "diff" like this: +

    +
    +
    +
    diff -L a/<path> -L b/<path> -pu <old> <new>
    +
    +

    For added files, /dev/null is used for <old>. For removed +files, /dev/null is used for <new>

    +

    The "diff" formatting options can be customized via the +environment variable GIT_DIFF_OPTS. For example, if you +prefer context diff:

    +
    +
    +
    GIT_DIFF_OPTS=-c git-diff-index -p HEAD
    +
    +
    2. +
  2. +

    +When the environment variable GIT_EXTERNAL_DIFF is set, the + program named by it is called, instead of the diff invocation + described above. +

    +

    For a path that is added, removed, or modified, +GIT_EXTERNAL_DIFF is called with 7 parameters:

    +
    +
    +
    path old-file old-hex old-mode new-file new-hex new-mode
    +
    +

    where:

    +
    + + + + + + + + + + + + +
    +<old|new>-file + +are files GIT_EXTERNAL_DIFF can use to read the + contents of <old|new>, +
    +<old|new>-hex + +are the 40-hexdigit SHA1 hashes, +
    +<old|new>-mode + +are the octal representation of the file modes. +
    +

    The file parameters can point at the user's working file +(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-file +when a new file is added), or a temporary file (e.g. old-file in the +index). GIT_EXTERNAL_DIFF should not worry about unlinking the +temporary file --- it is removed when GIT_EXTERNAL_DIFF exits.

    +
    3. +
+

For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1 +parameter, <path>.

+
+

git specific extension to diff format

+
+

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

+
    +
  1. +

    +It is preceeded with a "git diff" header, that looks like + this: +

    +
    +
    +
    diff --git a/file1 b/file2
    +
    +

    The a/ and b/ filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +/dev/null is _not_ used in place of a/ or b/ filenames.

    +

    When rename/copy is involved, file1 and file2 show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively.

    +
    2. +
  2. +

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

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

    +TAB, LF, and backslash characters in pathnames are + represented as \t, \n, and \\, respectively. +

    +
    4. +
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-diff-files.txt b/git-diff-files.txt new file mode 100644 index 00000000..67f51265 --- /dev/null +++ b/git-diff-files.txt @@ -0,0 +1,52 @@ +git-diff-files(1) +================= + +NAME +---- +git-diff-files - Compares files in the working tree and the index + + +SYNOPSIS +-------- +'git-diff-files' [-q] [] [...] + +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 "git-diff-index" and "git-diff-tree". + +OPTIONS +------- +include::diff-options.txt[] + +-1 -2 -3 or --base --ours --theirs, and -0:: + Diff against the "base" version, "our branch" or "their + branch" respectively. With these options, diffs for + merged entries are not shown. ++ +The default is to diff against our branch (-2) and the +cleanly resolved paths. The option -0 can be given to +omit diff output for unmerged entries and just show "Unmerged". + +-q:: + Remain silent even on nonexisting files + +Output format +------------- +include::diff-format.txt[] + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-diff-index.html b/git-diff-index.html new file mode 100644 index 00000000..e1a787e8 --- /dev/null +++ b/git-diff-index.html @@ -0,0 +1,844 @@ + + + + + + +git-diff-index(1) + + + +

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

+
+
+
+-p +
+
+

+ Generate patch (see section on generating patches) +

+
+
+-u +
+
+

+ Synonym for "-p". +

+
+
+-z +
+
+

+ \0 line termination on output +

+
+
+--name-only +
+
+

+ Show only names of changed files. +

+
+
+--name-status +
+
+

+ Show only names and status of changed files. +

+
+
+--full-index +
+
+

+ Instead of the first handful characters, show full + object name of pre- and post-image blob on the "index" + line when generating a patch format output. +

+
+
+--abbrev[=<n>] +
+
+

+ Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=<n>. +

+
+
+-B +
+
+

+ Break complete rewrite changes into pairs of delete and create. +

+
+
+-M +
+
+

+ Detect renames. +

+
+
+-C +
+
+

+ Detect copies as well as renames. +

+
+
+--find-copies-harder +
+
+

+ For performance reasons, by default, -C option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. +

+
+
+-l<num> +
+
+

+ -M and -C options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. +

+
+
+-S<string> +
+
+

+ Look for differences that contain the change in <string>. +

+
+
+--pickaxe-all +
+
+

+ When -S finds a change, show all the changes in that + changeset, not just the files that contain the change + in <string>. +

+
+
+-O<orderfile> +
+
+

+ Output the patch in the order specified in the + <orderfile>, which has one shell glob pattern per line. +

+
+
+-R +
+
+

+ Swap two inputs; that is, show differences from index or + on-disk file to tree contents. +

+
+
+

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

+
+
+<tree-ish> +
+
+

+ The id of a tree object to diff against. +

+
+
+--cached +
+
+

+ do not consider the on-disk file at all +

+
+
+-m +
+
+

+ By default, files recorded in the index but not checked + out are reported as deleted. This flag makes + "git-diff-index" say that all non-checked-out files are up + to date. +

+
+
+
+

Output format

+
+

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

+

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

+
+
+git-diff-index <tree-ish> +
+
+

+ compares the <tree-ish> and the files on the filesystem. +

+
+
+git-diff-index --cached <tree-ish> +
+
+

+ compares the <tree-ish> and the index. +

+
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…] +
+
+

+ compares the trees named by the two arguments. +

+
+
+git-diff-files [<pattern>…] +
+
+

+ compares the index and the files on the filesystem. +

+
+
+

An output line is formatted this way:

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

That is, from the left to the right:

+
    +
  1. +

    +a colon. +

    +
    2. +
  2. +

    +mode for "src"; 000000 if creation or unmerged. +

    +
    3. +
  3. +

    +a space. +

    +
    4. +
  4. +

    +mode for "dst"; 000000 if deletion or unmerged. +

    +
    5. +
  5. +

    +a space. +

    +
    6. +
  6. +

    +sha1 for "src"; 0{40} if creation or unmerged. +

    +
    7. +
  7. +

    +a space. +

    +
    8. +
  8. +

    +sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". +

    +
    9. +
  9. +

    +a space. +

    +
    10. +
  10. +

    +status, followed by optional "score" number. +

    +
    11. +
  11. +

    +a tab or a NUL when -z option is used. +

    +
    12. +
  12. +

    +path for "src" +

    +
    13. +
  13. +

    +a tab or a NUL when -z option is used; only exists for C or R. +

    +
    14. +
  14. +

    +path for "dst"; only exists for C or R. +

    +
    15. +
  15. +

    +an LF or a NUL when -z option is used, to terminate the record. +

    +
    16. +
+

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

+

Example:

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

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

+
+

Generating patches with -p

+
+

When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a -p option, they do not produce the output described above; +instead they produce a patch file.

+

The patch generation can be customized at two levels.

+
    +
  1. +

    +When the environment variable GIT_EXTERNAL_DIFF is not set, + these commands internally invoke "diff" like this: +

    +
    +
    +
    diff -L a/<path> -L b/<path> -pu <old> <new>
    +
    +

    For added files, /dev/null is used for <old>. For removed +files, /dev/null is used for <new>

    +

    The "diff" formatting options can be customized via the +environment variable GIT_DIFF_OPTS. For example, if you +prefer context diff:

    +
    +
    +
    GIT_DIFF_OPTS=-c git-diff-index -p HEAD
    +
    +
    2. +
  2. +

    +When the environment variable GIT_EXTERNAL_DIFF is set, the + program named by it is called, instead of the diff invocation + described above. +

    +

    For a path that is added, removed, or modified, +GIT_EXTERNAL_DIFF is called with 7 parameters:

    +
    +
    +
    path old-file old-hex old-mode new-file new-hex new-mode
    +
    +

    where:

    +
    + + + + + + + + + + + + +
    +<old|new>-file + +are files GIT_EXTERNAL_DIFF can use to read the + contents of <old|new>, +
    +<old|new>-hex + +are the 40-hexdigit SHA1 hashes, +
    +<old|new>-mode + +are the octal representation of the file modes. +
    +

    The file parameters can point at the user's working file +(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-file +when a new file is added), or a temporary file (e.g. old-file in the +index). GIT_EXTERNAL_DIFF should not worry about unlinking the +temporary file --- it is removed when GIT_EXTERNAL_DIFF exits.

    +
    3. +
+

For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1 +parameter, <path>.

+
+

git specific extension to diff format

+
+

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

+
    +
  1. +

    +It is preceeded with a "git diff" header, that looks like + this: +

    +
    +
    +
    diff --git a/file1 b/file2
    +
    +

    The a/ and b/ filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +/dev/null is _not_ used in place of a/ or b/ filenames.

    +

    When rename/copy is involved, file1 and file2 show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively.

    +
    2. +
  2. +

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

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

    +TAB, LF, and backslash characters in pathnames are + represented as \t, \n, and \\, respectively. +

    +
    4. +
+
+

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
+contents (the ones I'd write with a "git-write-tree")
+
+

For example, let's say that you have worked on your working directory, updated +some files in the index and are ready to commit. You want to see eactly +what you are going to commit is without having to write a new tree +object and compare it that way, and to do that, you just do

+
+
+
git-diff-index --cached HEAD
+
+

Example: let's say I had renamed commit.c to git-commit.c, and I had +done an "git-update-index" to make that effective in the index file. +"git-diff-files" wouldn't show anything at all, since the index file +matches my working directory. But doing a "git-diff-index" does:

+
+
+
torvalds@ppc970:~/git> git-diff-index --cached HEAD
+-100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
++100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
+
+

You can trivially see that the above is a rename.

+

In fact, "git-diff-index --cached" should always be entirely equivalent to +actually doing a "git-write-tree" and comparing that. Except this one is much +nicer for the case where you just want to check where you are.

+

So doing a "git-diff-index --cached" is basically very useful when 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 +a "git-write-tree" + "git-diff-tree". Thus that's the default mode. +The non-cached version asks the question:

+
+
+
show me the differences between HEAD and the currently checked out
+tree - index contents _and_ files that aren't up-to-date
+
+

which is obviously a very useful question too, since that tells you what +you could commit. Again, the output matches the "git-diff-tree -r" +output to a tee, but with a twist.

+

The twist is that if some file doesn't match the index, we don't have +a backing store thing for it, and we use the magic "all-zero" sha1 to +show that. So let's say that you have edited kernel/sched.c, but +have not actually done a "git-update-index" on it yet - there is no +"object" associated with the new state, and you get:

+
+
+
torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
+*100644->100664 blob    7476bb......->000000......      kernel/sched.c
+
+

ie it shows that the tree has changed, and that kernel/sched.c has is +not up-to-date and may contain new stuff. The all-zero sha1 means that to +get the real diff, you need to look at the object in the working directory +directly rather than do an object-to-object diff.

+
+ + + +
+
Note
+		As with other commands of this type, "git-diff-index" does not +actually look at the contents of the file at all. So maybe +kernel/sched.c hasn't actually changed, and it's just that you +touched it. In either case, it's a note that you need to +"git-upate-index" it to make the index be in sync.
+
+
+ + + +
+
Note
+		You can have a mixture of files show up as "has been updated" +and "is still dirty in the working directory" together. You can always +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.
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-diff-index.txt b/git-diff-index.txt new file mode 100644 index 00000000..dba6d30f --- /dev/null +++ b/git-diff-index.txt @@ -0,0 +1,133 @@ +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] [] [...] + +DESCRIPTION +----------- +Compares the content and mode of the blobs found via a tree +object with the content of the current index and, optionally +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 +------- +include::diff-options.txt[] + +:: + The id of a tree object to diff against. + +--cached:: + do not consider the on-disk file at all + +-m:: + By default, files recorded in the index but not checked + out are reported as deleted. This flag makes + "git-diff-index" say that all non-checked-out files are up + to date. + +Output format +------------- +include::diff-format.txt[] + +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 + contents (the ones I'd write with a "git-write-tree") + +For example, let's say that you have worked on your working directory, updated +some files in the index and are ready to commit. You want to see eactly +*what* you are going to commit is without having to write a new tree +object and compare it that way, and to do that, you just do + + git-diff-index --cached HEAD + +Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had +done an "git-update-index" to make that effective in the index file. +"git-diff-files" wouldn't show anything at all, since the index file +matches my working directory. But doing a "git-diff-index" does: + + torvalds@ppc970:~/git> git-diff-index --cached HEAD + -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c + +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c + +You can trivially see that the above is a rename. + +In fact, "git-diff-index --cached" *should* always be entirely equivalent to +actually doing a "git-write-tree" and comparing that. Except this one is much +nicer for the case where you just want to check where you are. + +So doing a "git-diff-index --cached" is basically very useful when 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 +a "git-write-tree" + "git-diff-tree". Thus that's the default mode. +The non-cached version asks the question: + + show me the differences between HEAD and the currently checked out + tree - index contents _and_ files that aren't up-to-date + +which is obviously a very useful question too, since that tells you what +you *could* commit. Again, the output matches the "git-diff-tree -r" +output to a tee, but with a twist. + +The twist is that if some file doesn't match the index, we don't have +a backing store thing for it, and we use the magic "all-zero" sha1 to +show that. So let's say that you have edited `kernel/sched.c`, but +have not actually done a "git-update-index" on it yet - there is no +"object" associated with the new state, and you get: + + torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD + *100644->100664 blob 7476bb......->000000...... kernel/sched.c + +ie it shows that the tree has changed, and that `kernel/sched.c` has is +not up-to-date and may contain new stuff. The all-zero sha1 means that to +get the real diff, you need to look at the object in the working directory +directly rather than do an object-to-object diff. + +NOTE: As with other commands of this type, "git-diff-index" does not +actually look at the contents of the file at all. So maybe +`kernel/sched.c` hasn't actually changed, and it's just that you +touched it. In either case, it's a note that you need to +"git-upate-index" it to make the index be in sync. + +NOTE: You can have a mixture of files show up as "has been updated" +and "is still dirty in the working directory" together. You can always +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. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-diff-stages.html b/git-diff-stages.html new file mode 100644 index 00000000..c6eba5d6 --- /dev/null +++ b/git-diff-stages.html @@ -0,0 +1,728 @@ + + + + + + +git-diff-stages(1) + + + +

SYNOPSIS

+
+

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

+
+

DESCRIPTION

+
+

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

+
+

OPTIONS

+
+
+
+-p +
+
+

+ Generate patch (see section on generating patches) +

+
+
+-u +
+
+

+ Synonym for "-p". +

+
+
+-z +
+
+

+ \0 line termination on output +

+
+
+--name-only +
+
+

+ Show only names of changed files. +

+
+
+--name-status +
+
+

+ Show only names and status of changed files. +

+
+
+--full-index +
+
+

+ Instead of the first handful characters, show full + object name of pre- and post-image blob on the "index" + line when generating a patch format output. +

+
+
+--abbrev[=<n>] +
+
+

+ Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=<n>. +

+
+
+-B +
+
+

+ Break complete rewrite changes into pairs of delete and create. +

+
+
+-M +
+
+

+ Detect renames. +

+
+
+-C +
+
+

+ Detect copies as well as renames. +

+
+
+--find-copies-harder +
+
+

+ For performance reasons, by default, -C option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. +

+
+
+-l<num> +
+
+

+ -M and -C options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. +

+
+
+-S<string> +
+
+

+ Look for differences that contain the change in <string>. +

+
+
+--pickaxe-all +
+
+

+ When -S finds a change, show all the changes in that + changeset, not just the files that contain the change + in <string>. +

+
+
+-O<orderfile> +
+
+

+ Output the patch in the order specified in the + <orderfile>, which has one shell glob pattern per line. +

+
+
+-R +
+
+

+ Swap two inputs; that is, show differences from index or + on-disk file to tree contents. +

+
+
+

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

+
+
+<stage1>,<stage2> +
+
+

+ The stage number to be compared. +

+
+
+
+

Output format

+
+

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

+

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

+
+
+git-diff-index <tree-ish> +
+
+

+ compares the <tree-ish> and the files on the filesystem. +

+
+
+git-diff-index --cached <tree-ish> +
+
+

+ compares the <tree-ish> and the index. +

+
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…] +
+
+

+ compares the trees named by the two arguments. +

+
+
+git-diff-files [<pattern>…] +
+
+

+ compares the index and the files on the filesystem. +

+
+
+

An output line is formatted this way:

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

That is, from the left to the right:

+
    +
  1. +

    +a colon. +

    +
    2. +
  2. +

    +mode for "src"; 000000 if creation or unmerged. +

    +
    3. +
  3. +

    +a space. +

    +
    4. +
  4. +

    +mode for "dst"; 000000 if deletion or unmerged. +

    +
    5. +
  5. +

    +a space. +

    +
    6. +
  6. +

    +sha1 for "src"; 0{40} if creation or unmerged. +

    +
    7. +
  7. +

    +a space. +

    +
    8. +
  8. +

    +sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". +

    +
    9. +
  9. +

    +a space. +

    +
    10. +
  10. +

    +status, followed by optional "score" number. +

    +
    11. +
  11. +

    +a tab or a NUL when -z option is used. +

    +
    12. +
  12. +

    +path for "src" +

    +
    13. +
  13. +

    +a tab or a NUL when -z option is used; only exists for C or R. +

    +
    14. +
  14. +

    +path for "dst"; only exists for C or R. +

    +
    15. +
  15. +

    +an LF or a NUL when -z option is used, to terminate the record. +

    +
    16. +
+

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

+

Example:

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

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

+
+

Generating patches with -p

+
+

When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a -p option, they do not produce the output described above; +instead they produce a patch file.

+

The patch generation can be customized at two levels.

+
    +
  1. +

    +When the environment variable GIT_EXTERNAL_DIFF is not set, + these commands internally invoke "diff" like this: +

    +
    +
    +
    diff -L a/<path> -L b/<path> -pu <old> <new>
    +
    +

    For added files, /dev/null is used for <old>. For removed +files, /dev/null is used for <new>

    +

    The "diff" formatting options can be customized via the +environment variable GIT_DIFF_OPTS. For example, if you +prefer context diff:

    +
    +
    +
    GIT_DIFF_OPTS=-c git-diff-index -p HEAD
    +
    +
    2. +
  2. +

    +When the environment variable GIT_EXTERNAL_DIFF is set, the + program named by it is called, instead of the diff invocation + described above. +

    +

    For a path that is added, removed, or modified, +GIT_EXTERNAL_DIFF is called with 7 parameters:

    +
    +
    +
    path old-file old-hex old-mode new-file new-hex new-mode
    +
    +

    where:

    +
    + + + + + + + + + + + + +
    +<old|new>-file + +are files GIT_EXTERNAL_DIFF can use to read the + contents of <old|new>, +
    +<old|new>-hex + +are the 40-hexdigit SHA1 hashes, +
    +<old|new>-mode + +are the octal representation of the file modes. +
    +

    The file parameters can point at the user's working file +(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-file +when a new file is added), or a temporary file (e.g. old-file in the +index). GIT_EXTERNAL_DIFF should not worry about unlinking the +temporary file --- it is removed when GIT_EXTERNAL_DIFF exits.

    +
    3. +
+

For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1 +parameter, <path>.

+
+

git specific extension to diff format

+
+

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

+
    +
  1. +

    +It is preceeded with a "git diff" header, that looks like + this: +

    +
    +
    +
    diff --git a/file1 b/file2
    +
    +

    The a/ and b/ filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +/dev/null is _not_ used in place of a/ or b/ filenames.

    +

    When rename/copy is involved, file1 and file2 show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively.

    +
    2. +
  2. +

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

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

    +TAB, LF, and backslash characters in pathnames are + represented as \t, \n, and \\, respectively. +

    +
    4. +
+
+

Author

+
+

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

+
+

Documentation

+
+

Documentation by Junio C Hamano.

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-diff-stages.txt b/git-diff-stages.txt new file mode 100644 index 00000000..28c60fc7 --- /dev/null +++ b/git-diff-stages.txt @@ -0,0 +1,40 @@ +git-diff-stages(1) +================== + +NAME +---- +git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file. + + +SYNOPSIS +-------- +'git-diff-stages' [] [...] + +DESCRIPTION +----------- +Compares the content and mode of the blobs in two stages in an +unmerged index file. + +OPTIONS +------- +include::diff-options.txt[] + +,:: + The stage number to be compared. + +Output format +------------- +include::diff-format.txt[] + + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-diff-tree.html b/git-diff-tree.html new file mode 100644 index 00000000..27362c24 --- /dev/null +++ b/git-diff-tree.html @@ -0,0 +1,873 @@ + + + + + + +git-diff-tree(1) + + + +

SYNOPSIS

+
+

git-diff-tree [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] [-t] [-r] [--root] [<common diff options>] <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

+
+
+
+-p +
+
+

+ Generate patch (see section on generating patches) +

+
+
+-u +
+
+

+ Synonym for "-p". +

+
+
+-z +
+
+

+ \0 line termination on output +

+
+
+--name-only +
+
+

+ Show only names of changed files. +

+
+
+--name-status +
+
+

+ Show only names and status of changed files. +

+
+
+--full-index +
+
+

+ Instead of the first handful characters, show full + object name of pre- and post-image blob on the "index" + line when generating a patch format output. +

+
+
+--abbrev[=<n>] +
+
+

+ Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=<n>. +

+
+
+-B +
+
+

+ Break complete rewrite changes into pairs of delete and create. +

+
+
+-M +
+
+

+ Detect renames. +

+
+
+-C +
+
+

+ Detect copies as well as renames. +

+
+
+--find-copies-harder +
+
+

+ For performance reasons, by default, -C option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. +

+
+
+-l<num> +
+
+

+ -M and -C options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. +

+
+
+-S<string> +
+
+

+ Look for differences that contain the change in <string>. +

+
+
+--pickaxe-all +
+
+

+ When -S finds a change, show all the changes in that + changeset, not just the files that contain the change + in <string>. +

+
+
+-O<orderfile> +
+
+

+ Output the patch in the order specified in the + <orderfile>, which has one shell glob pattern per line. +

+
+
+-R +
+
+

+ Swap two inputs; that is, show differences from index or + on-disk file to tree contents. +

+
+
+

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

+
+
+<tree-ish> +
+
+

+ The id of a tree object. +

+
+
+<path>… +
+
+

+ If provided, the results are limited to a subset of files + matching one of these prefix strings. + ie file matches /^<pattern1>|<pattern2>|…/ + Note that this parameter does not provide any wildcard or regexp + features. +

+
+
+-r +
+
+

+ recurse into sub-trees +

+
+
+-t +
+
+

+ show tree entry itself as well as subtrees. Implies -r. +

+
+
+--root +
+
+

+ When --root is specified the initial commit will be showed as a big + creation event. This is equivalent to a diff against the NULL tree. +

+
+
+--stdin +
+
+

+ When --stdin is specified, the command does not take + <tree-ish> arguments from the command line. Instead, it + reads either one <commit> or a pair of <tree-ish> + separated with a single space from its standard input. +

+

When a single commit is given on one line of such input, it compares +the commit with its parents. The following flags further affects its +behaviour. This does not apply to the case where two <tree-ish> +separated with a single space are given.

+
+
+-m +
+
+

+ By default, "git-diff-tree --stdin" does not show + differences for merge commits. With this flag, it shows + differences to that commit from all of its parents. +

+
+
+-s +
+
+

+ By default, "git-diff-tree --stdin" shows differences, + either in machine-readable form (without -p) or in patch + form (with -p). This output can be supressed. It is + only useful with -v flag. +

+
+
+-v +
+
+

+ This flag causes "git-diff-tree --stdin" to also show + the commit message before the differences. +

+
+
+--pretty[=(raw|medium|short)] +
+
+

+ This is used to control "pretty printing" format of the + commit message. Without "=<style>", it defaults to + medium. +

+
+
+--no-commit-id +
+
+

+ git-diff-tree outputs a line with the commit ID when + applicable. This flag suppressed the commit ID output. +

+
+
+
+

Limiting Output

+
+

If you're only interested in differences in a subset of files, for +example some architecture-specific files, you might do:

+
+
+
git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
+
+

and it will only show you what changed in those two directories.

+

Or if you are searching for what changed in just kernel/sched.c, just do

+
+
+
git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
+
+

and it will ignore all differences to other files.

+

The pattern is always the prefix, and is matched exactly. There are no +wildcards. Even stricter, it has to match a complete path component. +I.e. "foo" does not pick up foobar.h. "foo" does match foo/bar.h +so it can be used to name subdirectories.

+

An example of normal usage is:

+
+
+
torvalds@ppc970:~/git> git-diff-tree 5319e4......
+*100664->100664 blob    ac348b.......->a01513.......      git-fsck-objects.c
+
+

which tells you that the last commit changed just one file (it's from +this one:

+
+
+
commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
+tree 5319e4d609cdd282069cc4dce33c1db559539b03
+parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
+author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+
+Make "git-fsck-objects" print out all the root commits it finds.
+
+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).

+
+

Output format

+
+

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

+

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

+
+
+git-diff-index <tree-ish> +
+
+

+ compares the <tree-ish> and the files on the filesystem. +

+
+
+git-diff-index --cached <tree-ish> +
+
+

+ compares the <tree-ish> and the index. +

+
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…] +
+
+

+ compares the trees named by the two arguments. +

+
+
+git-diff-files [<pattern>…] +
+
+

+ compares the index and the files on the filesystem. +

+
+
+

An output line is formatted this way:

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

That is, from the left to the right:

+
    +
  1. +

    +a colon. +

    +
    2. +
  2. +

    +mode for "src"; 000000 if creation or unmerged. +

    +
    3. +
  3. +

    +a space. +

    +
    4. +
  4. +

    +mode for "dst"; 000000 if deletion or unmerged. +

    +
    5. +
  5. +

    +a space. +

    +
    6. +
  6. +

    +sha1 for "src"; 0{40} if creation or unmerged. +

    +
    7. +
  7. +

    +a space. +

    +
    8. +
  8. +

    +sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". +

    +
    9. +
  9. +

    +a space. +

    +
    10. +
  10. +

    +status, followed by optional "score" number. +

    +
    11. +
  11. +

    +a tab or a NUL when -z option is used. +

    +
    12. +
  12. +

    +path for "src" +

    +
    13. +
  13. +

    +a tab or a NUL when -z option is used; only exists for C or R. +

    +
    14. +
  14. +

    +path for "dst"; only exists for C or R. +

    +
    15. +
  15. +

    +an LF or a NUL when -z option is used, to terminate the record. +

    +
    16. +
+

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

+

Example:

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

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

+
+

Generating patches with -p

+
+

When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a -p option, they do not produce the output described above; +instead they produce a patch file.

+

The patch generation can be customized at two levels.

+
    +
  1. +

    +When the environment variable GIT_EXTERNAL_DIFF is not set, + these commands internally invoke "diff" like this: +

    +
    +
    +
    diff -L a/<path> -L b/<path> -pu <old> <new>
    +
    +

    For added files, /dev/null is used for <old>. For removed +files, /dev/null is used for <new>

    +

    The "diff" formatting options can be customized via the +environment variable GIT_DIFF_OPTS. For example, if you +prefer context diff:

    +
    +
    +
    GIT_DIFF_OPTS=-c git-diff-index -p HEAD
    +
    +
    2. +
  2. +

    +When the environment variable GIT_EXTERNAL_DIFF is set, the + program named by it is called, instead of the diff invocation + described above. +

    +

    For a path that is added, removed, or modified, +GIT_EXTERNAL_DIFF is called with 7 parameters:

    +
    +
    +
    path old-file old-hex old-mode new-file new-hex new-mode
    +
    +

    where:

    +
    + + + + + + + + + + + + +
    +<old|new>-file + +are files GIT_EXTERNAL_DIFF can use to read the + contents of <old|new>, +
    +<old|new>-hex + +are the 40-hexdigit SHA1 hashes, +
    +<old|new>-mode + +are the octal representation of the file modes. +
    +

    The file parameters can point at the user's working file +(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-file +when a new file is added), or a temporary file (e.g. old-file in the +index). GIT_EXTERNAL_DIFF should not worry about unlinking the +temporary file --- it is removed when GIT_EXTERNAL_DIFF exits.

    +
    3. +
+

For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1 +parameter, <path>.

+
+

git specific extension to diff format

+
+

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

+
    +
  1. +

    +It is preceeded with a "git diff" header, that looks like + this: +

    +
    +
    +
    diff --git a/file1 b/file2
    +
    +

    The a/ and b/ filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +/dev/null is _not_ used in place of a/ or b/ filenames.

    +

    When rename/copy is involved, file1 and file2 show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively.

    +
    2. +
  2. +

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

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

    +TAB, LF, and backslash characters in pathnames are + represented as \t, \n, and \\, respectively. +

    +
    4. +
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-diff-tree.txt b/git-diff-tree.txt new file mode 100644 index 00000000..9a2947e2 --- /dev/null +++ b/git-diff-tree.txt @@ -0,0 +1,141 @@ +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] [-t] [-r] [--root] [] [] [...] + +DESCRIPTION +----------- +Compares the content and mode of the blobs found via two tree objects. + +If there is only one 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 +------- +include::diff-options.txt[] + +:: + The id of a tree object. + +...:: + If provided, the results are limited to a subset of files + matching one of these prefix strings. + ie file matches `/^||.../` + Note that this parameter does not provide any wildcard or regexp + features. + +-r:: + recurse into sub-trees + +-t:: + show tree entry itself as well as subtrees. Implies -r. + +--root:: + When '--root' is specified the initial commit will be showed as a big + creation event. This is equivalent to a diff against the NULL tree. + +--stdin:: + When '--stdin' is specified, the command does not take + arguments from the command line. Instead, it + reads either one or a pair of + separated with a single space from its standard input. ++ +When a single commit is given on one line of such input, it compares +the commit with its parents. The following flags further affects its +behaviour. This does not apply to the case where two +separated with a single space are given. + +-m:: + By default, "git-diff-tree --stdin" does not show + differences for merge commits. With this flag, it shows + differences to that commit from all of its parents. + +-s:: + By default, "git-diff-tree --stdin" shows differences, + either in machine-readable form (without '-p') or in patch + form (with '-p'). This output can be supressed. It is + only useful with '-v' flag. + +-v:: + This flag causes "git-diff-tree --stdin" to also show + the commit message before the differences. + +--pretty[=(raw|medium|short)]:: + This is used to control "pretty printing" format of the + commit message. Without "= +git-diff(1) + + + +

SYNOPSIS

+
+

git-diff [ --diff-options ] <ent>{0,2} [<path>…]

+
+

DESCRIPTION

+
+

Show changes between two ents, an ent and the working tree, an +ent and the index file, or the index file and the working tree. +The combination of what is compared with what is determined by +the number of ents given to the command.

+
    +
  • +

    +When no <ent> is given, the working tree and the index + file is compared, using git-diff-files. +

    +
    • +
  • +

    +When one <ent> is given, the working tree and the named + tree is compared, using git-diff-index. The option + --cached can be given to compare the index file and + the named tree. +

    +
    • +
  • +

    +When two <ent>s are given, these two trees are compared + using git-diff-tree. +

    +
    • +
+
+

OPTIONS

+
+
+
+--diff-options +
+
+

+ --diff-options are passed to the git-diff-files, + git-diff-index, and git-diff-tree commands. See the + documentation for these commands for description. +

+
+
+<path>… +
+
+

+ The <path> arguments are also passed to git-diff-* + commands. +

+
+
+
+

EXAMPLES

+
+
+
+Various ways to check your working tree +
+
+
+
+
$ git diff (1)
+$ git diff --cached (2)
+$ git diff HEAD (3)
+
+(1) changes in the working tree since your last git-update-index.
+(2) changes between the index and your last commit; what you
+would be committing if you run "git commit" without "-a" option.
+(3) changes in the working tree since your last commit; what you
+would be committing if you run "git commit -a"
+
+
+
+Comparing with arbitrary commits +
+
+
+
+
$ git diff test (1)
+$ git diff HEAD -- ./test (2)
+$ git diff HEAD^ HEAD (3)
+
+(1) instead of using the tip of the current branch, compare with the
+tip of "test" branch.
+(2) instead of comparing with the tip of "test" branch, compare with
+the tip of the curren branch, but limit the comparison to the
+file "test".
+(3) compare the version before the last commit and the last commit.
+
+
+
+Limiting the diff output +
+
+
+
+
$ git diff --diff-filter=MRC (1)
+$ git diff --name-status -r (2)
+$ git diff arch/i386 include/asm-i386 (3)
+
+(1) show only modification, rename and copy, but not addition
+nor deletion.
+(2) show only names and the nature of change, but not actual
+diff output.  --name-status disables usual patch generation
+which in turn also disables recursive behaviour, so without -r
+you would only see the directory name if there is a change in a
+file in a subdirectory.
+(3) limit diff output to named subtrees.
+
+
+
+Munging the diff output +
+
+
+
+
$ git diff --find-copies-harder -B -C (1)
+$ git diff -R (2)
+
+(1) spend extra cycles to find renames, copies and complete
+rewrites (very expensive).
+(2) output diff in reverse.
+
+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-diff.txt b/git-diff.txt new file mode 100644 index 00000000..b04f393b --- /dev/null +++ b/git-diff.txt @@ -0,0 +1,116 @@ +git-diff(1) +=========== + +NAME +---- +git-diff - Show changes between commits, commit and working tree, etc. + + +SYNOPSIS +-------- +'git-diff' [ --diff-options ] {0,2} [...] + +DESCRIPTION +----------- +Show changes between two ents, an ent and the working tree, an +ent and the index file, or the index file and the working tree. +The combination of what is compared with what is determined by +the number of ents given to the command. + +* When no is given, the working tree and the index + file is compared, using `git-diff-files`. + +* When one is given, the working tree and the named + tree is compared, using `git-diff-index`. The option + `--cached` can be given to compare the index file and + the named tree. + +* When two s are given, these two trees are compared + using `git-diff-tree`. + +OPTIONS +------- +--diff-options:: + '--diff-options' are passed to the `git-diff-files`, + `git-diff-index`, and `git-diff-tree` commands. See the + documentation for these commands for description. + +...:: + The arguments are also passed to `git-diff-\*` + commands. + + +EXAMPLES +-------- + +Various ways to check your working tree:: ++ +------------ +$ git diff <1> +$ git diff --cached <2> +$ git diff HEAD <3> + +<1> changes in the working tree since your last git-update-index. +<2> changes between the index and your last commit; what you +would be committing if you run "git commit" without "-a" option. +<3> changes in the working tree since your last commit; what you +would be committing if you run "git commit -a" +------------ + +Comparing with arbitrary commits:: ++ +------------ +$ git diff test <1> +$ git diff HEAD -- ./test <2> +$ git diff HEAD^ HEAD <3> + +<1> instead of using the tip of the current branch, compare with the +tip of "test" branch. +<2> instead of comparing with the tip of "test" branch, compare with +the tip of the curren branch, but limit the comparison to the +file "test". +<3> compare the version before the last commit and the last commit. +------------ + + +Limiting the diff output:: ++ +------------ +$ git diff --diff-filter=MRC <1> +$ git diff --name-status -r <2> +$ git diff arch/i386 include/asm-i386 <3> + +<1> show only modification, rename and copy, but not addition +nor deletion. +<2> show only names and the nature of change, but not actual +diff output. --name-status disables usual patch generation +which in turn also disables recursive behaviour, so without -r +you would only see the directory name if there is a change in a +file in a subdirectory. +<3> limit diff output to named subtrees. +------------ + +Munging the diff output:: ++ +------------ +$ git diff --find-copies-harder -B -C <1> +$ git diff -R <2> + +<1> spend extra cycles to find renames, copies and complete +rewrites (very expensive). +<2> output diff in reverse. +------------ + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-fetch-pack.html b/git-fetch-pack.html new file mode 100644 index 00000000..b9ba9bd4 --- /dev/null +++ b/git-fetch-pack.html @@ -0,0 +1,375 @@ + + + + + + +git-fetch-pack(1) + + + +

SYNOPSIS

+
+

git-fetch-pack [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>…]

+
+

DESCRIPTION

+
+

Invokes git-upload-pack on a potentially remote repository, +and asks it to send objects missing from this repository, to +update the named heads. The list of commits available locally +is found out by scanning local $GIT_DIR/refs/ and sent to +git-upload-pack running on the other end.

+

This command degenerates to download everything to complete the +asked refs from the remote side when the local side does not +have a common ancestor commit.

+
+

OPTIONS

+
+
+
+-q +
+
+

+ Pass -q flag to git-unpack-objects; this makes the + cloning process less verbose. +

+
+
+-k +
+
+

+ Do not invoke git-unpack-objects on received data, but + create a single packfile out of it instead, and store it + in the object database. +

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

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

+
+
+<host> +
+
+

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

+
+
+<directory> +
+
+

+ The repository to sync from. +

+
+
+<refs>… +
+
+

+ The remote heads to update from. This is relative to + $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When + unspecified, update from all heads the remote side has. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

Documentation by Junio C Hamano.

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-fetch-pack.txt b/git-fetch-pack.txt new file mode 100644 index 00000000..b507e9b6 --- /dev/null +++ b/git-fetch-pack.txt @@ -0,0 +1,73 @@ +git-fetch-pack(1) +================= + +NAME +---- +git-fetch-pack - Receive missing objects from another repository. + + +SYNOPSIS +-------- +git-fetch-pack [-q] [-k] [--exec=] [:] [...] + +DESCRIPTION +----------- +Invokes 'git-upload-pack' on a potentially remote repository, +and asks it to send objects missing from this repository, to +update the named heads. The list of commits available locally +is found out by scanning local $GIT_DIR/refs/ and sent to +'git-upload-pack' running on the other end. + +This command degenerates to download everything to complete the +asked refs from the remote side when the local side does not +have a common ancestor commit. + + +OPTIONS +------- +-q:: + Pass '-q' flag to 'git-unpack-objects'; this makes the + cloning process less verbose. + +-k:: + Do not invoke 'git-unpack-objects' on received data, but + create a single packfile out of it instead, and store it + in the object database. + +--exec=:: + Use this to specify the path to 'git-upload-pack' on the + remote side, if is not found on your $PATH. + Installations of sshd ignores the user's environment + setup scripts for login shells (e.g. .bash_profile) and + your privately installed git may not be found on the system + default $PATH. Another workaround suggested is to set + up your $PATH in ".bashrc", but this flag is for people + who do not want to pay the overhead for non-interactive + shells by having a lean .bashrc file (they set most of + the things up in .bash_profile). + +:: + A remote host that houses the repository. When this + part is specified, 'git-upload-pack' is invoked via + ssh. + +:: + The repository to sync from. + +...:: + The remote heads to update from. This is relative to + $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When + unspecified, update from all heads the remote side has. + + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-fetch.html b/git-fetch.html new file mode 100644 index 00000000..9d38bb1e --- /dev/null +++ b/git-fetch.html @@ -0,0 +1,586 @@ + + + + + + +git-fetch(1) + + + +

SYNOPSIS

+
+

git-fetch <options> <repository> <refspec>…

+
+

DESCRIPTION

+
+

Fetches named heads or tags from another repository, along with +the objects necessary to complete them.

+

The ref names and their object names of fetched refs are stored +in .git/FETCH_HEAD. This information is left for a later merge +operation done by "git merge".

+
+

OPTIONS

+
+
+
+-a, --append +
+
+

+ Append ref names and object names of fetched refs to the + existing contents of .git/FETCH_HEAD. Without this + option old data in .git/FETCH_HEAD will be overwritten. +

+
+
+-f, --force +
+
+

+ When git-fetch is used with <rbranch>:<lbranch> + refspec, it refuses to update the local branch + <lbranch> unless the remote branch <rbranch> it + fetches is a descendant of <lbranch>. This option + overrides that check. +

+
+
+-t, --tags +
+
+

+ By default, the git core utilities will not fetch and store + tags under the same name as the remote repository; ask it + to do so using --tags. Using this option will bound the + list of objects pulled to the remote tags. Commits in branches + beyond the tags will be ignored. +

+
+
+-u, --update-head-ok +
+
+

+ By default git-fetch refuses to update the head which + corresponds to the current branch. This flag disables the + check. Note that fetching into the current branch will not + update the index and working directory, so use it with care. +

+
+
+<repository> +
+
+

+ The "remote" repository that is the source of a fetch + or pull operation, or the destination of a push operation. + One of the following notations can be used + to name the remote repository: +

+
+
+
    +
  • +

    +rsync://host.xz/path/to/repo.git/ +

    +
    • +
  • +

    +http://host.xz/path/to/repo.git/ +

    +
    • +
  • +

    +https://host.xz/path/to/repo.git/ +

    +
    • +
  • +

    +git://host.xz/path/to/repo.git/ +

    +
    • +
  • +

    +git://host.xz/~user/path/to/repo.git/ +

    +
    • +
  • +

    +ssh://host.xz/path/to/repo.git/ +

    +
    • +
  • +

    +ssh://host.xz/~user/path/to/repo.git/ +

    +
    • +
  • +

    +ssh://host.xz/~/path/to/repo.git +

    +
    • +
+
+

SSH Is the default transport protocol and also supports an +scp-like syntax. Both syntaxes support username expansion, +as does the native git protocol. The following three are +identical to the last three above, respectively:

+
+
+
    +
  • +

    +host.xz:/path/to/repo.git/ +

    +
    • +
  • +

    +host.xz:~user/path/to/repo.git/ +

    +
    • +
  • +

    +host.xz:path/to/repo.git +

    +
    • +
+
+

To sync with a local directory, use:

+
+
+
    +
  • +

    +/path/to/repo.git/ +

    +
    • +
+
+

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

+
+
+
URL: one of the above URL format
+Push: <refspec>
+Pull: <refspec>
+
+

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

+

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

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

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

+
+
+
URL: <url>
+Pull: refs/heads/<head>:<remote>
+
+
+
+<refspec> +
+
+

+ The canonical format of a <refspec> parameter is + +?<src>:<dst>; that is, an optional plus +, followed + by the source ref, followed by a colon :, followed by + the destination ref. +

+

When used in git-push, the <src> side can be an +arbitrary "SHA1 expression" that can be used as an +argument to git-cat-file -t. E.g. master~4 (push +four parents before the current master head).

+

For git-push, the local ref that matches <src> is used +to fast forward the remote ref that matches <dst>. If +the optional plus + is used, the remote ref is updated +even if it does not result in a fast forward update.

+

For git-fetch and git-pull, the remote ref that matches <src> +is fetched, and if <dst> is not empty string, the local +ref that matches it is fast forwarded using <src>. +Again, if the optional plus + is used, the local ref +is updated even if it does not result in a fast forward +update.

+
+ + + +
+
Note
+		If the remote branch from which you want to pull is +modified in non-linear ways such as being rewound and +rebased frequently, then a pull will attempt a merge with +an older version of itself, likely conflict, and fail. +It is under these conditions that you would want to use +the + sign to indicate non-fast-forward updates will +be needed. There is currently no easy way to determine +or declare that a branch will be made available in a +repository with this behavior; the pulling user simply +must know this is the expected usage pattern for a branch.
+
+
+ + + +
+
Note
+		You never do your own development on branches that appear +on the right hand side of a <refspec> colon on Pull: lines; +they are to be updated by git-fetch. If you intend to do +development derived from a remote branch B, have a Pull: +line to track it (i.e. Pull: B:remote-B), and have a separate +branch my-B to do your development on top of it. The latter +is created by git branch my-B remote-B (or its equivalent git +checkout -b my-B remote-B). Run git fetch to keep track of +the progress of the remote side, and when you see something new +on the remote branch, merge it into your development branch with +git pull . remote-B, while you are on my-B branch. +The common Pull: master:origin mapping of a remote master +branch to a local origin branch, which is then merged to a +local development branch, again typically named master, is made +when you run git clone for you to follow this pattern.
+
+
+ + + +
+
Note
+		There is a difference between listing multiple <refspec> +directly on git-pull command line and having multiple +Pull: <refspec> lines for a <repository> and running +git-pull command without any explicit <refspec> parameters. +<refspec> listed explicitly on the command line are always +merged into the current branch after fetching. In other words, +if you list more than one remote refs, you would be making +an Octopus. While git-pull run without any explicit <refspec> +parameter takes default <refspec>s from Pull: lines, it +merges only the first <refspec> found into the current branch, +after fetching all the remote refs. This is because making an +Octopus from remote refs is rarely done, while keeping track +of multiple remote heads in one-go by fetching more than one +is often useful.
+
+

Some short-cut notations are also supported.

+
    +
  • +

    +For backward compatibility, tag is almost ignored; + it just makes the following parameter <tag> to mean a + refspec refs/tags/<tag>:refs/tags/<tag>. +

    +
    • +
  • +

    +A parameter <ref> without a colon is equivalent to + <ref>: when pulling/fetching, and <ref>:<ref> when + pushing. That is, do not store it locally if + fetching, and update the same name if pushing. +

    +
    • +
+
+
+
+

SEE ALSO

+
+

git-pull(1)

+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <junkio@cox.net>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-fetch.txt b/git-fetch.txt new file mode 100644 index 00000000..d1b45f96 --- /dev/null +++ b/git-fetch.txt @@ -0,0 +1,48 @@ +git-fetch(1) +============ + +NAME +---- +git-fetch - Download objects and a head from another repository. + + +SYNOPSIS +-------- +'git-fetch' ... + + +DESCRIPTION +----------- +Fetches named heads or tags from another repository, along with +the objects necessary to complete them. + +The ref names and their object names of fetched refs are stored +in `.git/FETCH_HEAD`. This information is left for a later merge +operation done by "git merge". + + +OPTIONS +------- +include::fetch-options.txt[] + +include::pull-fetch-param.txt[] + + + +SEE ALSO +-------- +gitlink:git-pull[1] + + +Author +------ +Written by Linus Torvalds and +Junio C Hamano + +Documentation +------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-fmt-merge-msg.html b/git-fmt-merge-msg.html new file mode 100644 index 00000000..4497155d --- /dev/null +++ b/git-fmt-merge-msg.html @@ -0,0 +1,307 @@ + + + + + + +git-fmt-merge-msg(1) + + + +

SYNOPSIS

+
+

git-fmt-merge-msg <$GIT_DIR/FETCH_HEAD

+
+

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 +passed as the <merge-message> argument of git-merge.

+

This script is intended mostly for internal use by scripts +automatically invoking git-merge.

+
+

SEE ALSO

+
+

git-merge(1)

+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-fmt-merge-msg.txt b/git-fmt-merge-msg.txt new file mode 100644 index 00000000..a70eb399 --- /dev/null +++ b/git-fmt-merge-msg.txt @@ -0,0 +1,39 @@ +git-fmt-merge-msg(1) +==================== + +NAME +---- +git-fmt-merge-msg - Produce a merge commit message + + +SYNOPSIS +-------- +'git-fmt-merge-msg' <$GIT_DIR/FETCH_HEAD + +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 +passed as the '' argument of `git-merge`. + +This script is intended mostly for internal use by scripts +automatically invoking `git-merge`. + + +SEE ALSO +-------- +gitlink:git-merge[1] + + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Petr Baudis, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-format-patch.html b/git-format-patch.html new file mode 100644 index 00000000..3ecdbad5 --- /dev/null +++ b/git-format-patch.html @@ -0,0 +1,437 @@ + + + + + + +git-format-patch(1) + + + +

SYNOPSIS

+
+

git-format-patch [-n | -k] [-o <dir> | --stdout] [-s] [-c] [--mbox] [--diff-options] <his> [<mine>]

+
+

DESCRIPTION

+
+

Prepare each commit with its patch since <mine> head forked from +<his> head, one file per patch, for e-mail submission. Each +output file is numbered sequentially from 1, and uses the first +line of the commit message (massaged for pathname safety) as the +filename.

+

When -o is specified, output files are created in that +directory; otherwise in the current working directory.

+

When -n is specified, instead of "[PATCH] Subject", the first +line is formatted as "[PATCH N/M] Subject", unless you have only +one patch.

+

When --mbox is specified, the output is formatted to resemble +UNIX mailbox format, and can be concatenated together for +processing with applymbox.

+
+

OPTIONS

+
+
+
+-o|--output-directory <dir> +
+
+

+ Use <dir> to store the resulting files, instead of the + current working directory. +

+
+
+-n|--numbered +
+
+

+ Name output in [PATCH n/m] format. +

+
+
+-k|--keep-subject +
+
+

+ Do not strip/add [PATCH] from the first line of the + commit log message. +

+
+
+-a|--author, -d|--date +
+
+

+ Output From: and Date: headers for commits made by + yourself as well. Usually these are output only for + commits made by people other than yourself. +

+
+
+-s|--signoff +
+
+

+ Add Signed-off-by: line to the commit message, using + the committer identity of yourself. +

+
+
+-c|--check +
+
+

+ Display suspicious lines in the patch. The definition + of suspicious lines is currently the lines that has + trailing whitespaces, and the lines whose indentation + has a SP character immediately followed by a TAB + character. +

+
+
+-m|--mbox +
+
+

+ Format the output files for closer to mbox format by + adding a phony Unix "From " line, so they can be + concatenated together and fed to git-applymbox. + Implies --author and --date. +

+
+
+--stdout +
+
+

+ This flag generates the mbox formatted output to the + standard output, instead of saving them into a file per + patch and implies --mbox. +

+
+
+
+

EXAMPLES

+
+
+
+git-format-patch -k --stdout R1..R2 | git-am -3 -k +
+
+

+ Extract commits between revisions R1 and R2, and apply + them on top of the current branch using git-am to + cherry-pick them. +

+
+
+git-format-patch origin +
+
+

+ Extract commits the current branch accumulated since it + pulled from origin the last time in a patch form for + e-mail submission. +

+
+
+git-format-patch -M -B origin +
+
+

+ The same as the previous one, except detect and handle + renames and complete rewrites intelligently to produce + renaming patch. A renaming patch reduces the amount of + text output, and generally makes it easier to review + it. Note that the "patch" program does not understand + renaming patch well, so use it only when you know the + recipient uses git to apply your patch. +

+
+
+
+

See Also

+
+

git-am(1), gitlink:git-send-email

+
+

Author

+
+

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

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-format-patch.txt b/git-format-patch.txt new file mode 100644 index 00000000..d7ca2dbb --- /dev/null +++ b/git-format-patch.txt @@ -0,0 +1,113 @@ +git-format-patch(1) +=================== + +NAME +---- +git-format-patch - Prepare patches for e-mail submission. + + +SYNOPSIS +-------- +'git-format-patch' [-n | -k] [-o | --stdout] [-s] [-c] [--mbox] [--diff-options] [] + +DESCRIPTION +----------- +Prepare each commit with its patch since head forked from + head, one file per patch, for e-mail submission. Each +output file is numbered sequentially from 1, and uses the first +line of the commit message (massaged for pathname safety) as the +filename. + +When -o is specified, output files are created in that +directory; otherwise in the current working directory. + +When -n is specified, instead of "[PATCH] Subject", the first +line is formatted as "[PATCH N/M] Subject", unless you have only +one patch. + +When --mbox is specified, the output is formatted to resemble +UNIX mailbox format, and can be concatenated together for +processing with applymbox. + + +OPTIONS +------- +-o|--output-directory :: + Use to store the resulting files, instead of the + current working directory. + +-n|--numbered:: + Name output in '[PATCH n/m]' format. + +-k|--keep-subject:: + Do not strip/add '[PATCH]' from the first line of the + commit log message. + +-a|--author, -d|--date:: + Output From: and Date: headers for commits made by + yourself as well. Usually these are output only for + commits made by people other than yourself. + +-s|--signoff:: + Add `Signed-off-by:` line to the commit message, using + the committer identity of yourself. + +-c|--check:: + Display suspicious lines in the patch. The definition + of 'suspicious lines' is currently the lines that has + trailing whitespaces, and the lines whose indentation + has a SP character immediately followed by a TAB + character. + +-m|--mbox:: + Format the output files for closer to mbox format by + adding a phony Unix "From " line, so they can be + concatenated together and fed to `git-applymbox`. + Implies --author and --date. + +--stdout:: + This flag generates the mbox formatted output to the + standard output, instead of saving them into a file per + patch and implies --mbox. + + +EXAMPLES +-------- + +git-format-patch -k --stdout R1..R2 | git-am -3 -k:: + Extract commits between revisions R1 and R2, and apply + them on top of the current branch using `git-am` to + cherry-pick them. + +git-format-patch origin:: + Extract commits the current branch accumulated since it + pulled from origin the last time in a patch form for + e-mail submission. + +git-format-patch -M -B origin:: + The same as the previous one, except detect and handle + renames and complete rewrites intelligently to produce + renaming patch. A renaming patch reduces the amount of + text output, and generally makes it easier to review + it. Note that the "patch" program does not understand + renaming patch well, so use it only when you know the + recipient uses git to apply your patch. + + +See Also +-------- +gitlink:git-am[1], gitlink:git-send-email + + +Author +------ +Written by Junio C Hamano + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-fsck-objects.html b/git-fsck-objects.html new file mode 100644 index 00000000..51588205 --- /dev/null +++ b/git-fsck-objects.html @@ -0,0 +1,508 @@ + + + + + + +git-fsck-objects(1) + + + +

SYNOPSIS

+
+

git-fsck-objects [--tags] [--root] [--unreachable] [--cache] [--standalone | --full] [--strict] [<object>*]

+
+

DESCRIPTION

+
+

Verifies the connectivity and validity of the objects in the database.

+
+

OPTIONS

+
+
+
+<object> +
+
+

+ An object to treat as the head of an unreachability trace. +

+

If no objects are given, git-fsck-objects defaults to using the +index file and all SHA1 references in .git/refs/* as heads.

+
+
+--unreachable +
+
+

+ Print out objects that exist but that aren't readable from any + of the reference nodes. +

+
+
+--root +
+
+

+ Report root nodes. +

+
+
+--tags +
+
+

+ Report tags. +

+
+
+--cache +
+
+

+ Consider any object recorded in the index also as a head node for + an unreachability trace. +

+
+
+--standalone +
+
+

+ Limit checks to the contents of GIT_OBJECT_DIRECTORY + ($GIT_DIR/objects), making sure that it is consistent and + complete without referring to objects found in alternate + object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, + nor packed git archives found in $GIT_DIR/objects/pack; + cannot be used with --full. +

+
+
+--full +
+
+

+ Check not just objects in GIT_OBJECT_DIRECTORY + ($GIT_DIR/objects), but also the ones found in alternate + object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, + and in packed git archives found in $GIT_DIR/objects/pack + and corresponding pack subdirectories in alternate + object pools; cannot be used with --standalone. +

+
+
+--strict +
+
+

+ Enable more strict checking, namely to catch a file mode + recorded with g+w bit set, which was created by older + versions of git. Existing repositories, including the + Linux kernel, git itself, and sparse repository have old + objects that triggers this check, but it is recommended + to check new projects with this flag. +

+
+
+

It tests SHA1 and general object sanity, and it does full tracking of +the resulting reachability and everything else. It prints out any +corruption it finds (missing or bad objects), and if you use the +--unreachable flag it will also print out objects that exist but +that aren't readable from any of the specified head nodes.

+

So for example

+
+
+
git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*)
+
+

will do quite a _lot_ of verification on the tree. There are a few +extra validity tests to be added (make sure that tree objects are +sorted properly etc), but on the whole if "git-fsck-objects" is happy, you +do have a valid tree.

+

Any corrupt objects you will have to find in backups or other archives +(ie you can just remove them and do an "rsync" with some other site in +the hopes that somebody else has the object you have corrupted).

+

Of course, "valid tree" doesn't mean that it wasn't generated by some +evil person, and the end result might be crap. git is a revision +tracking system, not a quality assurance system ;)

+
+

Extracted Diagnostics

+
+
+
+expect dangling commits - potential heads - due to lack of head information +
+
+

+ You haven't specified any nodes as heads so it won't be + possible to differentiate between un-parented commits and + root nodes. +

+
+
+missing sha1 directory <dir> +
+
+

+ The directory holding the sha1 objects is missing. +

+
+
+unreachable <type> <object> +
+
+

+ The <type> object <object>, isn't actually referred to directly + or indirectly in any of the trees or commits seen. This can + mean that there's another root node that you're not specifying + or that the tree is corrupt. If you haven't missed a root node + then you might as well delete unreachable nodes since they + can't be used. +

+
+
+missing <type> <object> +
+
+

+ The <type> object <object>, is referred to but isn't present in + the database. +

+
+
+dangling <type> <object> +
+
+

+ The <type> object <object>, is present in the database but never + directly used. A dangling commit could be a root node. +

+
+
+warning: git-fsck-objects: tree <tree> has full pathnames in it +
+
+

+ And it shouldn't… +

+
+
+sha1 mismatch <object> +
+
+

+ The database has an object who's sha1 doesn't match the + database value. + This indicates a serious data integrity problem. +

+
+
+
+

Environment Variables

+
+
+
+GIT_OBJECT_DIRECTORY +
+
+

+ used to specify the object database root (usually $GIT_DIR/objects) +

+
+
+GIT_INDEX_FILE +
+
+

+ used to specify the index file of the index +

+
+
+GIT_ALTERNATE_OBJECT_DIRECTORIES +
+
+

+ used to specify additional object database roots (usually unset) +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-fsck-objects.txt b/git-fsck-objects.txt new file mode 100644 index 00000000..bab1f608 --- /dev/null +++ b/git-fsck-objects.txt @@ -0,0 +1,144 @@ +git-fsck-objects(1) +=================== + +NAME +---- +git-fsck-objects - Verifies the connectivity and validity of the objects in the database + + +SYNOPSIS +-------- +'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache] [--standalone | --full] [--strict] [*] + +DESCRIPTION +----------- +Verifies the connectivity and validity of the objects in the database. + +OPTIONS +------- +:: + An object to treat as the head of an unreachability trace. ++ +If no objects are given, git-fsck-objects defaults to using the +index file and all SHA1 references in .git/refs/* as heads. + +--unreachable:: + Print out objects that exist but that aren't readable from any + of the reference nodes. + +--root:: + Report root nodes. + +--tags:: + Report tags. + +--cache:: + Consider any object recorded in the index also as a head node for + an unreachability trace. + +--standalone:: + Limit checks to the contents of GIT_OBJECT_DIRECTORY + ($GIT_DIR/objects), making sure that it is consistent and + complete without referring to objects found in alternate + object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, + nor packed git archives found in $GIT_DIR/objects/pack; + cannot be used with --full. + +--full:: + Check not just objects in GIT_OBJECT_DIRECTORY + ($GIT_DIR/objects), but also the ones found in alternate + object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, + and in packed git archives found in $GIT_DIR/objects/pack + and corresponding pack subdirectories in alternate + object pools; cannot be used with --standalone. + +--strict:: + Enable more strict checking, namely to catch a file mode + recorded with g+w bit set, which was created by older + versions of git. Existing repositories, including the + Linux kernel, git itself, and sparse repository have old + objects that triggers this check, but it is recommended + to check new projects with this flag. + +It tests SHA1 and general object sanity, and it does full tracking of +the resulting reachability and everything else. It prints out any +corruption it finds (missing or bad objects), and if you use the +'--unreachable' flag it will also print out objects that exist but +that aren't readable from any of the specified head nodes. + +So for example + + git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*) + +will do quite a _lot_ of verification on the tree. There are a few +extra validity tests to be added (make sure that tree objects are +sorted properly etc), but on the whole if "git-fsck-objects" is happy, you +do have a valid tree. + +Any corrupt objects you will have to find in backups or other archives +(ie you can just remove them and do an "rsync" with some other site in +the hopes that somebody else has the object you have corrupted). + +Of course, "valid tree" doesn't mean that it wasn't generated by some +evil person, and the end result might be crap. git is a revision +tracking system, not a quality assurance system ;) + +Extracted Diagnostics +--------------------- + +expect dangling commits - potential heads - due to lack of head information:: + You haven't specified any nodes as heads so it won't be + possible to differentiate between un-parented commits and + root nodes. + +missing sha1 directory '':: + The directory holding the sha1 objects is missing. + +unreachable :: + The object , isn't actually referred to directly + or indirectly in any of the trees or commits seen. This can + mean that there's another root node that you're not specifying + or that the tree is corrupt. If you haven't missed a root node + then you might as well delete unreachable nodes since they + can't be used. + +missing :: + The object , is referred to but isn't present in + the database. + +dangling :: + The object , is present in the database but never + 'directly' used. A dangling commit could be a root node. + +warning: git-fsck-objects: tree has full pathnames in it:: + And it shouldn't... + +sha1 mismatch :: + The database has an object who's sha1 doesn't match the + database value. + This indicates a serious data integrity problem. + +Environment Variables +--------------------- + +GIT_OBJECT_DIRECTORY:: + used to specify the object database root (usually $GIT_DIR/objects) + +GIT_INDEX_FILE:: + used to specify the index file of the index + +GIT_ALTERNATE_OBJECT_DIRECTORIES:: + used to specify additional object database roots (usually unset) + +Author +------ +Written by Linus Torvalds + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-get-tar-commit-id.html b/git-get-tar-commit-id.html new file mode 100644 index 00000000..e7c0ce0f --- /dev/null +++ b/git-get-tar-commit-id.html @@ -0,0 +1,305 @@ + + + + + + +git-get-tar-commit-id(1) + + + +

SYNOPSIS

+
+

git-get-tar-commit-id < <tarfile>

+
+

DESCRIPTION

+
+

Acts as a filter, extracting the commit ID stored in archives created by +git-tar-tree. It reads only the first 1024 bytes of input, thus its +runtime is not influenced by the size of <tarfile> very much.

+

If no commit ID is found, git-get-tar-commit-id quietly exists with a +return code of 1. This can happen if <tarfile> had not been created +using git-tar-tree or if the first parameter of git-tar-tree had been +a tree ID instead of a commit ID or tag.

+
+

Author

+
+

Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-get-tar-commit-id.txt b/git-get-tar-commit-id.txt new file mode 100644 index 00000000..30b1fbf6 --- /dev/null +++ b/git-get-tar-commit-id.txt @@ -0,0 +1,37 @@ +git-get-tar-commit-id(1) +======================== + +NAME +---- +git-get-tar-commit-id - Extract commit ID from an archive created using git-tar-tree. + + +SYNOPSIS +-------- +'git-get-tar-commit-id' < + + +DESCRIPTION +----------- +Acts as a filter, extracting the commit ID stored in archives created by +git-tar-tree. It reads only the first 1024 bytes of input, thus its +runtime is not influenced by the size of very much. + +If no commit ID is found, git-get-tar-commit-id quietly exists with a +return code of 1. This can happen if had not been created +using git-tar-tree or if the first parameter of git-tar-tree had been +a tree ID instead of a commit ID or tag. + + +Author +------ +Written by Rene Scharfe + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list . + +GIT +--- +Part of the gitlink:git[7] suite + diff --git a/git-grep.html b/git-grep.html new file mode 100644 index 00000000..a4c233f2 --- /dev/null +++ b/git-grep.html @@ -0,0 +1,332 @@ + + + + + + +git-grep(1) + + + +

SYNOPSIS

+
+

git-grep <option>… <pattern> <path>…

+
+

DESCRIPTION

+
+

Searches list of files git-ls-files produces for lines +containing a match to the given pattern.

+
+

OPTIONS

+
+
+
+<option>… +
+
+

+ Either an option to pass to grep or git-ls-files. + Some grep options, such as -C and -m, that take + parameters are known to git-grep. +

+
+
+<pattern> +
+
+

+ The pattern to look for. +

+
+
+<path>… +
+
+

+ Optional paths to limit the set of files to be searched; + passed to git-ls-files. +

+
+
+
+

Author

+
+

Written by Linus Torvalds <torvalds@osdl.org>

+
+

Documentation

+
+

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

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-grep.txt b/git-grep.txt new file mode 100644 index 00000000..01757934 --- /dev/null +++ b/git-grep.txt @@ -0,0 +1,46 @@ +git-grep(1) +=========== + +NAME +---- +git-grep - print lines matching a pattern + + +SYNOPSIS +-------- +'git-grep'