From 13494ed14c3539b3e36ff47d1d8b65f5a9a3043b Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 23 Oct 2008 04:30:58 +0000 Subject: [PATCH 1/8] correct cache_entry allocation Most cache_entry structs are allocated by using the cache_entry_size macro, which rounds the size of the struct up to the nearest multiple of 8 bytes (presumably to avoid memory fragmentation). There is one exception: the special "conflict entry" is allocated with an empty name, and so is explicitly given just one extra byte to hold the NUL. However, later code doesn't realize that this particular struct has been allocated differently, and happily tries reading and copying it based on the ce_size macro, which assumes the 8-byte alignment. This can lead to reading uninitalized data, though since that data is simply padding, there shouldn't be any problem as a result. Still, it makes sense to hold the padding assumption so as not to surprise later maintainers. This fixes valgrind errors in t1005, t3030, t4002, and t4114. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- unpack-trees.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/unpack-trees.c b/unpack-trees.c index e59d144d28..e5749ef638 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -382,7 +382,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options o->merge_size = len; if (!dfc) - dfc = xcalloc(1, sizeof(struct cache_entry) + 1); + dfc = xcalloc(1, cache_entry_size(0)); o->df_conflict_entry = dfc; if (len) { From 421b488a58fea89ceb55d5b358738e9251d44f5e Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 23 Oct 2008 04:31:03 +0000 Subject: [PATCH 2/8] pack-objects: avoid reading uninitalized data In the main loop of find_deltas, we do: struct object_entry *entry = *list++; ... if (!*list_size) ... break Because we look at and increment *list _before_ the check of list_size, in the very last iteration of the loop we will look at uninitialized data, and increment the pointer beyond one past the end of the allocated space. Since we don't actually do anything with the data until after the check, this is not a problem in practice. But since it technically violates the C standard, and because it provokes a spurious valgrind warning, let's just move the initialization of entry to a safe place. This fixes valgrind errors in t5300, t5301, t5302, t303, and t9400. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- builtin-pack-objects.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index 4004e73e40..b0dddbee4f 100644 --- a/builtin-pack-objects.c +++ b/builtin-pack-objects.c @@ -1377,7 +1377,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size, memset(array, 0, array_size); for (;;) { - struct object_entry *entry = *list++; + struct object_entry *entry; struct unpacked *n = array + idx; int j, max_depth, best_base = -1; @@ -1386,6 +1386,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size, progress_unlock(); break; } + entry = *list++; (*list_size)--; if (!entry->preferred_base) { (*processed)++; From 1442171bc913a9cddae5c6ad0d0a4be3a1ca86e8 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 23 Oct 2008 04:32:23 +0000 Subject: [PATCH 3/8] fix overlapping memcpy in normalize_absolute_path The comments for normalize_absolute_path explicitly claim that the source and destination buffers may be the same (though they may not otherwise overlap). Thus the call to memcpy may involve copying overlapping data, and memmove should be used instead. This fixes a valgrind error in t1504. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/path.c b/path.c index 76e8872622..c1cb54b7b8 100644 --- a/path.c +++ b/path.c @@ -348,7 +348,7 @@ int normalize_absolute_path(char *buf, const char *path) goto next; } - memcpy(dst, comp_start, comp_len); + memmove(dst, comp_start, comp_len); dst += comp_len; next: comp_start = comp_end; From 30affa1e9a15e848f77c9c14544dd6dd593559d5 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Wed, 29 Oct 2008 05:17:55 +0000 Subject: [PATCH 4/8] send-pack: do not send out single-level refs such as refs/stash Since no version of receive-pack accepts these "funny refs", we should mirror the check when considering the list of refs to send. IOW, don't even make them eligible for matching or mirroring. Signed-off-by: Junio C Hamano --- builtin-send-pack.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/builtin-send-pack.c b/builtin-send-pack.c index 2af9f29341..301f230432 100644 --- a/builtin-send-pack.c +++ b/builtin-send-pack.c @@ -132,7 +132,13 @@ static struct ref *remote_refs, **remote_tail; static int one_local_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data) { struct ref *ref; - int len = strlen(refname) + 1; + int len; + + /* we already know it starts with refs/ to get here */ + if (check_ref_format(refname + 5)) + return 0; + + len = strlen(refname) + 1; ref = xcalloc(1, sizeof(*ref) + len); hashcpy(ref->new_sha1, sha1); memcpy(ref->name, refname, len); From 8c178687959732edab8bf91da9ed9f4fbcf7c14e Mon Sep 17 00:00:00 2001 From: Pierre Habouzit Date: Fri, 31 Oct 2008 18:57:10 +0000 Subject: [PATCH 5/8] git send-email: avoid leaking directory file descriptors. Signed-off-by: Pierre Habouzit Signed-off-by: Junio C Hamano --- git-send-email.perl | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index d2fd899076..18529c76e6 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -407,10 +407,9 @@ for my $f (@ARGV) { push @files, grep { -f $_ } map { +$f . "/" . $_ } sort readdir(DH); - + closedir(DH); } elsif (-f $f or -p $f) { push @files, $f; - } else { print STDERR "Skipping $f - not found.\n"; } From 4f73e240f98c38e608afe68887639c6e63b1d18f Mon Sep 17 00:00:00 2001 From: Jakub Narebski Date: Sat, 1 Nov 2008 06:24:55 +0000 Subject: [PATCH 6/8] Documentation/gitattributes: Add subsection header for each attribute This makes attributes easier to find; before this patch some attributes had individual subsections, and some didn't. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano --- Documentation/gitattributes.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 42776f089b..37fff208ff 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -213,6 +213,9 @@ with `crlf`, and then `ident` and fed to `filter`. Generating diff text ~~~~~~~~~~~~~~~~~~~~ +`diff` +^^^^^^ + The attribute `diff` affects if 'git-diff' generates textual patch for the path or just says `Binary files differ`. It also can affect what line is shown on the hunk header `@@ -k,l +n,m @@` @@ -323,6 +326,9 @@ patterns are available: Performing a three-way merge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +`merge` +^^^^^^^ + The attribute `merge` affects how three versions of a file is merged when a file-level merge is necessary during `git merge`, and other programs such as `git revert` and `git cherry-pick`. From c2163c6aa2343b21ebc73f7e62cbdecc8dba3a42 Mon Sep 17 00:00:00 2001 From: Tom Preston-Werner Date: Sat, 1 Nov 2008 15:28:18 +0000 Subject: [PATCH 7/8] add instructions on how to send patches to the mailing list with Gmail Gmail is one of the most popular email providers in the world. Now that Gmail supports IMAP, sending properly formatted patches via `git imap-send` is trivial. This section in SubmittingPatches explains how to do so. Signed-off-by: Tom Preston-Werner Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 841bead9db..c59edfa6a9 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail. 5) Back in the compose window: add whatever other text you wish to the message, complete the addressing and subject fields, and press send. + + +Gmail +----- + +Submitting properly formatted patches via Gmail is simple now that +IMAP support is available. First, edit your ~/.gitconfig to specify your +account settings: + +[imap] + folder = "[Gmail]/Drafts" + host = imaps://imap.gmail.com + user = user@gmail.com + pass = p4ssw0rd + port = 993 + sslverify = false + +Next, ensure that your Gmail settings are correct. In "Settings" the +"Use Unicode (UTF-8) encoding for outgoing messages" should be checked. + +Once your commits are ready to send to the mailing list, run the following +command to send the patch emails to your Gmail Drafts folder. + + $ git format-patch -M --stdout origin/master | git imap-send + +Go to your Gmail account, open the Drafts folder, find the patch email, fill +in the To: and CC: fields and send away! From 1a9016aae5aa8c468bb2d8d5dd16303d5c005869 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Sun, 2 Nov 2008 00:14:04 -0700 Subject: [PATCH 8/8] Start 1.6.0.4 cycle Signed-off-by: Junio C Hamano --- Documentation/RelNotes-1.6.0.4.txt | 29 +++++++++++++++++++++++++++++ RelNotes | 2 +- 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 Documentation/RelNotes-1.6.0.4.txt diff --git a/Documentation/RelNotes-1.6.0.4.txt b/Documentation/RelNotes-1.6.0.4.txt new file mode 100644 index 0000000000..4a4530b728 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.4.txt @@ -0,0 +1,29 @@ +GIT v1.6.0.4 Release Notes +========================== + +Fixes since v1.6.0.3 +-------------------- + +* 'git-add -p' said "No changes" when only binary files were changed. + +* git-archive did not work correctly in bare repositories. + +* when we refuse to detect renames because there are too many new or + deleted files, we did not say how many there are. + +* 'git-push --mirror' tried and failed to push the stash; there is no + point in sending it to begin with. + +* 'git-send-email' had a small fd leak while scanning directory. + +* git-svn used deprecated 'git-foo' form of subcommand invocaition. + +* Plugged small memleaks here and there. + +* Also contains many documentation updates. + +-- +exec >/var/tmp/1 +O=v1.6.0.3-22-gc2163c6 +echo O=$(git describe maint) +git shortlog --no-merges $O..maint diff --git a/RelNotes b/RelNotes index a677737b90..f9eb552873 120000 --- a/RelNotes +++ b/RelNotes @@ -1 +1 @@ -Documentation/RelNotes-1.6.0.3.txt \ No newline at end of file +Documentation/RelNotes-1.6.0.4.txt \ No newline at end of file