From 44db136cad84c003506e231a38935ca6acba4d7d Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 12 Dec 2005 16:20:21 -0800 Subject: Everyday: some examples. Signed-off-by: Junio C Hamano --- Documentation/everyday.txt | 72 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 68 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 5775cd28ac..ded4d512d8 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -59,9 +59,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 +67,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. @@ -83,6 +84,37 @@ following commands. * gitlink:git-rebase[1] to maintain topic branches. +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 . +$ git commit -m 'import of frotz source tree.' +------------ + +* Create a topic branch and develop +------------ +$ git checkout -b private +$ edit/compile/test +$ git diff <1> +$ git checkout -- foo.c <2> +$ edit/compile/test +$ git commit -a -s <3> +$ git checkout master <4> +$ git pull . private <5> + +<1> to see what changes you are committing. +<2> revert your botched changes in selected path "foo.c". +<3> commit everything as you have tested. +<4> switch to the master branch. +<5> merge a topic branch into your master branch +------------ + + Individual Developer (Participant)[[Individual Developer (Participant)]] ------------------------------------------------------------------------ @@ -100,6 +132,38 @@ addition to the ones needed by a standalone developer. 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 master <2> +$ git pull <3> +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <4> + +<1> repeat as needed. +<2> extract patches from your branch for e-mail submission. +<3> "pull" fetches from "origin" by default and merges. +<4> fetch from a specific branch from a specific repository and and merge. +------------ + +* 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 formal "merging". +------------ + + Integrator[[Integrator]] ------------------------ -- cgit v1.2.3 From 180c4746479892a9e58918b0d45f89911cb48716 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 12 Dec 2005 18:29:53 -0800 Subject: Everyday: a bit more example. Signed-off-by: Junio C Hamano --- Documentation/everyday.txt | 110 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 93 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index ded4d512d8..88df3ffc28 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -83,6 +83,7 @@ following commands. * gitlink:git-rebase[1] to maintain topic branches. + * gitlink:git-tag[1] to mark known point. Examples ~~~~~~~~ @@ -92,26 +93,48 @@ Examples $ tar zxf frotz.tar.gz $ cd frotz $ git-init-db -$ git add . +$ 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 private +$ 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 diff <1> -$ git checkout -- foo.c <2> +$ git reset --soft HEAD^ <6> $ edit/compile/test -$ git commit -a -s <3> -$ git checkout master <4> -$ git pull . private <5> - -<1> to see what changes you are committing. -<2> revert your botched changes in selected path "foo.c". -<3> commit everything as you have tested. -<4> switch to the master branch. -<5> merge a topic branch into your master branch +$ 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> or --since='aug 1', --max-count=10 +<12> view only the changes that touch what's in curses/ +directory, since v2.43 tag. ------------ @@ -142,12 +165,19 @@ $ cd my2.6 $ edit/compile/test; git commit -a -s <1> $ git format-patch master <2> $ git pull <3> -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <4> +$ 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> <1> repeat as needed. <2> extract patches from your branch for e-mail submission. <3> "pull" fetches from "origin" by default and merges. -<4> fetch from a specific branch from a specific repository and and merge. +<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. ------------ * Branch off of a specific tag. @@ -157,10 +187,11 @@ $ 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 formal "merging". +<2> forward port all changes in private2.6.14 branch to master branch +without a formal "merging". ------------ @@ -185,6 +216,51 @@ 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 pu && git reset --hard master <6> +$ git pull . topic/one topic/two && git pull . hold/linus <7> +$ git fetch ko master:refs/tags/ko-master && + git show-branch master ko-master <8> +$ git push ko <9> +$ git checkout maint +$ git cherry-pick master~4 <10> +$ compile/test +$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <11> +$ git push ko v0.99.9x <12> + +<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> restart "pu" every time from the master. +<7> and bundle topic branches still cooking. +<8> make sure I did not accidentally rewound master beyond what I +already pushed out. +<9> push out the bleeding edge. +<10> backport a critical fix. +<11> create a signed tag. +<12> push the tag out. +------------ + + Repository Administration[[Repository Administration]] ------------------------------------------------------ -- cgit v1.2.3 From 1e2ccd3abc8f5d96244806f753568493c3e77d4c Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 12 Dec 2005 23:24:06 -0800 Subject: Documentation: more examples. Signed-off-by: Junio C Hamano --- Documentation/everyday.txt | 99 +++++++++++++++++++++++++++++++++--------- Documentation/git-am.txt | 2 +- Documentation/git-branch.txt | 26 +++++++++++ Documentation/git-checkout.txt | 10 +++-- Documentation/git-clone.txt | 21 +++++++++ Documentation/git-init-db.txt | 7 ++- Documentation/git-reset.txt | 70 +++++++++++++++++++++++++++++ 7 files changed, 209 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 88df3ffc28..88bd88963a 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -50,6 +50,35 @@ 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 +------------ + + Individual Developer (Standalone)[[Individual Developer (Standalone)]] ---------------------------------------------------------------------- @@ -88,7 +117,8 @@ following commands. Examples ~~~~~~~~ -* Extract a tarball and create a working tree and a new repository to keep track of it. +Extract a tarball and create a working tree and a new repository to keep track of it:: ++ ------------ $ tar zxf frotz.tar.gz $ cd frotz @@ -101,7 +131,8 @@ $ git tag v2.43 <2> <2> make a lightweight, unannotated tag. ------------ -* Create a topic branch and develop +Create a topic branch and develop:: ++ ------------ $ git checkout -b alsa-audio <1> $ edit/compile/test @@ -158,12 +189,13 @@ addition to the ones needed by a standalone developer. Examples ~~~~~~~~ -* Clone the upstream and work on it. Feed changes to upstream. +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 master <2> +$ 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> @@ -180,7 +212,8 @@ area we are interested in. <7> garbage collect leftover objects from reverted pull. ------------ -* Branch off of a specific tag. +Branch off of a specific tag:: ++ ------------ $ git checkout -b private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a @@ -219,7 +252,8 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -* My typical GIT day. +My typical GIT day:: ++ ------------ $ git status <1> $ git show-branch <2> @@ -231,16 +265,17 @@ $ 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 pu && git reset --hard master <6> -$ git pull . topic/one topic/two && git pull . hold/linus <7> +$ 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 fetch ko master:refs/tags/ko-master && - git show-branch master ko-master <8> -$ git push ko <9> + git show-branch master ko-master <9> +$ git push ko <10> $ git checkout maint -$ git cherry-pick master~4 <10> +$ git cherry-pick master~4 <11> $ compile/test -$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <11> -$ git push ko v0.99.9x <12> +$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <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 @@ -250,14 +285,16 @@ 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> restart "pu" every time from the master. -<7> and bundle topic branches still cooking. -<8> make sure I did not accidentally rewound master beyond what I +<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> make sure I did not accidentally rewound master beyond what I already pushed out. -<9> push out the bleeding edge. -<10> backport a critical fix. -<11> create a signed tag. -<12> push the tag out. +<10> push out the bleeding edge. +<11> backport a critical fix. +<12> create a signed tag. +<13> push the tag out. ------------ @@ -276,3 +313,25 @@ 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 +------------ + +Give push/pull only access to developers:: ++ +------------ +$ grep git /etc/shells +/usr/bin/git-shell +$ grep git /etc/passwd +alice:x:1000:1000::/home/alice:/usr/bin/git-shell +bob:x:1001:1001::/home/bob:/usr/bin/git-shell +cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell +david:x:1003:1003::/home/david:/usr/bin/git-shell +------------ 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 and Junio C Hamano 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 + Documentation -------------- Documentation by Junio C Hamano and the git-list . 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-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 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 and Linus Torvalds -- cgit v1.2.3 From 76cead391f77142f153ceafcb21ba50f0b09dd15 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 12 Dec 2005 23:55:09 -0800 Subject: Documentation: fix missing links to git(7) Also move pack protocol description to technical/. Signed-off-by: Junio C Hamano --- Documentation/git-cvsexportcommit.txt | 2 +- Documentation/git.txt | 9 +++++++ Documentation/pack-protocol.txt | 38 ---------------------------- Documentation/technical/pack-protocol.txt | 41 +++++++++++++++++++++++++++++++ 4 files changed, 51 insertions(+), 39 deletions(-) delete mode 100644 Documentation/pack-protocol.txt create mode 100644 Documentation/technical/pack-protocol.txt (limited to 'Documentation') 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.txt b/Documentation/git.txt index 45773db135..d32e6cd745 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -159,6 +159,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 +214,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 +346,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. diff --git a/Documentation/pack-protocol.txt b/Documentation/pack-protocol.txt deleted file mode 100644 index 7d6aec409d..0000000000 --- a/Documentation/pack-protocol.txt +++ /dev/null @@ -1,38 +0,0 @@ -There are two Pack push-pull protocols. - -upload-pack (S) | fetch/clone-pack (C) protocol: - - # Tell the puller what commits we have and what their names are - S: SHA1 name - S: ... - S: SHA1 name - S: # flush -- it's your turn - # Tell the pusher what commits we want, and what we have - C: want name - C: .. - C: want name - C: have SHA1 - C: have SHA1 - C: ... - C: # flush -- occasionally ask "had enough?" - S: NAK - C: have SHA1 - C: ... - C: have SHA1 - S: ACK - C: done - S: XXXXXXX -- packfile contents. - -send-pack | receive-pack protocol. - - # Tell the pusher what commits we have and what their names are - C: SHA1 name - C: ... - C: SHA1 name - C: # flush -- it's your turn - # Tell the puller what the pusher has - S: old-SHA1 new-SHA1 name - S: old-SHA1 new-SHA1 name - S: ... - S: # flush -- done with the list - S: XXXXXXX --- packfile contents. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt new file mode 100644 index 0000000000..9cd48b4859 --- /dev/null +++ b/Documentation/technical/pack-protocol.txt @@ -0,0 +1,41 @@ +Pack transfer protocols +======================= + +There are two Pack push-pull protocols. + +upload-pack (S) | fetch/clone-pack (C) protocol: + + # Tell the puller what commits we have and what their names are + S: SHA1 name + S: ... + S: SHA1 name + S: # flush -- it's your turn + # Tell the pusher what commits we want, and what we have + C: want name + C: .. + C: want name + C: have SHA1 + C: have SHA1 + C: ... + C: # flush -- occasionally ask "had enough?" + S: NAK + C: have SHA1 + C: ... + C: have SHA1 + S: ACK + C: done + S: XXXXXXX -- packfile contents. + +send-pack | receive-pack protocol. + + # Tell the pusher what commits we have and what their names are + C: SHA1 name + C: ... + C: SHA1 name + C: # flush -- it's your turn + # Tell the puller what the pusher has + S: old-SHA1 new-SHA1 name + S: old-SHA1 new-SHA1 name + S: ... + S: # flush -- done with the list + S: XXXXXXX --- packfile contents. -- cgit v1.2.3 From 803f498c03b47b1da88cf8f14ba2c374f0fc16d3 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 13 Dec 2005 01:54:15 -0800 Subject: Documentation: diff examples. Signed-off-by: Junio C Hamano --- Documentation/git-diff.txt | 62 ++++++++++++++++++++++++++++++++++++++ Documentation/git-format-patch.txt | 9 ++++++ 2 files changed, 71 insertions(+) (limited to 'Documentation') 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 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 -------- -- cgit v1.2.3 From 9755afbd9467759bb77a6e5a535791243c5b907d Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 13 Dec 2005 02:38:24 -0800 Subject: Documentation: not learning core git commands. The initial section of tutorial was too heavy on internal workings for the first-time readers, so rewrite the introductory section of git(7) to start with "not learning core git commands" section and refer them to README to grasp the basic concepts, then Everyday to give overview with task/role oriented examples for minimum set of commands, and finally the tutorial. Also add to existing note in the tutorial that many too technical descriptions can be skipped by a casual reader. I initially started to review the tutorial, with the objective of ripping out the detailed technical information altogether, but I found that the level of details in the initial couple of sections that talk about refs and the object database in a hands-on fashion was about rigth, and left all of them there. I feel that reading about fsck-index and repack is too abstract without being aware of these directories and files. Signed-off-by: Junio C Hamano --- Documentation/git.txt | 51 +++++++++++++++++++++++++++------------------- Documentation/tutorial.txt | 20 +++++++++++++++++- 2 files changed, 49 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/git.txt b/Documentation/git.txt index d32e6cd745..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 <> 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 <> 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 -08/05/05 - -Updated by Junio C Hamano 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 @@ -582,14 +589,16 @@ include::../README[] Authors ------- - git's founding father is Linus Torvalds . - The current git nurse is Junio C Hamano . - The git potty was written by Andres Ericsson . - General upbringing is handled by the git-list . +* git's founding father is Linus Torvalds . +* The current git nurse is Junio C Hamano . +* The git potty was written by Andres Ericsson . +* General upbringing is handled by the git-list . Documentation -------------- -Documentation by David Greaves, Junio C Hamano and the git-list . +The documentation for git suite was started by David Greaves +, and later enhanced greatly by the +contributors on the git-list . GIT --- 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 -------------------- -- cgit v1.2.3 From 01f49e3453d9960fec62d93bc3a66784f1be4c26 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 14 Dec 2005 00:42:45 -0800 Subject: Everyday: a bit more examples. Talk about the following as well: * git fetch --tags * Use of "git push" as a one-man distributed development vehicle. * Show example of remotes file for pulling and pushing. * Annotate git-shell setup. * Using Carl's update hook in a CVS-style shared repository. Signed-off-by: Junio C Hamano --- Documentation/everyday.txt | 147 ++++++++++++++++++++++++++++++++++++--------- 1 file changed, 118 insertions(+), 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 88bd88963a..d8d7a6441a 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -53,7 +53,7 @@ Everybody uses these commands to feed and care git repositories. Examples ~~~~~~~~ -Check health and remove cruft:: +Check health and remove cruft.:: + ------------ $ git fsck-objects <1> @@ -71,11 +71,14 @@ 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:: +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 ------------ @@ -117,7 +120,7 @@ following commands. Examples ~~~~~~~~ -Extract a tarball and create a working tree and a new repository to keep track of it:: +Extract a tarball and create a working tree and a new repository to keep track of it.:: + ------------ $ tar zxf frotz.tar.gz @@ -131,7 +134,7 @@ $ git tag v2.43 <2> <2> make a lightweight, unannotated tag. ------------ -Create a topic branch and develop:: +Create a topic branch and develop.:: + ------------ $ git checkout -b alsa-audio <1> @@ -163,7 +166,8 @@ modification will be caught if you do "commit -a" later. you originally wrote. <9> switch to the master branch. <10> merge a topic branch into your master branch -<11> or --since='aug 1', --max-count=10 +<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. ------------ @@ -176,20 +180,22 @@ 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:: +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 @@ -201,6 +207,7 @@ $ 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. @@ -210,9 +217,42 @@ 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:: +Branch off of a specific tag.:: + ------------ $ git checkout -b private2.6.14 v2.6.14 <1> @@ -252,7 +292,7 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -My typical GIT day:: +My typical GIT day.:: + ------------ $ git status <1> @@ -268,13 +308,12 @@ $ 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 fetch ko master:refs/tags/ko-master && - git show-branch master ko-master <9> -$ git push ko <10> $ git checkout maint -$ git cherry-pick master~4 <11> +$ git cherry-pick master~4 <9> $ compile/test -$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <12> +$ 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. @@ -289,12 +328,20 @@ sign-offs. 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> make sure I did not accidentally rewound master beyond what I -already pushed out. -<10> push out the bleeding edge. -<11> backport a critical fix. -<12> create a signed tag. -<13> push the tag out. +<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. ------------ @@ -317,21 +364,63 @@ and maintain access to the repository by developers. Examples ~~~~~~~~ -Run git-daemon to serve /pub/scm from inetd:: +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 +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:: +Give push/pull only access to developers.:: + ------------ -$ grep git /etc/shells -/usr/bin/git-shell -$ grep git /etc/passwd +$ 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. ------------ -- cgit v1.2.3 From b3f041fb0f7de167dbb6711b0a231d36c4b5de08 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Tue, 13 Dec 2005 22:39:23 -0800 Subject: git-am support for naked email messages (take 2) This allows git-am to accept single-message files as well as mboxes. Unlike the previous version, this one doesn't need to be explicitly told which one it is; rather, it looks to see if the first line is a From line and uses it to select mbox mode or not. I moved the logic to do all this into git-mailsplit, which got a new user interface as result, although the old interface is still available for backwards compatibility. [jc: applied with two obvious fixes.] Signed-off-by: H. Peter Anvin Signed-off-by: Junio C Hamano --- Documentation/git-mailsplit.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') 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] [] +'git-mailsplit' [-b] [-f] [-d] -o [--] [...] DESCRIPTION ----------- @@ -23,11 +23,18 @@ OPTIONS :: 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:: Instead of the default 4 digits with leading zeros, different precision can be specified for the generated filenames. +-f:: + Skip the first numbers, for example if -f3 is specified, + start the numbering with 0004. Author ------ -- cgit v1.2.3 From a4adf54d38ba49e58511aaafd18e99e6d3d4dabb Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 14 Dec 2005 12:57:49 -0800 Subject: Documentation: topic branches Recommend git over ssh direct to master.kernel.org, instead of going over rsync to public machines, since this is meant to be a procedure for kernel subsystem maintainers. Also fix an obvious typo. Signed-off-by: Junio C Hamano --- Documentation/howto/using-topic-branches.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') 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 -- cgit v1.2.3