diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/everyday.txt | 302 | ||||
| -rw-r--r-- | Documentation/git-am.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-branch.txt | 26 | ||||
| -rw-r--r-- | Documentation/git-checkout.txt | 10 | ||||
| -rw-r--r-- | Documentation/git-clone.txt | 21 | ||||
| -rw-r--r-- | Documentation/git-cvsexportcommit.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-diff.txt | 62 | ||||
| -rw-r--r-- | Documentation/git-format-patch.txt | 9 | ||||
| -rw-r--r-- | Documentation/git-init-db.txt | 7 | ||||
| -rw-r--r-- | Documentation/git-mailsplit.txt | 9 | ||||
| -rw-r--r-- | Documentation/git-reset.txt | 70 | ||||
| -rw-r--r-- | Documentation/git.txt | 60 | ||||
| -rw-r--r-- | Documentation/howto/using-topic-branches.txt | 7 | ||||
| -rw-r--r-- | Documentation/technical/pack-protocol.txt (renamed from Documentation/pack-protocol.txt) | 3 | ||||
| -rw-r--r-- | Documentation/tutorial.txt | 20 |
15 files changed, 570 insertions, 40 deletions
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 5775cd28ac..d8d7a6441a 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -50,6 +50,38 @@ Everybody uses these commands to feed and care git repositories. * 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)]] ---------------------------------------------------------------------- @@ -59,9 +91,6 @@ following commands. * gitlink:git-show-branch[1] to see where you are. - * gitlink:git-diff[1] and gitlink:git-status[1] to see what - you are in the middle of doing. - * gitlink:git-log[1] to see what happened. * gitlink:git-whatchanged[1] to find out where things have @@ -70,7 +99,11 @@ following commands. * gitlink:git-checkout[1] and gitlink:git-branch[1] to switch branches. - * gitlink:git-update-index[1] to manage the index file. + * 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. @@ -82,6 +115,63 @@ following commands. * 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)]] ------------------------------------------------------------------------ @@ -90,15 +180,93 @@ 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-pull[1] from "origin" to keep up-to-date with - the upstream. + * 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 + * 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. +<4> look at the changes since last time we checked, only in the +area we are interested in. +<5> fetch from a specific branch from a specific repository and 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]] ------------------------ @@ -121,6 +289,62 @@ commands in addition to the ones needed by participants. * 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 rewound 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 +<12> push out the bleeding edge. +<13> push the tag out, too. +------------ + + Repository Administration[[Repository Administration]] ------------------------------------------------------ @@ -136,3 +360,67 @@ and maintain access to the repository by developers. * link:howto/update-hook-example.txt[update hook howto] has a good example of managing a shared central repository. + +Examples +~~~~~~~~ + +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. +------------ diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 6645e82b84..a415fe24c3 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -69,7 +69,7 @@ recover from this in one of two ways: . 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 '--resume' option. + 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, diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 98014f6d9b..d20b475735 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -32,6 +32,32 @@ 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> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index b7bb1b4c74..9442c66b18 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -50,10 +50,14 @@ the `Makefile` to two revisions back, deletes hello.c by mistake, and gets it back from the index. ------------ -$ git checkout master -$ git checkout master~2 Makefile +$ git checkout master <1> +$ git checkout master~2 Makefile <2> $ rm -f hello.c -$ git checkout 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 diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 83f58ae536..8410a6d381 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -74,10 +74,31 @@ OPTIONS 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>. diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt index c3da73d1cd..91def2b515 100644 --- a/Documentation/git-cvsexportcommit.txt +++ b/Documentation/git-cvsexportcommit.txt @@ -8,7 +8,7 @@ git-cvsexportcommit - Export a commit to a CVS checkout SYNOPSIS -------- -git-cvsapplycommmit.perl +git-cvsexportcommmit.perl [ -h ] [ -v ] [ -c ] [ -p ] [PARENTCOMMIT] COMMITID diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index cf7527f5e9..b04f393bc4 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -40,6 +40,68 @@ OPTIONS 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> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index abb8fc89f4..d7ca2dbb22 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -84,6 +84,15 @@ git-format-patch origin:: 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 -------- diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 4486f0c1cf..6deef92508 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -40,9 +40,12 @@ Start a new git repository for an existing code base:: + ---------------- $ cd /path/to/my/codebase -$ git-init-db ----------------- +$ git-init-db <1> +$ git-add . <2> +<1> prepare /path/to/my/codebase/.git directory +<2> add all existing file to the index +---------------- Author diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt index 03a9477664..e0703e9dfa 100644 --- a/Documentation/git-mailsplit.txt +++ b/Documentation/git-mailsplit.txt @@ -7,7 +7,7 @@ git-mailsplit - Totally braindamaged mbox splitter program. SYNOPSIS -------- -'git-mailsplit' [-d<prec>] [<mbox>] <directory> +'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>...] DESCRIPTION ----------- @@ -23,11 +23,18 @@ OPTIONS <directory>:: Directory in which to place the individual messages. +-b:: + If any file doesn't begin with a From line, assume it is a + single mail message instead of signalling error. + -d<prec>:: Instead of the default 4 digits with leading zeros, different precision can be specified for the generated filenames. +-f<nn>:: + Skip the first <nn> numbers, for example if -f3 is specified, + start the numbering with 0004. Author ------ diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 6af3a4fdb9..02048918bf 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -42,6 +42,76 @@ OPTIONS <commit-ish>:: Commit to make the current HEAD. +Examples +~~~~~~~~ + +Undo a commit and redo:: ++ +------------ +$ git commit ... +$ git reset --soft HEAD^ <1> +$ edit <2> +$ git commit -a -c ORIG_HEAD <3> + +<1> This is most often done when you remembered what you +just committed is incomplete, or you misspelled your commit +message, or both. Leaves working tree as it was before "reset". +<2> make corrections to working tree files. +<3> "reset" copies the old head to .git/ORIG_HEAD; redo the +commit by starting with its log message. If you do not need to +edit the message further, you can give -C option instead. +------------ + +Undo commits permanently:: ++ +------------ +$ git commit ... +$ git reset --hard HEAD~3 <1> + +<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad +and you do not want to ever see them again. Do *not* do this if +you have already given these commits to somebody else. +------------ + +Undo a commit, making it a topic branch:: ++ +------------ +$ git branch topic/wip <1> +$ git reset --hard HEAD~3 <2> +$ git checkout topic/wip <3> + +<1> You have made some commits, but realize they were premature +to be in the "master" branch. You want to continue polishing +them in a topic branch, so create "topic/wip" branch off of the +current HEAD. +<2> Rewind the master branch to get rid of those three commits. +<3> Switch to "topic/wip" branch and keep working. +------------ + +Undo update-index:: ++ +------------ +$ edit <1> +$ git-update-index frotz.c filfre.c +$ mailx <2> +$ git reset <3> +$ git pull git://info.example.com/ nitfol <4> + +<1> you are happily working on something, and find the changes +in these files are in good order. You do not want to see them +when you run "git diff", because you plan to work on other files +and changes with these files are distracting. +<2> somebody asks you to pull, and the changes sounds worthy of merging. +<3> however, you already dirtied the index (i.e. your index does +not match the HEAD commit). But you know the pull you are going +to make does not affect frotz.c nor filfre.c, so you revert the +index changes for these two files. Your changes in working tree +remain there. +<4> then you can pull and merge, leaving frotz.c and filfre.c +changes still in the working tree. +------------ + + Author ------ Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org> diff --git a/Documentation/git.txt b/Documentation/git.txt index 45773db135..482eba7eba 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -33,34 +33,41 @@ OPTIONS environment variable. If no path is given 'git' will print the current setting and then exit. -CORE GIT COMMANDS ------------------ -Before reading this cover to cover, you may want to take a look -at the link:tutorial.html[tutorial] document. If you are -migrating from CVS, link:cvs-migration.html[cvs migration] -document may be helpful after you finish the tutorial. - -The <<Discussion>> section below contains much useful definition -and clarification info - read that first. After that, if you -are interested in using git to manage (version control) + +NOT LEARNING CORE GIT COMMANDS +------------------------------ + +This manual is intended to give complete background information +and internal workings of git, which may be too much for most +people. The <<Discussion>> section below contains much useful +definition and clarification - read that first. + +If you are interested in using git to manage (version control) projects, use link:everyday.html[Everyday GIT] as a guide to the minimum set of commands you need to know for day-to-day work. +Most likely, that will get you started, and you can go a long +way without knowing the low level details too much. + +The link:tutorial.html[tutorial] document covers how things +internally work. + +If you are migrating from CVS, link:cvs-migration.html[cvs +migration] document may be helpful after you finish the +tutorial. After you get the general feel from the tutorial and this overview page, you may want to take a look at the link:howto-index.html[howto] documents. + +CORE GIT COMMANDS +----------------- + If you are writing your own Porcelain, you need to be familiar with most of the low level commands --- I suggest starting from gitlink:git-update-index[1] and gitlink:git-read-tree[1]. -David Greaves <david@dgreaves.com> -08/05/05 - -Updated by Junio C Hamano <junkio@cox.net> on 2005-05-05 and -further on 2005-12-07 to reflect recent changes. - Commands Overview ----------------- The git commands can helpfully be split into those that manipulate @@ -159,6 +166,9 @@ gitlink:git-merge-base[1]:: gitlink:git-name-rev[1]:: Find symbolic names for given revs. +gitlink:git-pack-redundant[1]:: + Find redundant pack files. + gitlink:git-rev-list[1]:: Lists commit objects in reverse chronological order. @@ -211,6 +221,9 @@ gitlink:git-receive-pack[1]:: gitlink:git-send-pack[1]:: Pushes to a remote repository, intelligently. +gitlink:git-http-push[1]:: + Push missing objects using HTTP/DAV. + gitlink:git-shell[1]:: Restricted shell for GIT-only SSH access. @@ -340,6 +353,9 @@ gitlink:git-convert-objects[1]:: gitlink:git-cvsimport[1]:: Salvage your data out of another SCM people love to hate. +gitlink:git-cvsexportcommit[1]:: + Export a single commit to a CVS checkout. + gitlink:git-lost-found[1]:: Recover lost refs that luckily have not yet been pruned. @@ -573,14 +589,16 @@ include::../README[] Authors ------- - git's founding father is Linus Torvalds <torvalds@osdl.org>. - The current git nurse is Junio C Hamano <junkio@cox.net>. - The git potty was written by Andres Ericsson <ae@op5.se>. - General upbringing is handled by the git-list <git@vger.kernel.org>. +* git's founding father is Linus Torvalds <torvalds@osdl.org>. +* The current git nurse is Junio C Hamano <junkio@cox.net>. +* The git potty was written by Andres Ericsson <ae@op5.se>. +* General upbringing is handled by the git-list <git@vger.kernel.org>. Documentation -------------- -Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. +The documentation for git suite was started by David Greaves +<david@dgreaves.com>, and later enhanced greatly by the +contributors on the git-list <git@vger.kernel.org>. GIT --- diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt index 4698abe46b..494429738f 100644 --- a/Documentation/howto/using-topic-branches.txt +++ b/Documentation/howto/using-topic-branches.txt @@ -31,7 +31,7 @@ test tree and then pull to the release tree as that would leave trivial patches blocked in the test tree waiting for complex changes to accumulate enough test time to graduate. -Back in the BitKeeper days I achieved this my creating small forests of +Back in the BitKeeper days I achieved this by creating small forests of temporary trees, one tree for each logical grouping of patches, and then pulling changes from these trees first to the test tree, and then to the release tree. At first I replicated this in GIT, but then I realised @@ -42,7 +42,8 @@ So here is the step-by-step guide how this all works for me. First create your work tree by cloning Linus's public tree: - $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work + $ git clone \ + master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work Change directory into the cloned tree you just created @@ -52,7 +53,7 @@ Set up a remotes file so that you can fetch the latest from Linus' master branch into a local branch named "linus": $ cat > .git/remotes/linus - URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Pull: master:linus ^D diff --git a/Documentation/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 7d6aec409d..9cd48b4859 100644 --- a/Documentation/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -1,3 +1,6 @@ +Pack transfer protocols +======================= + There are two Pack push-pull protocols. upload-pack (S) | fetch/clone-pack (C) protocol: diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 0827056e1c..a61b824443 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -18,7 +18,14 @@ doing. The core git is often called "plumbing", with the prettier user interfaces on top of it called "porcelain". You may not want to use the plumbing directly very often, but it can be good to know what the -plumbing does for when the porcelain isn't flushing... +plumbing does for when the porcelain isn't flushing. + +The material presented here often goes deep describing how things +work internally. If you are mostly interested in using git as a +SCM, you can skip them during your first pass. + +[NOTE] +And those "too deep" descriptions are often marked as Note. Creating a git repository @@ -252,6 +259,17 @@ tree. That's very useful. A common shorthand for `git-diff-files -p` is to just write `git diff`, which will do the same thing. +------------ +$ git diff +diff --git a/hello b/hello +index 557db03..263414f 100644 +--- a/hello ++++ b/hello +@@ -1 +1,2 @@ + Hello World ++It's a new day for git +------------ + Committing git state -------------------- |