Post 1.7.10 cycle

Post 1.7.10 cycle

[Junio C Hamano]

It's now time to pick among the topics that have been cooking in 'next'
and 'pu' which ones to start moving to 'master' in what order.

I've already kicked one topic out of 'next' as it regresses the http proxy
support, but I haven't spent enough time to look at the other topics again
closely enough to decide.  I was hoping that we could feed a handful of
topics every few days to 'master'.

I think the following topics (in 'next') are more or less ready:

da/difftool-test
jn/diffstat-tests
jc/commit-hook-authorship
tr/maint-word-diff-regex-sticky
rs/unpack-trees-leakfix
jc/diff-algo-cleanup
nd/stream-more
zj/test-cred-helper-nicer-prove
nl/rebase-i-cheat-sheet
jc/maint-clean-nested-worktree-in-subdir
jh/notes-merge-in-git-dir-worktree

These (in 'next') are "ready" code-wise, but we would need to see the end
of the "upstream", "current" or "beginner" discussion:

ct/advise-push-default
mm/push-default-switch-warning


And I think these in 'pu' are ready for 'next':

jk/diff-no-rename-empty
rs/combine-diff-zero-context-at-the-beginning
jc/commit-unedited-template
jk/http-backend-keep-committer-ident-env
jc/push-upstream-sanity
jk/branch-quiet
jc/run-hook-env-1
sl/autoconf
jb/am-include
jc/am-report-3way
jc/fmt-merge-msg-people
wk/gitweb-snapshot-use-if-modified-since
bw/spawn-via-shell-path
it/fetch-pack-many-refs
jn/debian-customizes-default-editor
jk/add-p-skip-conflicts


Others not listed here fall into one of the following categories:

 (1) known to be incomplete;
 (2) stalled;
 (3) I simply haven't stared at them long enough; or
 (4) I don't have strong opinion in the area in general.

I'll do a proper "What's cooking" later tonight or tomorrow.

Re: Post 1.7.10 cycle

[René Scharfe]

Am 10.04.2012 02:22, schrieb Junio C Hamano:
> It's now time to pick among the topics that have been cooking in 'next'
> and 'pu' which ones to start moving to 'master' in what order.
> 
> I've already kicked one topic out of 'next' as it regresses the http proxy
> support, but I haven't spent enough time to look at the other topics again
> closely enough to decide.  I was hoping that we could feed a handful of
> topics every few days to 'master'.
> 
> I think the following topics (in 'next') are more or less ready:

> rs/unpack-trees-leakfix

Please apply the following patch before this one.  It makes sure that it
is a pure leak fix.  Without the added check, it'd change the behaviour
slightly: with o->merge == 0, we'd call mark_ce_used() on src[0]; before
it would point to the leaked version, but after the patch it points to
the version that has been added using do_add_entry().  Not sure if this
can lead to any user-visible consequences, but this is cleaner.

-- >8 --
Subject: unpack-trees: don't perform any index operation if we're not merging

src[0] points to the index entry in the merge case and to the first
tree to unpack in the non-merge case.  We only want to mark the index
entry, so check first if we're merging.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
 unpack-trees.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/unpack-trees.c b/unpack-trees.c
index 7c9ecf6..60b728e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -772,7 +772,7 @@ static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, str
 	if (unpack_nondirectories(n, mask, dirmask, src, names, info) < 0)
 		return -1;
 
-	if (src[0]) {
+	if (o->merge && src[0]) {
 		if (ce_stage(src[0]))
 			mark_ce_used_same_name(src[0], o);
 		else
-- 
1.7.10