From b6936205e73c058784288d21d1937e5bba26b91b Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Fri, 2 Feb 2007 05:10:25 -0800 Subject: [PATCH 1/6] Disallow invalid --pretty= abbreviations --pretty=o is a valid abbreviation, --pretty=omfg is not Noticed by: Nicolas Vilz Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano --- commit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/commit.c b/commit.c index 9b2b842e7d..3e8c87294b 100644 --- a/commit.c +++ b/commit.c @@ -47,7 +47,8 @@ enum cmit_fmt get_commit_format(const char *arg) if (*arg == '=') arg++; for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) { - if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len)) + if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len) && + !strncmp(arg, cmt_fmts[i].n, strlen(arg))) return cmt_fmts[i].v; } From 0d18e41e008e9ac1f371d090e2e1b85481221796 Mon Sep 17 00:00:00 2001 From: Andy Parkins Date: Fri, 2 Feb 2007 23:56:08 +0000 Subject: [PATCH 2/6] doc: hooks.txt said post-commit default sends an email, it doesn't The default post-commit hook is actually empty; it is the update hook that sends an email. This patch corrects hooks.txt to reflect that. Signed-off-by: Andy Parkins Signed-off-by: Junio C Hamano --- Documentation/hooks.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt index e3b76f96eb..b083290d12 100644 --- a/Documentation/hooks.txt +++ b/Documentation/hooks.txt @@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of `git-commit`. -The default 'post-commit' hook, when enabled, demonstrates how to -send out a commit notification e-mail. - update ------ @@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you want to report something to the `git-send-pack` on the other end, you can simply `echo` your messages. +The default 'update' hook, when enabled, demonstrates how to +send out a notification e-mail. post-update ----------- From 3cf8b462d2dbe78233bba5c0765ecaa2c6b6cd99 Mon Sep 17 00:00:00 2001 From: "Shawn O. Pearce" Date: Fri, 2 Feb 2007 03:00:03 -0500 Subject: [PATCH 3/6] Don't leak file descriptors from unavailable pack files. If open_packed_git failed it may have been because the packfile actually exists and is readable, but some sort of verification did not pass. In this case open_packed_git left pack_fd filled in, as the file descriptor is valid. We don't want to leak the file descriptor, nor do we want to allow someone in the future to use this packed_git. Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano --- sha1_file.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 2eff14ac87..45e410e883 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -552,7 +552,11 @@ void unuse_pack(struct pack_window **w_cursor) } } -static int open_packed_git(struct packed_git *p) +/* + * Do not call this directly as this leaks p->pack_fd on error return; + * call open_packed_git() instead. + */ +static int open_packed_git_1(struct packed_git *p) { struct stat st; struct pack_header hdr; @@ -608,6 +612,17 @@ static int open_packed_git(struct packed_git *p) return 0; } +static int open_packed_git(struct packed_git *p) +{ + if (!open_packed_git_1(p)) + return 0; + if (p->pack_fd != -1) { + close(p->pack_fd); + p->pack_fd = -1; + } + return -1; +} + static int in_window(struct pack_window *win, unsigned long offset) { /* We must promise at least 20 bytes (one hash) after the From 953202a3fd68f84210cfe9bf102c534ac3ee40e4 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 2 Feb 2007 22:19:17 -0800 Subject: [PATCH 4/6] Tutorial: fix asciidoc formatting of "git add" section. Signed-off-by: Junio C Hamano --- Documentation/tutorial.txt | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index adb1e32750..ea3418909e 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways: 1) By using 'git add ...' - This can be performed multiple times before a commit. Note that this - is not only for adding new files. Even modified files must be - added to the set of changes about to be committed. The "git status" - command gives you a summary of what is included so far for the - next commit. When done you should use the 'git commit' command to - make it real. +This can be performed multiple times before a commit. Note that this +is not only for adding new files. Even modified files must be +added to the set of changes about to be committed. The "git status" +command gives you a summary of what is included so far for the +next commit. When done you should use the 'git commit' command to +make it real. - Note: don't forget to 'add' a file again if you modified it after the - first 'add' and before 'commit'. Otherwise only the previous added - state of that file will be committed. This is because git tracks - content, so what you're really 'add'ing to the commit is the *content* - of the file in the state it is in when you 'add' it. +Note: don't forget to 'add' a file again if you modified it after the +first 'add' and before 'commit'. Otherwise only the previous added +state of that file will be committed. This is because git tracks +content, so what you're really 'add'ing to the commit is the *content* +of the file in the state it is in when you 'add' it. 2) By using 'git commit -a' directly - This is a quick way to automatically 'add' the content from all files - that were modified since the previous commit, and perform the actual - commit without having to separately 'add' them beforehand. This will - not add content from new files i.e. files that were never added before. - Those files still have to be added explicitly before performing a - commit. +This is a quick way to automatically 'add' the content from all files +that were modified since the previous commit, and perform the actual +commit without having to separately 'add' them beforehand. This will +not add content from new files i.e. files that were never added before. +Those files still have to be added explicitly before performing a +commit. But here's a twist. If you do 'git commit ...' then only the changes belonging to those explicitly specified files will be From bf3478de973607ebe5b7689fa76e05c3f344aabd Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 2 Feb 2007 22:55:07 -0800 Subject: [PATCH 5/6] Tutorial-2: Adjust git-status output to recent reality. Signed-off-by: Junio C Hamano --- Documentation/tutorial-2.txt | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt index f363d17f0b..8d89992712 100644 --- a/Documentation/tutorial-2.txt +++ b/Documentation/tutorial-2.txt @@ -352,24 +352,23 @@ situation: ------------------------------------------------ $ git status -# -# Added but not yet committed: -# (will commit) +# On branch master +# Changes to be committed: +# (use "git reset HEAD ..." to unstage) # # new file: closing.txt # -# -# Changed but not added: -# (use "git add file1 file2" to include for commit) +# Changed but not updated: +# (use "git add ..." to update what will be committed) # # modified: file.txt # ------------------------------------------------ Since the current state of closing.txt is cached in the index file, -it is listed as "added but not yet committed". Since file.txt has +it is listed as "Changes to be committed". Since file.txt has changes in the working directory that aren't reflected in the index, -it is marked "changed but not added". At this point, running "git +it is marked "changed but not updated". At this point, running "git commit" would create a commit that added closing.txt (with its new contents), but that didn't modify file.txt. From 505739f6c0c67b7426ffbc723734c794b0a810d9 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 2 Feb 2007 23:17:34 -0800 Subject: [PATCH 6/6] core-tutorial: http reference link fix Signed-off-by: Junio C Hamano --- Documentation/core-tutorial.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt index 1cd834b0ff..9c28bea62e 100644 --- a/Documentation/core-tutorial.txt +++ b/Documentation/core-tutorial.txt @@ -1469,8 +1469,8 @@ Working with Others Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There -is a nice illustration (page 17, "Merges to Mainline") in Randy -Dunlap's presentation (`http://tinyurl.com/a2jdg`). +is a nice illustration (page 17, "Merges to Mainline") in +link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in git that enforces the "chain of