From 5214f7704474553d8d933d8055db410106d8581e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=1B=2CAv=1B=28Bnig?= Date: Tue, 16 Jan 2007 16:02:02 +0100 Subject: [PATCH 01/27] document --exec for git-push MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The text is just copied from git-send-pack.txt. Signed-off-by: Uwe Kleine-K,Av(Bnig Signed-off-by: Junio C Hamano --- Documentation/git-push.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 197f4b512f..a19631d4b8 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- -'git-push' [--all] [--tags] [-f | --force] ... +'git-push' [--all] [--tags] [--exec=] [-f | --force] ... DESCRIPTION ----------- @@ -67,6 +67,12 @@ the remote repository. addition to refspecs explicitly listed on the command line. +\--exec:: + Path to the 'git-receive-pack' program on the remote + end. Sometimes useful when pushing to a remote + repository over ssh, and you do not have the program in + a directory on the default $PATH. + -f, \--force:: Usually, the command refuses to update a remote ref that is not a descendant of the local ref used to overwrite it. From dc36f26525a5f94fbb1dddc3ae342e6bc638258c Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 11:46:03 -0800 Subject: [PATCH 02/27] git-push documentation: remaining bits Mention --thin, --no-thin, --repo and -v. Signed-off-by: Junio C Hamano --- Documentation/git-push.txt | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index a19631d4b8..3e8dbcf93a 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- -'git-push' [--all] [--tags] [--exec=] [-f | --force] ... +'git-push' [--all] [--tags] [--exec=] [--repo=all] [-f | --force] [-v] [ ...] DESCRIPTION ----------- @@ -79,6 +79,18 @@ the remote repository. This flag disables the check. This can cause the remote repository to lose commits; use it with care. +\--repo=:: + When no repository is specified the command defaults to + "origin"; this overrides it. + +\--thin, \--no-thin:: + These options are passed to `git-send-pack`. Thin + transfer spends extra cycles to minimize the number of + objects to be sent and meant to be used on slower connection. + +-v:: + Run verbosely. + include::urls.txt[] Author From a9877f83e0da46efcbc552bd439acee2dcc499d0 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 11:50:29 -0800 Subject: [PATCH 03/27] git-rm documentation: remove broken behaviour from the example. The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano --- Documentation/git-rm.txt | 12 ++++-------- builtin-rm.c | 2 +- 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 3a8f279e1a..6feebc0400 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file. EXAMPLES -------- git-rm Documentation/\\*.txt:: - Removes all `\*.txt` files from the index that are under the - `Documentation` directory and any of its subdirectories. The - files are not removed from the working tree. + `Documentation` directory and any of its subdirectories. + Note that the asterisk `\*` is quoted from the shell in this example; this lets the command include the files from subdirectories of `Documentation/` directory. git-rm -f git-*.sh:: - - Remove all git-*.sh scripts that are in the index. The files - are removed from the index, and from the working - tree. Because this example lets the shell expand the - asterisk (i.e. you are listing the files explicitly), it + Remove all git-*.sh scripts that are in the index. + Because this example lets the shell expand the asterisk + (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. See Also diff --git a/builtin-rm.c b/builtin-rm.c index d81f289c3c..00dbe39960 100644 --- a/builtin-rm.c +++ b/builtin-rm.c @@ -10,7 +10,7 @@ #include "tree-walk.h" static const char builtin_rm_usage[] = -"git-rm [-n] [-f] [--cached] ..."; +"git-rm [-f] [-n] [-r] [--cached] [--] ..."; static struct { int nr, alloc; From 8bef62049b46038334ed6f065fdac27758070a5e Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Tue, 16 Jan 2007 22:10:54 +0100 Subject: [PATCH 04/27] Fix spurious compile error From time to time, I would get this error: [...] sed: -e expression #8, char 41: Unterminated `s' command make: *** [git-add--interactive] Error 1 Turns out that the function WriteMakefile() called in Makefile.PL outputs the message "Writing perl.mak for Git" to stdout! Thus, the output of "make -C perl -s --no-print-directory instlibdir" would be prefixed by that message whenever Makefile.PL was newer than perl.mak. This is fixed by redirecting stdout to stderr in Makefile.PL. Signed-off-by: Johannes E. Schindelin Signed-off-by: Junio C Hamano --- perl/Makefile.PL | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/perl/Makefile.PL b/perl/Makefile.PL index 41687757a7..9b117fd0d7 100644 --- a/perl/Makefile.PL +++ b/perl/Makefile.PL @@ -20,6 +20,10 @@ if ($@) { my %extra; $extra{DESTDIR} = $ENV{DESTDIR} if $ENV{DESTDIR}; +# redirect stdout, otherwise the message "Writing perl.mak for Git" +# disrupts the output for the target 'instlibdir' +open STDOUT, ">&STDERR"; + WriteMakefile( NAME => 'Git', VERSION_FROM => 'Git.pm', From 8b616f24ea5f18a13bd274f9dd9a1a42e6c4b223 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Santi=20B=C3=A9jar?= Date: Wed, 17 Jan 2007 01:09:12 +0100 Subject: [PATCH 05/27] tutorial: Use only separate layout MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Then the newbies only have to understand one layout. Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano --- Documentation/tutorial.txt | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 8325c5e53a..1b93013041 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -283,10 +283,12 @@ at /home/bob/myrepo. She does this with: ------------------------------------------------ $ cd /home/alice/project -$ git pull /home/bob/myrepo master +$ git remote add bob /home/bob/myrepo +$ git pull bob master ------------------------------------------------ -This merges the changes from Bob's "master" branch into Alice's +First it adds the "remote" Bob's repository with the name "bob" and +then it merges the changes from Bob's "master" branch into Alice's current branch. If Alice has made her own changes in the meantime, then she may need to manually fix any conflicts. (Note that the "master" argument in the above command is actually unnecessary, as it @@ -296,18 +298,16 @@ The "pull" command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch. You can perform the first operation alone using the "git fetch" -command. For example, Alice could create a temporary branch just to -track Bob's changes, without merging them with her own, using: +command without merging them with her own branch, using: ------------------------------------- -$ git fetch /home/bob/myrepo master:bob-incoming +$ git fetch bob ------------------------------------- -which fetches the changes from Bob's master branch into a new branch -named bob-incoming. Then +which fetches the changes from Bob's branches. Then ------------------------------------- -$ git log -p master..bob-incoming +$ git log -p master..bob/master ------------------------------------- shows a list of all the changes that Bob made since he branched from @@ -318,21 +318,21 @@ could merge the changes into her master branch: ------------------------------------- $ git checkout master -$ git merge bob-incoming +$ git merge bob/master ------------------------------------- -The last command is a merge from the "bob-incoming" branch in Alice's +The last command is a merge of the "bob/master" branch in Alice's own repository. Alice could also perform both steps at once with: ------------------------------------- -$ git pull /home/bob/myrepo master:bob-incoming +$ git pull bob ------------------------------------- -This is just like the "git pull /home/bob/myrepo master" that we saw +This is just like the "git pull bob master" that we saw before, except that it also stores the unmerged changes from bob's -master branch in bob-incoming before merging them into Alice's +master branch in bob/master before merging them into Alice's current branch. Note that git pull always merges into the current branch, regardless of what else is given on the commandline. From c1ff284a702c487e4a6f4966b69adff83cd5cf37 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:10:14 +0100 Subject: [PATCH 06/27] tutorial: shorthand for remotes but show distributed nature of git MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Promiscous pull shows the distributed nature of git better. * Add a new step after that to teach "remote add". * Highlight that with the shorthand defined you will get remote tracking branches for free. * Fix Alice's workflow. Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano --- Documentation/tutorial.txt | 43 +++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 1b93013041..c27a4505d4 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -283,12 +283,10 @@ at /home/bob/myrepo. She does this with: ------------------------------------------------ $ cd /home/alice/project -$ git remote add bob /home/bob/myrepo -$ git pull bob master +$ git pull /home/bob/myrepo master ------------------------------------------------ -First it adds the "remote" Bob's repository with the name "bob" and -then it merges the changes from Bob's "master" branch into Alice's +This merges the changes from Bob's "master" branch into Alice's current branch. If Alice has made her own changes in the meantime, then she may need to manually fix any conflicts. (Note that the "master" argument in the above command is actually unnecessary, as it @@ -297,14 +295,27 @@ is the default.) The "pull" command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch. -You can perform the first operation alone using the "git fetch" -command without merging them with her own branch, using: +When you are working in a small closely knit group, it is not +unusual to interact with the same repository over and over +again. By defining 'remote' repository shorthand, you can make +it easier: + +------------------------------------------------ +$ git remote add bob /home/bob/myrepo +------------------------------------------------ + +With this, you can perform the first operation alone using the +"git fetch" command without merging them with her own branch, +using: ------------------------------------- $ git fetch bob ------------------------------------- -which fetches the changes from Bob's branches. Then +Unlike the longhand form, when Alice fetches from Bob using a +remote repository shorthand set up with `git remote`, what was +fetched is stored in a remote tracking branch, in this case +`bob/master`. So after this: ------------------------------------- $ git log -p master..bob/master @@ -313,28 +324,22 @@ $ git log -p master..bob/master shows a list of all the changes that Bob made since he branched from Alice's master branch. -After examining those changes, and possibly fixing things, Alice +After examining those changes, Alice could merge the changes into her master branch: ------------------------------------- -$ git checkout master $ git merge bob/master ------------------------------------- -The last command is a merge of the "bob/master" branch in Alice's -own repository. - -Alice could also perform both steps at once with: +This `merge` can also be done by 'pulling from her own remote +tracking branch', like this: ------------------------------------- -$ git pull bob +$ git pull . remotes/bob/master ------------------------------------- -This is just like the "git pull bob master" that we saw -before, except that it also stores the unmerged changes from bob's -master branch in bob/master before merging them into Alice's -current branch. Note that git pull always merges into the current -branch, regardless of what else is given on the commandline. +Note that git pull always merges into the current branch, +regardless of what else is given on the commandline. Later, Bob can update his repo with Alice's latest changes using From 7905ba626e14c32d09a412c168931486ceedb6ec Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 16:36:54 -0800 Subject: [PATCH 07/27] git-commit documentation: remove comment on unfixed git-rm ... which was fixed since then. Signed-off-by: Junio C Hamano --- Documentation/git-commit.txt | 5 ----- 1 file changed, 5 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index b4528d72ba..6139386ad7 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -142,11 +142,6 @@ $ git add hello.c $ git commit ------------ -//////////// -We should fix 'git rm' to remove goodbye.c from both index and -working tree for the above example. -//////////// - Instead of staging files after each individual change, you can tell `git commit` to notice the changes to the files whose contents are tracked in From c1a4278ee3f99ca9db94bd032b047b3d19ac6e5f Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 20:46:39 -0800 Subject: [PATCH 08/27] Use merge-recursive in git-checkout -m (branch switching) This allows "git checkout -m " to notice renames and carry local changes in the working tree forward. Signed-off-by: Junio C Hamano --- git-checkout.sh | 5 +++-- t/t7201-co.sh | 41 +++++++++++++++++++++++++++++++++-------- 2 files changed, 36 insertions(+), 10 deletions(-) diff --git a/git-checkout.sh b/git-checkout.sh index 66e40b90eb..e02d4d87f6 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -201,8 +201,9 @@ else git diff-files --name-only | git update-index --remove --stdin && work=`git write-tree` && git read-tree --reset -u $new && - git read-tree -m -u --aggressive --exclude-per-directory=.gitignore $old $new $work || - exit + eval GITHEAD_$new=${new_name:-${branch:-$new}} GITHEAD_$work=local && + export GITHEAD_$new GITHEAD_$work && + git merge-recursive $old -- $new $work || exit if result=`git write-tree 2>/dev/null` then diff --git a/t/t7201-co.sh b/t/t7201-co.sh index 085d4a096b..315fa3564c 100755 --- a/t/t7201-co.sh +++ b/t/t7201-co.sh @@ -14,15 +14,23 @@ fill () { done } + test_expect_success setup ' - fill 1 2 3 4 5 >one && + fill 1 2 3 4 5 6 7 8 >one && fill a b c d e >two && git add one two && git commit -m "Initial A one, A two" && - git checkout -b side && - fill 1 2 3 >one && + git checkout -b renamer && + rm -f one && + fill 1 3 4 5 6 7 8 >uno && + git add uno && + fill a b c d e f >two && + git commit -a -m "Renamer R one->uno, M two" && + + git checkout -b side master && + fill 1 2 3 4 5 6 7 >one && fill A B C D E >three && rm -f two && git update-index --add --remove one two three && @@ -42,7 +50,7 @@ test_expect_success "checkout from non-existing branch" ' test_expect_success "checkout with dirty tree without -m" ' - fill 0 1 2 3 4 5 >one && + fill 0 1 2 3 4 5 6 7 8 >one && if git checkout side then echo Not happy @@ -58,12 +66,10 @@ test_expect_success "checkout -m with dirty tree" ' git checkout -f master && git clean && - fill 0 1 2 3 4 5 >one && + fill 0 1 2 3 4 5 6 7 8 >one && git checkout -m side && - fill " master" "* side" >expect.branch && - git branch >current.branch && - diff expect.branch current.branch && + test "$(git symbolic-ref HEAD)" = "refs/heads/side" && fill "M one" "A three" "D two" >expect.master && git diff --name-status master >current.master && @@ -78,4 +84,23 @@ test_expect_success "checkout -m with dirty tree" ' diff expect.index current.index ' +test_expect_success "checkout -m with dirty tree, renamed" ' + + git checkout -f master && git clean && + + fill 1 2 3 4 5 7 8 >one && + if git checkout renamer + then + echo Not happy + false + else + echo "happy - failed correctly" + fi && + + git checkout -m renamer && + fill 1 3 4 5 7 8 >expect && + diff expect uno && + ! test -f one +' + test_done From 5ea5621f89f0fe7d9a13c862cc738eb3588b8ddd Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 22:45:35 -0800 Subject: [PATCH 09/27] Document where configuration files are in config.txt Talking about what the files contain without talking about where they are does not help new users. Signed-off-by: Junio C Hamano --- Documentation/config.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index faa17ba848..da7fde56b4 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2,7 +2,12 @@ CONFIGURATION FILE ------------------ The git configuration file contains a number of variables that affect -the git command's behavior. They can be used by both the git plumbing +the git command's behavior. `.git/config` file for each repository +is used to store the information for that repository, and +`$HOME/.gitconfig` is used to store per user information to give +fallback values for `.git/config` file. + +They can be used by both the git plumbing and the porcelains. The variables are divided into sections, where in the fully qualified variable name the variable itself is the last dot-separated segment and the section name is everything before the last From 276bc2caab78a4493b35f8d582dd8eeff4866615 Mon Sep 17 00:00:00 2001 From: Chris Wedgwood Date: Tue, 16 Jan 2007 22:28:02 -0800 Subject: [PATCH 10/27] cache.h; fix a couple of prototypes Trivial patch. Signed-off-by: Junio C Hamano --- cache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index 620b6a4ed4..fda3f8ec16 100644 --- a/cache.h +++ b/cache.h @@ -317,7 +317,7 @@ void datestamp(char *buf, int bufsize); unsigned long approxidate(const char *); extern int setup_ident(void); -extern void ignore_missing_committer_name(); +extern void ignore_missing_committer_name(void); extern const char *git_author_info(int); extern const char *git_committer_info(int); @@ -400,7 +400,7 @@ extern void install_packed_git(struct packed_git *pack); extern struct packed_git *find_sha1_pack(const unsigned char *sha1, struct packed_git *packs); -extern void pack_report(); +extern void pack_report(void); extern unsigned char* use_pack(struct packed_git *, struct pack_window **, unsigned long, unsigned int *); extern void unuse_pack(struct pack_window **); extern struct packed_git *add_packed_git(char *, int, int); From 936f32d3de468db8daf853155ddd5c6b191af60c Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 16 Jan 2007 22:53:28 -0800 Subject: [PATCH 11/27] git-commit: document log message formatting convention Take it from the tutorial, since not everybody necessarily reads it. Signed-off-by: Junio C Hamano --- Documentation/git-commit.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 6139386ad7..9c84353068 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -218,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option). DISCUSSION ---------- +Though not required, it's a good idea to begin the commit message +with a single short (less than 50 character) line summarizing the +change, followed by a blank line and then a more thorough description. +Tools that turn commits into email, for example, use the first line +on the Subject: line and the rest of the commit in the body. + include::i18n.txt[] ENVIRONMENT VARIABLES From e30b217ba41081f5f11206ca3dfb987725315304 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:07:27 -0800 Subject: [PATCH 12/27] Documentation/SubmittingPatches: Gnus tips Also warn about format=flowed (aka 'flawed'). Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 646b6e7331..41b76d8a4a 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -72,7 +72,9 @@ other than the commit message itself. Place such "cover letter" material between the three dash lines and the diffstat. Do not attach the patch as a MIME attachment, compressed or not. -Do not let your e-mail client send quoted-printable. Many +Do not let your e-mail client send quoted-printable. Do not let +your e-mail client send format=flowed which would destroy +whitespaces in your patches. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes a bit more time to @@ -312,3 +314,19 @@ settings but I haven't tried, yet. mail.identity.default.compose_html => false mail.identity.id?.compose_html => false + + +Gnus +---- + +'|' in the *Summary* buffer can be used to pipe the current +message to an external program, and this is a handy way to drive +"git am". However, if the message is MIME encoded, what is +piped into the program is the representation you see in your +*Article* buffer after unwrapping MIME. This is often not what +you would want for two reasons. It tends to screw up non ASCII +characters (most notably in people's names), and also +whitespaces (fatal in patches). Running 'C-u g' to display the +message in raw form before using '|' to run the pipe can work +this problem around. + From 79d5b81fee8fa3213276b8c287a18c7ed2aefdb9 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:08:30 -0800 Subject: [PATCH 13/27] Documentation/git-tag: the command can be used to also verify a tag. Signed-off-by: Junio C Hamano --- Documentation/git-tag.txt | 2 +- Documentation/git.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 80bece0775..8a71ab37df 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -3,7 +3,7 @@ git-tag(1) NAME ---- -git-tag - Create a tag object signed with GPG +git-tag - Create or verify a tag object signed with GPG SYNOPSIS diff --git a/Documentation/git.txt b/Documentation/git.txt index f89d745efa..6a82803f31 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -246,7 +246,7 @@ gitlink:git-symbolic-ref[1]:: Read and modify symbolic refs. gitlink:git-tag[1]:: - An example script to create a tag object signed with GPG. + Create or verify a tag object signed with GPG. gitlink:git-update-ref[1]:: Update the object name stored in a ref safely. From e54155750876ac81ff8be945903177e833f457a9 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:09:41 -0800 Subject: [PATCH 14/27] Documentation/git-tools.txt: mention tig and refer to wiki In general list at Wiki seems to be maintained a lot better than this list. Signed-off-by: Junio C Hamano --- Documentation/git-tools.txt | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 0914cbb0ba..6b407f9adf 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -50,7 +50,7 @@ History Viewers gitview is a GTK based repository browser for git - - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/) + - *gitweb* (shipped with git-core) GITweb provides full-fledged web interface for GIT repositories. @@ -63,12 +63,18 @@ History Viewers Currently it is the fastest and most feature rich among the git viewers and commit tools. + - *tig* (http://jonas.nitro.dk/tig/) + + tig by Jonas Fonseca is a simple git repository browser + written using ncurses. Basically, it just acts as a front-end + for git-log and git-show/git-diff. Additionally, you can also + use it as a pager for git commands. Foreign SCM interface --------------------- - - *git-svn* (contrib/) + - *git-svn* (shipped with git-core) git-svn is a simple conduit for changesets between a single Subversion branch and git. @@ -95,3 +101,7 @@ Others This is an Emacs interface for git. The user interface is modeled on pcl-cvs. It has been developed on Emacs 21 and will probably need some tweaking to work on XEmacs. + + +http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more +comprehensive list. From 0f2ba25d54b143e08bdb7b24316c3dbad6fef558 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:10:13 -0800 Subject: [PATCH 15/27] Documentation/git-tar-tree.txt: default umask is now 002 Signed-off-by: Junio C Hamano --- Documentation/git-tar-tree.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt index 74a6fddd9a..bc3360f079 100644 --- a/Documentation/git-tar-tree.txt +++ b/Documentation/git-tar-tree.txt @@ -50,7 +50,7 @@ repository configuration as follows : umask = 002 ;# group friendly The special umask value "user" indicates that the user's current umask -will be used instead. The default value remains 0, which means world +will be used instead. The default value is 002, which means group readable/writable files and directories. EXAMPLES From 31fcd63c4a0c07f110c6adc600da2671bc566f36 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:11:01 -0800 Subject: [PATCH 16/27] Documentation/git-status.txt: mention color configuration Signed-off-by: Junio C Hamano --- Documentation/git-status.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index ce7857e5a9..7f86d8cd5d 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit template comments, and all the output lines are prefixed with '#'. +CONFIGURATION +------------- + +The command honors `color.status` (or `status.color` -- they +mean the same thing and the latter is kept for backward +compatibility) and `color.status.` configuration variables +to colorize its output. + + Author ------ Written by Linus Torvalds and From 705517266794f94b7956f29ace0d7cc1caa89c39 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:11:56 -0800 Subject: [PATCH 17/27] Documentation/git-whatchanged.txt: show - instead of --max-count. ... to match the change we did earlier to git-log documentation. Signed-off-by: Junio C Hamano --- Documentation/git-whatchanged.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index e8f21d02f7..399bff3bbc 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -27,7 +27,7 @@ OPTIONS output format that is useful only to tell the changed paths and their nature of changes. ---max-count=:: +-:: Limit output to commits. ..:: From 850844e28f728625ba96b7880a0a264a5578e4c6 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 01:13:05 -0800 Subject: [PATCH 18/27] Documentation/git-sh-setup.txt: programmer's docs Clarify that this is not meant for end users, and list what shell functions are defined. Signed-off-by: Junio C Hamano --- Documentation/git-sh-setup.txt | 51 +++++++++++++++++++++++++++++----- 1 file changed, 44 insertions(+), 7 deletions(-) diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt index 79217d8a56..2b2abebd60 100644 --- a/Documentation/git-sh-setup.txt +++ b/Documentation/git-sh-setup.txt @@ -12,14 +12,51 @@ SYNOPSIS DESCRIPTION ----------- -Sets up the normal git environment variables and a few helper functions -(currently just "die()"), and returns OK if it all looks like a git archive. -So, to make the rest of the git scripts more careful and readable, -use it as follows: +This is not a command the end user would want to run. Ever. +This documentation is meant for people who are studying the +Porcelain-ish scripts and/or are writing new ones. + +The `git-sh-setup` scriptlet is designed to be sourced (using +`.`) by other shell scripts to set up some variables pointing at +the normal git directories and a few helper shell functions. + +Before sourcing it, your script should set up a few variables; +`USAGE` (and `LONG_USAGE`, if any) is used to define message +given by `usage()` shell function. `SUBDIRECTORY_OK` can be set +if the script can run from a subdirectory of the working tree +(some commands do not). + +The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell +variables, but does *not* export them to the environment. + +FUNCTIONS +--------- + +die:: + exit after emitting the supplied error message to the + standard error stream. + +usage:: + die with the usage message. + +set_reflog_action:: + set the message that will be recorded to describe the + end-user action in the reflog, when the script updates a + ref. + +is_bare_repository:: + outputs `true` or `false` to the standard output stream + to indicate if the repository is a bare repository + (i.e. without an associated working tree). + +cd_to_toplevel:: + runs chdir to the toplevel of the working tree. + +require_work_tree:: + checks if the repository is a bare repository, and dies + if so. Used by scripts that require working tree + (e.g. `checkout`). -------------------------------------------------- -. git-sh-setup || die "Not a git archive" -------------------------------------------------- Author ------ From 23bfbb815d7d71ff20c014f4610732597f0a75db Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Scharfe?= Date: Wed, 17 Jan 2007 16:32:41 +0100 Subject: [PATCH 19/27] Documentation: a few spelling fixes Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano --- Documentation/git-add.txt | 2 +- Documentation/git-blame.txt | 8 ++++---- Documentation/git-branch.txt | 2 +- Documentation/git-commit.txt | 2 +- Documentation/git-cvsimport.txt | 2 +- Documentation/git-for-each-ref.txt | 2 +- Documentation/git-gc.txt | 2 +- Documentation/git-grep.txt | 2 +- Documentation/git-ls-remote.txt | 2 +- Documentation/git-rerere.txt | 2 +- Documentation/git-shortlog.txt | 2 +- Documentation/git-svn.txt | 2 +- 12 files changed, 15 insertions(+), 15 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 95bea66374..a5051aad6b 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -83,7 +83,7 @@ git-add git-*.sh:: Interactive mode ---------------- When the command enters the interactive mode, it shows the -output of the 'status' subcommand, and then goes into ints +output of the 'status' subcommand, and then goes into its interactive command loop. The command loop shows the list of subcommands available, and diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index bdfc666928..b14e794077 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -24,7 +24,7 @@ replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe" interface briefly mentioned in the following paragraph. Apart from supporting file annotation, git also supports searching the -development history for when a code snippet occured in a change. This makes it +development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for a text string in the diff. A small example: @@ -89,7 +89,7 @@ THE PORCELAIN FORMAT -------------------- In this format, each line is output after a header; the -header at the minumum has the first line which has: +header at the minimum has the first line which has: - 40-byte SHA-1 of the commit the line is attributed to; - the line number of the line in the original file; @@ -112,8 +112,8 @@ header, prefixed by a TAB. This is to allow adding more header elements later. -SPECIFIYING RANGES ------------------- +SPECIFYING RANGES +----------------- Unlike `git-blame` and `git-annotate` in older git, the extent of annotation can be limited to both line ranges and revision diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index e872fc89fc..d5f8118261 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -74,7 +74,7 @@ OPTIONS List both remote-tracking branches and local branches. -v:: - Show sha1 and commit subjectline for each head. + Show sha1 and commit subject line for each head. --abbrev=:: Alter minimum display length for sha1 in output listing, diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 9c84353068..bd1c22b316 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -111,7 +111,7 @@ but can be used to amend a merge commit. are concluding a conflicted merge. -q|--quiet:: - Supress commit summary message. + Suppress commit summary message. \--:: Do not interpret any more arguments as options. diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 5c402de267..44713949a5 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -97,7 +97,7 @@ If you need to pass multiple options, separate them with a comma. Substitute the character "/" in branch names with -A :: - CVS by default uses the unix username when writing its + CVS by default uses the Unix username when writing its commit logs. Using this option and an author-conv-file in this format diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 2bf6aef735..06e7ab1ec1 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -15,7 +15,7 @@ DESCRIPTION Iterate over all refs that match `` and show them according to the given ``, after sorting them according to the given set of ``. If `` is given, stop after -showing that many refs. The interporated values in `` +showing that many refs. The interpolated values in `` can optionally be quoted as string literals in the specified host language allowing their direct evaluation in that language. diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 73d78c15e8..2bcc9491a3 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -35,7 +35,7 @@ can be set to indicate how long historical reflog entries which are not part of the current branch should remain available in this repository. These types of entries are generally created as a result of using `git commit \--amend` or `git rebase` and are the -commits prior to the amend or rebase occuring. Since these changes +commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner. This option defaults to '30 days'. diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index bfbece9864..0140c8e358 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -91,7 +91,7 @@ OPTIONS combined by 'or'. --and | --or | --not | ( | ):: - Specify how multiple patterns are combined using boolean + Specify how multiple patterns are combined using Boolean expressions. `--or` is the default operator. `--and` has higher precedence than `--or`. `-e` has to be used for all patterns. diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index c8a4c5a4d9..c254005ca3 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -29,7 +29,7 @@ OPTIONS -u , --upload-pack=:: Specify the full path of gitlink:git-upload-pack[1] on the remote host. This allows listing references from repositories accessed via - SSH and where the SSH deamon does not use the PATH configured by the + SSH and where the SSH daemon does not use the PATH configured by the user. Also see the '--exec' option for gitlink:git-peek-remote[1]. :: diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index 08a055713c..c65c59e861 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -38,7 +38,7 @@ its working state. This resets the metadata used by rerere if a merge resolution is to be is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1] -[--skip|--abort] will automatcally invoke this command. +[--skip|--abort] will automatically invoke this command. 'diff':: diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 95fa9010c1..b0df92e819 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -29,7 +29,7 @@ OPTIONS of author alphabetic order. -s:: - Supress commit description and provide a commit count summary only. + Suppress commit description and provide a commit count summary only. FILES ----- diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 9ed721118b..321083d461 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -113,7 +113,7 @@ manually joining branches on commit. 'commit-diff':: Commits the diff of two tree-ish arguments from the - command-line. This command is intended for interopability with + command-line. This command is intended for interoperability with git-svnimport and does not rely on being inside an git-svn init-ed repository. This command takes three arguments, (a) the original tree to diff against, (b) the new tree result, (c) the From 5e1a2e8c61b31410fd0c2e5a67c45bf6b373f4c3 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 10:43:50 -0800 Subject: [PATCH 20/27] Documentation: detached HEAD Add discussion section to git-checkout documentation and mention detached HEAD in repository-layout document. Signed-off-by: Junio C Hamano --- Documentation/git-checkout.txt | 54 +++++++++++++++++++++++++++-- Documentation/repository-layout.txt | 6 ++++ 2 files changed, 58 insertions(+), 2 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index fbdbadc74f..c44a4a8004 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -9,7 +9,7 @@ SYNOPSIS -------- [verse] 'git-checkout' [-f] [-b [-l]] [-m] [] -'git-checkout' [-m] [] ... +'git-checkout' [] ... DESCRIPTION ----------- @@ -63,7 +63,57 @@ and mark the resolved paths with `git update-index`. :: Branch to checkout; may be any object ID that resolves to a - commit. Defaults to HEAD. + commit. Defaults to HEAD. ++ +When this parameter names a non-branch (but still a valid commit object), +your HEAD becomes 'detached'. + + +Detached HEAD +------------- + +It is sometimes useful to be able to 'checkout' a commit that is +not at the tip of one of your branches. The most obvious +example is to check out the commit at a tagged official release +point, like this: + +------------ +$ git checkout v2.6.18 +------------ + +Earlier versions of git did not allow this and asked you to +create a temporary branch using `-b` option, but starting from +version 1.5.0, the above command 'detaches' your HEAD from the +current branch and directly point at the commit named by the tag +(`v2.6.18` in the above example). + +You can use usual git commands while in this state. You can use +`git-reset --hard $othercommit` to further move around, for +example. You can make changes and create a new commit on top of +a detached HEAD. You can even create a merge by using `git +merge $othercommit`. + +The state you are in while your HEAD is detached is not recorded +by any branch (which is natural --- you are not on any branch). +What this means is that you can discard your temporary commits +and merges by switching back to an existing branch (e.g. `git +checkout master`), and a later `git prune` or `git gc` would +garbage-collect them. + +The command would refuse to switch back to make sure that you do +not discard your temporary state by mistake when your detached +HEAD is not pointed at by any existing ref. If you did want to +save your state (e.g. "I was interested in the fifth commit from +the top of 'master' branch", or "I made two commits to fix minor +bugs while on a detached HEAD" -- and if you do not want to lose +these facts), you can create a new branch and switch to it with +`git checkout -b newbranch` so that you can keep building on +that state, or tag it first so that you can come back to it +later and switch to the branch you wanted to switch to with `git +tag that_state; git checkout master`. On the other hand, if you +did want to discard the temporary state, you can give `-f` +option (e.g. `git checkout -f master`) to override this +behaviour. EXAMPLES diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt index 0fdd36614d..7c8c141419 100644 --- a/Documentation/repository-layout.txt +++ b/Documentation/repository-layout.txt @@ -91,6 +91,12 @@ HEAD:: 'name' does not (yet) exist. In some legacy setups, it is a symbolic link instead of a symref that points at the current branch. ++ +HEAD can also record a specific commit directly, instead of +being a symref to point at the current branch. Such a state +is often called 'detached HEAD', and almost all commands work +identically as normal. See gitlink:git-checkout[1] for +details. branches:: A slightly deprecated way to store shorthands to be used From df59afe3eb121e89195e246105dd53de0ec396ab Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 10:52:36 -0800 Subject: [PATCH 21/27] Make a short-and-sweet "git-add -i" synonym for "git-add --interactive" Signed-off-by: Junio C Hamano --- Documentation/git-add.txt | 4 ++-- builtin-add.c | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index a5051aad6b..b73a99d61f 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next SYNOPSIS -------- -'git-add' [-n] [-v] [-f] [--interactive] [--] ... +'git-add' [-n] [-v] [-f] [--interactive | -i] [--] ... DESCRIPTION ----------- @@ -52,7 +52,7 @@ OPTIONS -f:: Allow adding otherwise ignored files. -\--interactive:: +\i, \--interactive:: Add modified contents in the working tree interactively to the index. diff --git a/builtin-add.c b/builtin-add.c index e7a1b4d9ab..87e16aa220 100644 --- a/builtin-add.c +++ b/builtin-add.c @@ -10,7 +10,7 @@ #include "cache-tree.h" static const char builtin_add_usage[] = -"git-add [-n] [-v] [-f] [--interactive] [--] ..."; +"git-add [-n] [-v] [-f] [--interactive | -i] [--] ..."; static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix) { @@ -102,7 +102,8 @@ int cmd_add(int argc, const char **argv, const char *prefix) int add_interactive = 0; for (i = 1; i < argc; i++) { - if (!strcmp("--interactive", argv[i])) + if (!strcmp("--interactive", argv[i]) || + !strcmp("-i", argv[i])) add_interactive++; } if (add_interactive) { From 428ddc5de64684ad37d20c563544f17993a4d58d Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 10:53:31 -0800 Subject: [PATCH 22/27] Documentation: describe shallow repository Signed-off-by: Junio C Hamano --- Documentation/glossary.txt | 12 ++++++++++++ Documentation/repository-layout.txt | 8 ++++++++ 2 files changed, 20 insertions(+) diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt index bc917bbac3..d20eb6270c 100644 --- a/Documentation/glossary.txt +++ b/Documentation/glossary.txt @@ -286,6 +286,18 @@ SCM:: SHA1:: Synonym for object name. +shallow repository:: + A shallow repository has an incomplete history some of + whose commits have parents cauterized away (in other + words, git is told to pretend that these commits do not + have the parents, even though they are recorded in the + commit object). This is sometimes useful when you are + interested only in the recent history of a project even + though the real history recorded in the upstream is + much larger. A shallow repository is created by giving + `--depth` option to gitlink:git-clone[1], and its + history can be later deepened with gitlink:git-fetch[1]. + symref:: Symbolic reference: instead of containing the SHA1 id itself, it is of the format 'ref: refs/some/thing' and when referenced, it diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt index 7c8c141419..f9370d25bb 100644 --- a/Documentation/repository-layout.txt +++ b/Documentation/repository-layout.txt @@ -18,6 +18,8 @@ could have only commit objects without associated blobs and trees this way, for example. A repository with this kind of incomplete object store is not suitable to be published to the outside world but sometimes useful for private repository. +. You also could have an incomplete but locally usable repository +by cloning shallowly. See gitlink:git-clone[1]. . You can be using `objects/info/alternates` mechanism, or `$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow' objects from other object stores. A repository with this kind @@ -162,3 +164,9 @@ logs/refs/heads/`name`:: logs/refs/tags/`name`:: Records all changes made to the tag named `name`. + +shallow:: + This is similar to `info/grafts` but is internally used + and maintained by shallow clone mechanism. See `--depth` + option to gitlink:git-clone[1] and gitlink:git-fetch[1]. + From 24a0fd02c9d0d0e415841a76e509d66785502c54 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 10:54:18 -0800 Subject: [PATCH 23/27] Documentation/glossary.txt: unpacked objects are loose. Signed-off-by: Junio C Hamano --- Documentation/repository-layout.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt index f9370d25bb..a951b354c4 100644 --- a/Documentation/repository-layout.txt +++ b/Documentation/repository-layout.txt @@ -34,7 +34,7 @@ objects/[0-9a-f][0-9a-f]:: two letters from its object name to keep the number of directory entries `objects` directory itself needs to hold. Objects found here are often called 'unpacked' - objects. + (or 'loose') objects. objects/pack:: Packs (files that store many object in compressed form, From 2aa73a8fa23d9f5b9048816f9884f65a2d24215a Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 10:54:58 -0800 Subject: [PATCH 24/27] Documentation/glossary.txt: describe remotes/ tracking and packed-refs Signed-off-by: Junio C Hamano --- Documentation/repository-layout.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt index a951b354c4..863cb6710a 100644 --- a/Documentation/repository-layout.txt +++ b/Documentation/repository-layout.txt @@ -82,6 +82,15 @@ refs/tags/`name`:: records any object name (not necessarily a commit object, or a tag object that points at a commit object). +refs/remotes/`name`:: + records tip-of-the-tree commit objects of branches copied + from a remote repository. + +packed-refs:: + records the same information as refs/heads/, refs/tags/, + and friends record in a more efficient way. See + gitlink:git-pack-refs[1]. + HEAD:: A symref (see glossary) to the `refs/heads/` namespace describing the currently active branch. It does not mean From 03eeaeaea57485e288dfecc37b120b074d6e92de Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 11:12:03 -0800 Subject: [PATCH 25/27] Introduce 'git-format-patch --suffix=.patch' The default can also be changed with "format.suffix" configuration. Leaving it empty would not add any suffix. Signed-off-by: Junio C Hamano --- Documentation/git-format-patch.txt | 17 ++++++++++++++++- builtin-log.c | 19 ++++++++++++++++--- 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 67425dc035..23acb47528 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git-format-patch' [-n | -k] [-o | --stdout] [--attach] [--thread] [-s | --signoff] [--diff-options] [--start-number ] - [--in-reply-to=Message-Id] + [--in-reply-to=Message-Id] [--suffix=.] [..] DESCRIPTION @@ -78,6 +78,16 @@ OPTIONS reply to the given Message-Id, which avoids breaking threads to provide a new patch series. +--suffix=.:: + Instead of using `.txt` as the suffix for generated + filenames, use specifed suffix. A common alternative is + `--suffix=.patch`. ++ +Note that you would need to include the leading dot `.` if you +want a filename like `0001-description-of-my-change.patch`, and +the first letter does not have to be a dot. Leaving it empty would +not add any suffix. + CONFIGURATION ------------- You can specify extra mail header lines to be added to each @@ -86,6 +96,11 @@ message in the repository configuration as follows: [format] headers = "Organization: git-foo\n" +You can specify default suffix used: + +[format] + suffix = .patch + EXAMPLES -------- diff --git a/builtin-log.c b/builtin-log.c index a59b4acef1..7397a5af07 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -197,6 +197,7 @@ static int istitlechar(char c) static char *extra_headers = NULL; static int extra_headers_size = 0; +static const char *fmt_patch_suffix = ".txt"; static int git_format_config(const char *var, const char *value) { @@ -208,6 +209,12 @@ static int git_format_config(const char *var, const char *value) strcat(extra_headers, value); return 0; } + if (!strcmp(var, "format.suffix")) { + if (!value) + die("format.suffix without value"); + fmt_patch_suffix = xstrdup(value); + return 0; + } if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) { return 0; } @@ -223,9 +230,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject) char filename[1024]; char *sol; int len = 0; + int suffix_len = strlen(fmt_patch_suffix) + 10; /* ., NUL and slop */ if (output_directory) { - strlcpy(filename, output_directory, 1010); + strlcpy(filename, output_directory, 1000); len = strlen(filename); if (filename[len - 1] != '/') filename[len++] = '/'; @@ -249,7 +257,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject) } } - for (j = 0; len < 1024 - 6 && sol[j] && sol[j] != '\n'; j++) { + for (j = 0; + len < sizeof(filename) - suffix_len && + sol[j] && sol[j] != '\n'; + j++) { if (istitlechar(sol[j])) { if (space) { filename[len++] = '-'; @@ -265,7 +276,7 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject) while (filename[len - 1] == '.' || filename[len - 1] == '-') len--; } - strcpy(filename + len, ".txt"); + strcpy(filename + len, fmt_patch_suffix); fprintf(realstdout, "%s\n", filename); freopen(filename, "w", stdout); } @@ -436,6 +447,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) die("Need a Message-Id for --in-reply-to"); in_reply_to = argv[i]; } + else if (!strncmp(argv[i], "--suffix=", 9)) + fmt_patch_suffix = argv[i] + 9; else argv[j++] = argv[i]; } From d7fb91c69dc347c53b0d9830b13fdadf217a78f1 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 17 Jan 2007 11:13:02 -0800 Subject: [PATCH 26/27] git-format-patch: do not crash with format.headers without value. An incorrect config file can say: [format] headers and crash the parsing. Signed-off-by: Junio C Hamano --- builtin-log.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin-log.c b/builtin-log.c index 7397a5af07..1cd9d3f768 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -202,7 +202,11 @@ static const char *fmt_patch_suffix = ".txt"; static int git_format_config(const char *var, const char *value) { if (!strcmp(var, "format.headers")) { - int len = strlen(value); + int len; + + if (!value) + die("format.headers without value"); + len = strlen(value); extra_headers_size += len + 1; extra_headers = xrealloc(extra_headers, extra_headers_size); extra_headers[extra_headers_size - len - 1] = 0; From 556b6600b25713054430b1dcaa731120eefbbd5b Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Wed, 17 Jan 2007 13:04:39 -0500 Subject: [PATCH 27/27] sanitize content of README file Current README content is way too esoteric for someone looking at GIT for the first time. Instead it should provide a quick summary of what GIT is with a few pointers to other resources. The bulk of the previous README content is moved to Documentation/core-intro.txt. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano --- Documentation/Makefile | 9 +- Documentation/core-intro.txt | 590 ++++++++++++++++++++++++++++++++++ Documentation/git.txt | 2 +- README | 599 ++--------------------------------- 4 files changed, 618 insertions(+), 582 deletions(-) create mode 100644 Documentation/core-intro.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index 93c7024b48..9f2d242e59 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -71,14 +71,11 @@ doc.dep : $(wildcard *.txt) build-docdep.perl -include doc.dep -git.7: README - -README: ../README - cp $< $@ +git.7 git.html: git.txt core-intro.txt clean: - rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README + rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep %.html : %.txt asciidoc -b xhtml11 -d manpage -f asciidoc.conf $< @@ -89,8 +86,6 @@ clean: %.xml : %.txt asciidoc -b docbook -d manpage -f asciidoc.conf $< -git.html: git.txt README - glossary.html : glossary.txt sort_glossary.pl cat $< | \ perl sort_glossary.pl | \ diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt new file mode 100644 index 0000000000..0458dc3d02 --- /dev/null +++ b/Documentation/core-intro.txt @@ -0,0 +1,590 @@ +//////////////////////////////////////////////////////////////// + + GIT - the stupid content tracker + +//////////////////////////////////////////////////////////////// + +"git" can mean anything, depending on your mood. + + - random three-letter combination that is pronounceable, and not + actually used by any common UNIX command. The fact that it is a + mispronunciation of "get" may or may not be relevant. + - stupid. contemptible and despicable. simple. Take your pick from the + dictionary of slang. + - "global information tracker": you're in a good mood, and it actually + works for you. Angels sing, and a light suddenly fills the room. + - "goddamn idiotic truckload of sh*t": when it breaks + +This is a (not so) stupid but extremely fast directory content manager. +It doesn't do a whole lot at its core, but what it 'does' do is track +directory contents efficiently. + +There are two object abstractions: the "object database", and the +"current directory cache" aka "index". + +The Object Database +~~~~~~~~~~~~~~~~~~~ +The object database is literally just a content-addressable collection +of objects. All objects are named by their content, which is +approximated by the SHA1 hash of the object itself. Objects may refer +to other objects (by referencing their SHA1 hash), and so you can +build up a hierarchy of objects. + +All objects have a statically determined "type" aka "tag", which is +determined at object creation time, and which identifies the format of +the object (i.e. how it is used, and how it can refer to other +objects). There are currently four different object types: "blob", +"tree", "commit" and "tag". + +A "blob" object cannot refer to any other object, and is, like the type +implies, a pure storage object containing some user data. It is used to +actually store the file data, i.e. a blob object is associated with some +particular version of some file. + +A "tree" object is an object that ties one or more "blob" objects into a +directory structure. In addition, a tree object can refer to other tree +objects, thus creating a directory hierarchy. + +A "commit" object ties such directory hierarchies together into +a DAG of revisions - each "commit" is associated with exactly one tree +(the directory hierarchy at the time of the commit). In addition, a +"commit" refers to one or more "parent" commit objects that describe the +history of how we arrived at that directory hierarchy. + +As a special case, a commit object with no parents is called the "root" +object, and is the point of an initial project commit. Each project +must have at least one root, and while you can tie several different +root objects together into one project by creating a commit object which +has two or more separate roots as its ultimate parents, that's probably +just going to confuse people. So aim for the notion of "one root object +per project", even if git itself does not enforce that. + +A "tag" object symbolically identifies and can be used to sign other +objects. It contains the identifier and type of another object, a +symbolic name (of course!) and, optionally, a signature. + +Regardless of object type, all objects share the following +characteristics: they are all deflated with zlib, and have a header +that not only specifies their type, but also provides size information +about the data in the object. It's worth noting that the SHA1 hash +that is used to name the object is the hash of the original data +plus this header, so `sha1sum` 'file' does not match the object name +for 'file'. +(Historical note: in the dawn of the age of git the hash +was the sha1 of the 'compressed' object.) + +As a result, the general consistency of an object can always be tested +independently of the contents or the type of the object: all objects can +be validated by verifying that (a) their hashes match the content of the +file and (b) the object successfully inflates to a stream of bytes that +forms a sequence of + + + + . + +The structured objects can further have their structure and +connectivity to other objects verified. This is generally done with +the `git-fsck-objects` program, which generates a full dependency graph +of all objects, and verifies their internal consistency (in addition +to just verifying their superficial consistency through the hash). + +The object types in some more detail: + +Blob Object +~~~~~~~~~~~ +A "blob" object is nothing but a binary blob of data, and doesn't +refer to anything else. There is no signature or any other +verification of the data, so while the object is consistent (it 'is' +indexed by its sha1 hash, so the data itself is certainly correct), it +has absolutely no other attributes. No name associations, no +permissions. It is purely a blob of data (i.e. normally "file +contents"). + +In particular, since the blob is entirely defined by its data, if two +files in a directory tree (or in multiple different versions of the +repository) have the same contents, they will share the same blob +object. The object is totally independent of its location in the +directory tree, and renaming a file does not change the object that +file is associated with in any way. + +A blob is typically created when gitlink:git-update-index[1] +is run, and its data can be accessed by gitlink:git-cat-file[1]. + +Tree Object +~~~~~~~~~~~ +The next hierarchical object type is the "tree" object. A tree object +is a list of mode/name/blob data, sorted by name. Alternatively, the +mode data may specify a directory mode, in which case instead of +naming a blob, that name is associated with another TREE object. + +Like the "blob" object, a tree object is uniquely determined by the +set contents, and so two separate but identical trees will always +share the exact same object. This is true at all levels, i.e. it's +true for a "leaf" tree (which does not refer to any other trees, only +blobs) as well as for a whole subdirectory. + +For that reason a "tree" object is just a pure data abstraction: it +has no history, no signatures, no verification of validity, except +that since the contents are again protected by the hash itself, we can +trust that the tree is immutable and its contents never change. + +So you can trust the contents of a tree to be valid, the same way you +can trust the contents of a blob, but you don't know where those +contents 'came' from. + +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, +and your diff will look right. In other words, you can effectively +(and efficiently) tell the difference between any two random trees by +O(n) where "n" is the size of the difference, rather than the size of +the tree. + +Side note 2 on trees: since the name of a "blob" depends entirely and +exclusively on its contents (i.e. there are no names or permissions +involved), you can see trivial renames or permission changes by +noticing that the blob stayed the same. However, renames with data +changes need a smarter "diff" implementation. + +A tree is created with gitlink:git-write-tree[1] and +its data can be accessed by gitlink:git-ls-tree[1]. +Two trees can be compared with gitlink:git-diff-tree[1]. + +Commit Object +~~~~~~~~~~~~~ +The "commit" object is an object that introduces the notion of +history into the picture. In contrast to the other objects, it +doesn't just describe the physical state of a tree, it describes how +we got there, and why. + +A "commit" is defined by the tree-object that it results in, the +parent commits (zero, one or more) that led up to that point, and a +comment on what happened. Again, a commit is not trusted per se: +the contents are well-defined and "safe" due to the cryptographically +strong signatures at all levels, but there is no reason to believe +that the tree is "good" or that the merge information makes sense. +The parents do not have to actually have any relationship with the +result, for example. + +Note on commits: unlike real SCM's, commits do not contain +rename information or file mode change information. All of that is +implicit in the trees involved (the result tree, and the result trees +of the parents), and describing that makes no sense in this idiotic +file manager. + +A commit is created with gitlink:git-commit-tree[1] and +its data can be accessed by gitlink:git-cat-file[1]. + +Trust +~~~~~ +An aside on the notion of "trust". Trust is really outside the scope +of "git", but it's worth noting a few things. First off, since +everything is hashed with SHA1, you 'can' trust that an object is +intact and has not been messed with by external sources. So the name +of an object uniquely identifies a known state - just not a state that +you may want to trust. + +Furthermore, since the SHA1 signature of a commit refers to the +SHA1 signatures of the tree it is associated with and the signatures +of the parent, a single named commit specifies uniquely a whole set +of history, with full contents. You can't later fake any step of the +way once you have the name of a commit. + +So to introduce some real trust in the system, the only thing you need +to do is to digitally sign just 'one' special note, which includes the +name of a top-level commit. Your digital signature shows others +that you trust that commit, and the immutability of the history of +commits tells others that they can trust the whole history. + +In other words, you can easily validate a whole archive by just +sending out a single email that tells the people the name (SHA1 hash) +of the top commit, and digitally sign that email using something +like GPG/PGP. + +To assist in this, git also provides the tag object... + +Tag Object +~~~~~~~~~~ +Git provides the "tag" object to simplify creating, managing and +exchanging symbolic and signed tokens. The "tag" object at its +simplest simply symbolically identifies another object by containing +the sha1, type and symbolic name. + +However it can optionally contain additional signature information +(which git doesn't care about as long as there's less than 8k of +it). This can then be verified externally to git. + +Note that despite the tag features, "git" itself only handles content +integrity; the trust framework (and signature provision and +verification) has to come from outside. + +A tag is created with gitlink:git-mktag[1], +its data can be accessed by gitlink:git-cat-file[1], +and the signature can be verified by +gitlink:git-verify-tag[1]. + + +The "index" aka "Current Directory Cache" +----------------------------------------- +The index is a simple binary file, which contains an efficient +representation of a virtual directory content at some random time. It +does so by a simple array that associates a set of names, dates, +permissions and content (aka "blob") objects together. The cache is +always kept ordered by name, and names are unique (with a few very +specific rules) at any point in time, but the cache has no long-term +meaning, and can be partially updated at any time. + +In particular, the index certainly does not need to be consistent with +the current directory contents (in fact, most operations will depend on +different ways to make the index 'not' be consistent with the directory +hierarchy), but it has three very important attributes: + +'(a) it can re-generate the full state it caches (not just the +directory structure: it contains pointers to the "blob" objects so +that it can regenerate the data too)' + +As a special case, there is a clear and unambiguous one-way mapping +from a current directory cache to a "tree object", which can be +efficiently created from just the current directory cache without +actually looking at any other data. So a directory cache at any one +time uniquely specifies one and only one "tree" object (but has +additional data to make it easy to match up that tree object with what +has happened in the directory) + +'(b) it has efficient methods for finding inconsistencies between that +cached state ("tree object waiting to be instantiated") and the +current state.' + +'(c) it can additionally efficiently represent information about merge +conflicts between different tree objects, allowing each pathname to be +associated with sufficient information about the trees involved that +you can create a three-way merge between them.' + +Those are the three ONLY things that the directory cache does. It's a +cache, and the normal operation is to re-generate it completely from a +known tree object, or update/compare it with a live tree that is being +developed. If you blow the directory cache away entirely, you generally +haven't lost any information as long as you have the name of the tree +that it described. + +At the same time, the index is at the same time also the +staging area for creating new trees, and creating a new tree always +involves a controlled modification of the index file. In particular, +the index file can have the representation of an intermediate tree that +has not yet been instantiated. So the index can be thought of as a +write-back cache, which can contain dirty information that has not yet +been written back to the backing store. + + + +The Workflow +------------ +Generally, all "git" operations work on the index file. Some operations +work *purely* on the index file (showing the current state of the +index), but most operations move data to and from the index file. Either +from the database or from the working directory. Thus there are four +main combinations: + +1) working directory -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update the index with information from the working directory with +the gitlink:git-update-index[1] command. You +generally update the index information by just specifying the filename +you want to update, like so: + + git-update-index filename + +but to avoid common mistakes with filename globbing etc, the command +will not normally add totally new entries or remove old entries, +i.e. it will normally just update existing cache entries. + +To tell git that yes, you really do realize that certain files no +longer exist, or that new files should be added, you +should use the `--remove` and `--add` flags respectively. + +NOTE! A `--remove` flag does 'not' mean that subsequent filenames will +necessarily be removed: if the files still exist in your directory +structure, the index will be updated with their new status, not +removed. The only thing `--remove` means is that update-cache will be +considering a removed file to be a valid thing, and if the file really +does not exist any more, it will update the index accordingly. + +As a special case, you can also do `git-update-index --refresh`, which +will refresh the "stat" information of each index to match the current +stat information. It will 'not' update the object status itself, and +it will only update the fields that are used to quickly test whether +an object still matches its old backing store object. + +2) index -> object database +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You write your current index file to a "tree" object with the program + + git-write-tree + +that doesn't come with any options - it will just write out the +current index into the set of tree objects that describe that state, +and it will return the name of the resulting top-level tree. You can +use that tree to re-generate the index at any time by going in the +other direction: + +3) object database -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You read a "tree" file from the object database, and use that to +populate (and overwrite - don't do this if your index contains any +unsaved state that you might want to restore later!) your current +index. Normal operation is just + + git-read-tree + +and your index file will now be equivalent to the tree that you saved +earlier. However, that is only your 'index' file: your working +directory contents have not been modified. + +4) index -> working directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update your working directory from the index by "checking out" +files. This is not a very common operation, since normally you'd just +keep your files updated, and rather than write to your working +directory, you'd tell the index files about the changes in your +working directory (i.e. `git-update-index`). + +However, if you decide to jump to a new version, or check out somebody +else's version, or just restore a previous tree, you'd populate your +index file with read-tree, and then you need to check out the result +with + + git-checkout-index filename + +or, if you want to check out all of the index, use `-a`. + +NOTE! git-checkout-index normally refuses to overwrite old files, so +if you have an old version of the tree already checked out, you will +need to use the "-f" flag ('before' the "-a" flag or the filename) to +'force' the checkout. + + +Finally, there are a few odds and ends which are not purely moving +from one representation to the other: + +5) Tying it all together +~~~~~~~~~~~~~~~~~~~~~~~~ +To commit a tree you have instantiated with "git-write-tree", you'd +create a "commit" object that refers to that tree and the history +behind it - most notably the "parent" commits that preceded it in +history. + +Normally a "commit" has one parent: the previous state of the tree +before a certain change was made. However, sometimes it can have two +or more parent commits, in which case we call it a "merge", due to the +fact that such a commit brings together ("merges") two or more +previous states represented by other commits. + +In other words, while a "tree" represents a particular directory state +of a working directory, a "commit" represents that state in "time", +and explains how we got there. + +You create a commit object by giving it the tree that describes the +state at the time of the commit, and a list of parents: + + git-commit-tree -p [-p ..] + +and then giving the reason for the commit on stdin (either through +redirection from a pipe or file, or by just typing it at the tty). + +git-commit-tree will return the name of the object that represents +that commit, and you should save it away for later use. Normally, +you'd commit a new `HEAD` state, and while git doesn't care where you +save the note about that state, in practice we tend to just write the +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + + +6) Examining the data +~~~~~~~~~~~~~~~~~~~~~ + +You can examine the data represented in the object database and the +index with various helper tools. For every object, you can use +gitlink:git-cat-file[1] to examine details about the +object: + + git-cat-file -t + +shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use + + git-cat-file blob|tree|commit|tag + +to show its contents. NOTE! Trees have binary content, and as a result +there is a special helper for showing that content, called +`git-ls-tree`, which turns the binary content into a more easily +readable form. + +It's especially instructive to look at "commit" objects, since those +tend to be small and fairly self-explanatory. In particular, if you +follow the convention of having the top commit name in `.git/HEAD`, +you can do + + git-cat-file commit HEAD + +to see what the top commit was. + +7) Merging multiple trees +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Git helps you do a three-way merge, which you can expand to n-way by +repeating the merge procedure arbitrary times until you finally +"commit" the state. The normal situation is that you'd only do one +three-way merge (two parents), and commit it, but if you like to, you +can do multiple parents in one go. + +To do a three-way merge, you need the two sets of "commit" objects +that you want to merge, use those to find the closest common parent (a +third "commit" object), and then use those commit objects to find the +state of the directory ("tree" object) at these points. + +To get the "base" for the merge, you first look up the common parent +of two commits with + + git-merge-base + +which will return you the commit they are both based on. You should +now look up the "tree" objects of those commits, which you can easily +do with (for example) + + git-cat-file commit | head -1 + +since the tree object information is always the first line in a commit +object. + +Once you know the three trees you are going to merge (the one +"original" tree, aka the common case, and the two "result" trees, aka +the branches you want to merge), you do a "merge" read into the +index. This will complain if it has to throw away your old index contents, so you should +make sure that you've committed those - in fact you would normally +always do a merge against your last commit (which should thus match +what you have in your current index anyway). + +To do the merge, do + + git-read-tree -m -u + +which will do all trivial merge operations for you directly in the +index file, and you can just write the result out with +`git-write-tree`. + +Historical note. We did not have `-u` facility when this +section was first written, so we used to warn that +the merge is done in the index file, not in your +working tree, and your working tree will not match your +index after this step. +This is no longer true. The above command, thanks to `-u` +option, updates your working tree with the merge results for +paths that have been trivially merged. + + +8) Merging multiple trees, continued +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sadly, many merges aren't trivial. If there are files that have +been added.moved or removed, or if both branches have modified the +same file, you will be left with an index tree that contains "merge +entries" in it. Such an index tree can 'NOT' be written out to a tree +object, and you will have to resolve any such merge clashes using +other tools before you can write out the result. + +You can examine such index state with `git-ls-files --unmerged` +command. An example: + +------------------------------------------------ +$ git-read-tree -m $orig HEAD $target +$ git-ls-files --unmerged +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c +------------------------------------------------ + +Each line of the `git-ls-files --unmerged` output begins with +the blob mode bits, blob SHA1, 'stage number', and the +filename. The 'stage number' is git's way to say which tree it +came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` +tree, and stage3 `$target` tree. + +Earlier we said that trivial merges are done inside +`git-read-tree -m`. For example, if the file did not change +from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` and `$orig` to `$target` the same way, +obviously the final outcome is what is in `HEAD`. What the +above example shows is that file `hello.c` was changed from +`$orig` to `HEAD` and `$orig` to `$target` in a different way. +You could resolve this by running your favorite 3-way merge +program, e.g. `diff3` or `merge`, on the blob objects from +these three stages yourself, like this: + +------------------------------------------------ +$ git-cat-file blob 263414f... >hello.c~1 +$ git-cat-file blob 06fa6a2... >hello.c~2 +$ git-cat-file blob cc44c73... >hello.c~3 +$ merge hello.c~2 hello.c~1 hello.c~3 +------------------------------------------------ + +This would leave the merge result in `hello.c~2` file, along +with conflict markers if there are conflicts. After verifying +the merge result makes sense, you can tell git what the final +merge result for this file is by: + + mv -f hello.c~2 hello.c + git-update-index hello.c + +When a path is in unmerged state, running `git-update-index` for +that path tells git to mark the path resolved. + +The above is the description of a git merge at the lowest level, +to help you understand what conceptually happens under the hood. +In practice, nobody, not even git itself, uses three `git-cat-file` +for this. There is `git-merge-index` program that extracts the +stages to temporary files and calls a "merge" script on it: + + git-merge-index git-merge-one-file hello.c + +and that is what higher level `git resolve` is implemented with. diff --git a/Documentation/git.txt b/Documentation/git.txt index 6a82803f31..a0bcef71d7 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -699,7 +699,7 @@ other Discussion[[Discussion]] ------------------------ -include::README[] +include::core-intro.txt[] Authors ------- diff --git a/README b/README index cee7e435d7..441167cb8a 100644 --- a/README +++ b/README @@ -3,6 +3,7 @@ GIT - the stupid content tracker //////////////////////////////////////////////////////////////// + "git" can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not @@ -11,579 +12,29 @@ - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - "global information tracker": you're in a good mood, and it actually - works for you. Angels sing, and a light suddenly fills the room. + works for you. Angels sing, and a light suddenly fills the room. - "goddamn idiotic truckload of sh*t": when it breaks -This is a stupid (but extremely fast) directory content manager. It -doesn't do a whole lot, but what it 'does' do is track directory -contents efficiently. - -There are two object abstractions: the "object database", and the -"current directory cache" aka "index". - -The Object Database -~~~~~~~~~~~~~~~~~~~ -The object database is literally just a content-addressable collection -of objects. All objects are named by their content, which is -approximated by the SHA1 hash of the object itself. Objects may refer -to other objects (by referencing their SHA1 hash), and so you can -build up a hierarchy of objects. - -All objects have a statically determined "type" aka "tag", which is -determined at object creation time, and which identifies the format of -the object (i.e. how it is used, and how it can refer to other -objects). There are currently four different object types: "blob", -"tree", "commit" and "tag". - -A "blob" object cannot refer to any other object, and is, like the type -implies, a pure storage object containing some user data. It is used to -actually store the file data, i.e. a blob object is associated with some -particular version of some file. - -A "tree" object is an object that ties one or more "blob" objects into a -directory structure. In addition, a tree object can refer to other tree -objects, thus creating a directory hierarchy. - -A "commit" object ties such directory hierarchies together into -a DAG of revisions - each "commit" is associated with exactly one tree -(the directory hierarchy at the time of the commit). In addition, a -"commit" refers to one or more "parent" commit objects that describe the -history of how we arrived at that directory hierarchy. - -As a special case, a commit object with no parents is called the "root" -object, and is the point of an initial project commit. Each project -must have at least one root, and while you can tie several different -root objects together into one project by creating a commit object which -has two or more separate roots as its ultimate parents, that's probably -just going to confuse people. So aim for the notion of "one root object -per project", even if git itself does not enforce that. - -A "tag" object symbolically identifies and can be used to sign other -objects. It contains the identifier and type of another object, a -symbolic name (of course!) and, optionally, a signature. - -Regardless of object type, all objects share the following -characteristics: they are all deflated with zlib, and have a header -that not only specifies their type, but also provides size information -about the data in the object. It's worth noting that the SHA1 hash -that is used to name the object is the hash of the original data -plus this header, so `sha1sum` 'file' does not match the object name -for 'file'. -(Historical note: in the dawn of the age of git the hash -was the sha1 of the 'compressed' object.) - -As a result, the general consistency of an object can always be tested -independently of the contents or the type of the object: all objects can -be validated by verifying that (a) their hashes match the content of the -file and (b) the object successfully inflates to a stream of bytes that -forms a sequence of + + + + . - -The structured objects can further have their structure and -connectivity to other objects verified. This is generally done with -the `git-fsck-objects` program, which generates a full dependency graph -of all objects, and verifies their internal consistency (in addition -to just verifying their superficial consistency through the hash). - -The object types in some more detail: - -Blob Object -~~~~~~~~~~~ -A "blob" object is nothing but a binary blob of data, and doesn't -refer to anything else. There is no signature or any other -verification of the data, so while the object is consistent (it 'is' -indexed by its sha1 hash, so the data itself is certainly correct), it -has absolutely no other attributes. No name associations, no -permissions. It is purely a blob of data (i.e. normally "file -contents"). - -In particular, since the blob is entirely defined by its data, if two -files in a directory tree (or in multiple different versions of the -repository) have the same contents, they will share the same blob -object. The object is totally independent of its location in the -directory tree, and renaming a file does not change the object that -file is associated with in any way. - -A blob is typically created when gitlink:git-update-index[1] -is run, and its data can be accessed by gitlink:git-cat-file[1]. - -Tree Object -~~~~~~~~~~~ -The next hierarchical object type is the "tree" object. A tree object -is a list of mode/name/blob data, sorted by name. Alternatively, the -mode data may specify a directory mode, in which case instead of -naming a blob, that name is associated with another TREE object. - -Like the "blob" object, a tree object is uniquely determined by the -set contents, and so two separate but identical trees will always -share the exact same object. This is true at all levels, i.e. it's -true for a "leaf" tree (which does not refer to any other trees, only -blobs) as well as for a whole subdirectory. - -For that reason a "tree" object is just a pure data abstraction: it -has no history, no signatures, no verification of validity, except -that since the contents are again protected by the hash itself, we can -trust that the tree is immutable and its contents never change. - -So you can trust the contents of a tree to be valid, the same way you -can trust the contents of a blob, but you don't know where those -contents 'came' from. - -Side note on trees: since a "tree" object is a sorted list of -"filename+content", you can create a diff between two trees without -actually having to unpack two trees. Just ignore all common parts, -and your diff will look right. In other words, you can effectively -(and efficiently) tell the difference between any two random trees by -O(n) where "n" is the size of the difference, rather than the size of -the tree. - -Side note 2 on trees: since the name of a "blob" depends entirely and -exclusively on its contents (i.e. there are no names or permissions -involved), you can see trivial renames or permission changes by -noticing that the blob stayed the same. However, renames with data -changes need a smarter "diff" implementation. - -A tree is created with gitlink:git-write-tree[1] and -its data can be accessed by gitlink:git-ls-tree[1]. -Two trees can be compared with gitlink:git-diff-tree[1]. - -Commit Object -~~~~~~~~~~~~~ -The "commit" object is an object that introduces the notion of -history into the picture. In contrast to the other objects, it -doesn't just describe the physical state of a tree, it describes how -we got there, and why. - -A "commit" is defined by the tree-object that it results in, the -parent commits (zero, one or more) that led up to that point, and a -comment on what happened. Again, a commit is not trusted per se: -the contents are well-defined and "safe" due to the cryptographically -strong signatures at all levels, but there is no reason to believe -that the tree is "good" or that the merge information makes sense. -The parents do not have to actually have any relationship with the -result, for example. - -Note on commits: unlike real SCM's, commits do not contain -rename information or file mode change information. All of that is -implicit in the trees involved (the result tree, and the result trees -of the parents), and describing that makes no sense in this idiotic -file manager. - -A commit is created with gitlink:git-commit-tree[1] and -its data can be accessed by gitlink:git-cat-file[1]. - -Trust -~~~~~ -An aside on the notion of "trust". Trust is really outside the scope -of "git", but it's worth noting a few things. First off, since -everything is hashed with SHA1, you 'can' trust that an object is -intact and has not been messed with by external sources. So the name -of an object uniquely identifies a known state - just not a state that -you may want to trust. - -Furthermore, since the SHA1 signature of a commit refers to the -SHA1 signatures of the tree it is associated with and the signatures -of the parent, a single named commit specifies uniquely a whole set -of history, with full contents. You can't later fake any step of the -way once you have the name of a commit. - -So to introduce some real trust in the system, the only thing you need -to do is to digitally sign just 'one' special note, which includes the -name of a top-level commit. Your digital signature shows others -that you trust that commit, and the immutability of the history of -commits tells others that they can trust the whole history. - -In other words, you can easily validate a whole archive by just -sending out a single email that tells the people the name (SHA1 hash) -of the top commit, and digitally sign that email using something -like GPG/PGP. - -To assist in this, git also provides the tag object... - -Tag Object -~~~~~~~~~~ -Git provides the "tag" object to simplify creating, managing and -exchanging symbolic and signed tokens. The "tag" object at its -simplest simply symbolically identifies another object by containing -the sha1, type and symbolic name. - -However it can optionally contain additional signature information -(which git doesn't care about as long as there's less than 8k of -it). This can then be verified externally to git. - -Note that despite the tag features, "git" itself only handles content -integrity; the trust framework (and signature provision and -verification) has to come from outside. - -A tag is created with gitlink:git-mktag[1], -its data can be accessed by gitlink:git-cat-file[1], -and the signature can be verified by -gitlink:git-verify-tag[1]. - - -The "index" aka "Current Directory Cache" ------------------------------------------ -The index is a simple binary file, which contains an efficient -representation of a virtual directory content at some random time. It -does so by a simple array that associates a set of names, dates, -permissions and content (aka "blob") objects together. The cache is -always kept ordered by name, and names are unique (with a few very -specific rules) at any point in time, but the cache has no long-term -meaning, and can be partially updated at any time. - -In particular, the index certainly does not need to be consistent with -the current directory contents (in fact, most operations will depend on -different ways to make the index 'not' be consistent with the directory -hierarchy), but it has three very important attributes: - -'(a) it can re-generate the full state it caches (not just the -directory structure: it contains pointers to the "blob" objects so -that it can regenerate the data too)' - -As a special case, there is a clear and unambiguous one-way mapping -from a current directory cache to a "tree object", which can be -efficiently created from just the current directory cache without -actually looking at any other data. So a directory cache at any one -time uniquely specifies one and only one "tree" object (but has -additional data to make it easy to match up that tree object with what -has happened in the directory) - -'(b) it has efficient methods for finding inconsistencies between that -cached state ("tree object waiting to be instantiated") and the -current state.' - -'(c) it can additionally efficiently represent information about merge -conflicts between different tree objects, allowing each pathname to be -associated with sufficient information about the trees involved that -you can create a three-way merge between them.' - -Those are the three ONLY things that the directory cache does. It's a -cache, and the normal operation is to re-generate it completely from a -known tree object, or update/compare it with a live tree that is being -developed. If you blow the directory cache away entirely, you generally -haven't lost any information as long as you have the name of the tree -that it described. - -At the same time, the index is at the same time also the -staging area for creating new trees, and creating a new tree always -involves a controlled modification of the index file. In particular, -the index file can have the representation of an intermediate tree that -has not yet been instantiated. So the index can be thought of as a -write-back cache, which can contain dirty information that has not yet -been written back to the backing store. - - - -The Workflow ------------- -Generally, all "git" operations work on the index file. Some operations -work *purely* on the index file (showing the current state of the -index), but most operations move data to and from the index file. Either -from the database or from the working directory. Thus there are four -main combinations: - -1) working directory -> index -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You update the index with information from the working directory with -the gitlink:git-update-index[1] command. You -generally update the index information by just specifying the filename -you want to update, like so: - - git-update-index filename - -but to avoid common mistakes with filename globbing etc, the command -will not normally add totally new entries or remove old entries, -i.e. it will normally just update existing cache entries. - -To tell git that yes, you really do realize that certain files no -longer exist, or that new files should be added, you -should use the `--remove` and `--add` flags respectively. - -NOTE! A `--remove` flag does 'not' mean that subsequent filenames will -necessarily be removed: if the files still exist in your directory -structure, the index will be updated with their new status, not -removed. The only thing `--remove` means is that update-cache will be -considering a removed file to be a valid thing, and if the file really -does not exist any more, it will update the index accordingly. - -As a special case, you can also do `git-update-index --refresh`, which -will refresh the "stat" information of each index to match the current -stat information. It will 'not' update the object status itself, and -it will only update the fields that are used to quickly test whether -an object still matches its old backing store object. - -2) index -> object database -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You write your current index file to a "tree" object with the program - - git-write-tree - -that doesn't come with any options - it will just write out the -current index into the set of tree objects that describe that state, -and it will return the name of the resulting top-level tree. You can -use that tree to re-generate the index at any time by going in the -other direction: - -3) object database -> index -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You read a "tree" file from the object database, and use that to -populate (and overwrite - don't do this if your index contains any -unsaved state that you might want to restore later!) your current -index. Normal operation is just - - git-read-tree - -and your index file will now be equivalent to the tree that you saved -earlier. However, that is only your 'index' file: your working -directory contents have not been modified. - -4) index -> working directory -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You update your working directory from the index by "checking out" -files. This is not a very common operation, since normally you'd just -keep your files updated, and rather than write to your working -directory, you'd tell the index files about the changes in your -working directory (i.e. `git-update-index`). - -However, if you decide to jump to a new version, or check out somebody -else's version, or just restore a previous tree, you'd populate your -index file with read-tree, and then you need to check out the result -with - - git-checkout-index filename - -or, if you want to check out all of the index, use `-a`. - -NOTE! git-checkout-index normally refuses to overwrite old files, so -if you have an old version of the tree already checked out, you will -need to use the "-f" flag ('before' the "-a" flag or the filename) to -'force' the checkout. - - -Finally, there are a few odds and ends which are not purely moving -from one representation to the other: - -5) Tying it all together -~~~~~~~~~~~~~~~~~~~~~~~~ -To commit a tree you have instantiated with "git-write-tree", you'd -create a "commit" object that refers to that tree and the history -behind it - most notably the "parent" commits that preceded it in -history. - -Normally a "commit" has one parent: the previous state of the tree -before a certain change was made. However, sometimes it can have two -or more parent commits, in which case we call it a "merge", due to the -fact that such a commit brings together ("merges") two or more -previous states represented by other commits. - -In other words, while a "tree" represents a particular directory state -of a working directory, a "commit" represents that state in "time", -and explains how we got there. - -You create a commit object by giving it the tree that describes the -state at the time of the commit, and a list of parents: - - git-commit-tree -p [-p ..] - -and then giving the reason for the commit on stdin (either through -redirection from a pipe or file, or by just typing it at the tty). - -git-commit-tree will return the name of the object that represents -that commit, and you should save it away for later use. Normally, -you'd commit a new `HEAD` state, and while git doesn't care where you -save the note about that state, in practice we tend to just write the -result to the file pointed at by `.git/HEAD`, so that we can always see -what the last committed state was. - -Here is an ASCII art by Jon Loeliger that illustrates how -various pieces fit together. - ------------- - - commit-tree - commit obj - +----+ - | | - | | - V V - +-----------+ - | Object DB | - | Backing | - | Store | - +-----------+ - ^ - write-tree | | - tree obj | | - | | read-tree - | | tree obj - V - +-----------+ - | Index | - | "cache" | - +-----------+ - update-index ^ - blob obj | | - | | - checkout-index -u | | checkout-index - stat | | blob obj - V - +-----------+ - | Working | - | Directory | - +-----------+ - ------------- - - -6) Examining the data -~~~~~~~~~~~~~~~~~~~~~ - -You can examine the data represented in the object database and the -index with various helper tools. For every object, you can use -gitlink:git-cat-file[1] to examine details about the -object: - - git-cat-file -t - -shows the type of the object, and once you have the type (which is -usually implicit in where you find the object), you can use - - git-cat-file blob|tree|commit|tag - -to show its contents. NOTE! Trees have binary content, and as a result -there is a special helper for showing that content, called -`git-ls-tree`, which turns the binary content into a more easily -readable form. - -It's especially instructive to look at "commit" objects, since those -tend to be small and fairly self-explanatory. In particular, if you -follow the convention of having the top commit name in `.git/HEAD`, -you can do - - git-cat-file commit HEAD - -to see what the top commit was. - -7) Merging multiple trees -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Git helps you do a three-way merge, which you can expand to n-way by -repeating the merge procedure arbitrary times until you finally -"commit" the state. The normal situation is that you'd only do one -three-way merge (two parents), and commit it, but if you like to, you -can do multiple parents in one go. - -To do a three-way merge, you need the two sets of "commit" objects -that you want to merge, use those to find the closest common parent (a -third "commit" object), and then use those commit objects to find the -state of the directory ("tree" object) at these points. - -To get the "base" for the merge, you first look up the common parent -of two commits with - - git-merge-base - -which will return you the commit they are both based on. You should -now look up the "tree" objects of those commits, which you can easily -do with (for example) - - git-cat-file commit | head -1 - -since the tree object information is always the first line in a commit -object. - -Once you know the three trees you are going to merge (the one -"original" tree, aka the common case, and the two "result" trees, aka -the branches you want to merge), you do a "merge" read into the -index. This will complain if it has to throw away your old index contents, so you should -make sure that you've committed those - in fact you would normally -always do a merge against your last commit (which should thus match -what you have in your current index anyway). - -To do the merge, do - - git-read-tree -m -u - -which will do all trivial merge operations for you directly in the -index file, and you can just write the result out with -`git-write-tree`. - -Historical note. We did not have `-u` facility when this -section was first written, so we used to warn that -the merge is done in the index file, not in your -working tree, and your working tree will not match your -index after this step. -This is no longer true. The above command, thanks to `-u` -option, updates your working tree with the merge results for -paths that have been trivially merged. - - -8) Merging multiple trees, continued -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Sadly, many merges aren't trivial. If there are files that have -been added.moved or removed, or if both branches have modified the -same file, you will be left with an index tree that contains "merge -entries" in it. Such an index tree can 'NOT' be written out to a tree -object, and you will have to resolve any such merge clashes using -other tools before you can write out the result. - -You can examine such index state with `git-ls-files --unmerged` -command. An example: - ------------------------------------------------- -$ git-read-tree -m $orig HEAD $target -$ git-ls-files --unmerged -100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c -100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c ------------------------------------------------- - -Each line of the `git-ls-files --unmerged` output begins with -the blob mode bits, blob SHA1, 'stage number', and the -filename. The 'stage number' is git's way to say which tree it -came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` -tree, and stage3 `$target` tree. - -Earlier we said that trivial merges are done inside -`git-read-tree -m`. For example, if the file did not change -from `$orig` to `HEAD` nor `$target`, or if the file changed -from `$orig` to `HEAD` and `$orig` to `$target` the same way, -obviously the final outcome is what is in `HEAD`. What the -above example shows is that file `hello.c` was changed from -`$orig` to `HEAD` and `$orig` to `$target` in a different way. -You could resolve this by running your favorite 3-way merge -program, e.g. `diff3` or `merge`, on the blob objects from -these three stages yourself, like this: - ------------------------------------------------- -$ git-cat-file blob 263414f... >hello.c~1 -$ git-cat-file blob 06fa6a2... >hello.c~2 -$ git-cat-file blob cc44c73... >hello.c~3 -$ merge hello.c~2 hello.c~1 hello.c~3 ------------------------------------------------- - -This would leave the merge result in `hello.c~2` file, along -with conflict markers if there are conflicts. After verifying -the merge result makes sense, you can tell git what the final -merge result for this file is by: - - mv -f hello.c~2 hello.c - git-update-index hello.c - -When a path is in unmerged state, running `git-update-index` for -that path tells git to mark the path resolved. - -The above is the description of a git merge at the lowest level, -to help you understand what conceptually happens under the hood. -In practice, nobody, not even git itself, uses three `git-cat-file` -for this. There is `git-merge-index` program that extracts the -stages to temporary files and calls a "merge" script on it: - - git-merge-index git-merge-one-file hello.c - -and that is what higher level `git resolve` is implemented with. +Git is a fast, scalable, distributed revision control system with an +unusually rich command set that provides both high-level operations +and full access to internals. + +Git is an Open Source project covered by the GNU General Public License. +It was originally written by Linus Torvalds with help of a group of +hackers around the net. It is currently maintained by Junio C Hamano. + +Please read the file INSTALL for installation instructions. +See Documentation/tutorial.txt to get started, then see +Documentation/everyday.txt for a useful minimum set of commands, +and "man git-commandname" for documentation of each command. +CVS users may also want to read Documentation/cvs-migration.txt. + +Many Git online resources are accessible from http://git.or.cz/ +including full documentation and Git related tools. + +The user discussion and development of Git take place on the Git +mailing list -- everyone is welcome to post bug reports, feature +requests, comments and patches to git@vger.kernel.org. To subscribe +to the list, send an email with just "subscribe git" in the body to +majordomo@vger.kernel.org. The mailing list archives are available at +http://marc.theaimsgroup.com/?l=git and other archival sites.