What's cooking in git.git (Sep 2021, #07; Thu, 23)

Here are the topics that have been cooking in my tree.  Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release).  Commits prefixed with '-' are only in 'seen',
which means nothing more than that I have found them of interest for
some reason (like "it may have hard-to-resolve conflicts with
another topic already in flight" or "this may turn out to be
useful").  Do not read too much into a topic being in (or not in)
'seen'.  The ones marked with '.' do not appear in any of the
integration branches, but I am still holding onto them.

The eighth batch is out.

Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors.  Some
repositories have only a subset of branches.

With maint, master, next, seen, todo:

	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-vcs/git/

With all the integration branches and topics broken out:

	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/

Release tarballs are available at:

	https://www.kernel.org/pub/software/scm/git/

1088 more lines

On Thu, Sep 23, 2021 at 04:22:00PM -0700, Junio C Hamano wrote:

* tb/commit-graph-usage-fix (2021-09-22) 2 commits
 Will merge to 'next'.

Thanks, this pair of trivial fixes hopefully shouldn't cause many
issues ;).

* tb/repack-write-midx (2021-09-16) 8 commits
 Will merge to 'next'?

Probably good to hold off; I know that Google folks made this the
subject of their review club meeting, and had only gotten part of the
way through the series.

* tb/midx-write-propagate-namehash (2021-09-17) 7 commits
 Will merge to 'next'?

Yes, please. Peff reviewed this and was happy with the latest version,
which matches your copy.

c.f., https://lore.kernel.org/git/YUUS4Mrh85KPucmi@coredump.intra.peff.net/

Thanks,
Taylor

On Thu, Sep 23, 2021 at 4:24 PM Junio C Hamano [off-list ref] wrote:

* pw/rebase-of-a-tag-fix (2021-09-22) 10 commits
 - rebase: dereference tags
 - rebase: use lookup_commit_reference_by_name()
 - rebase: use our standard error return value
 - t3407: rework rebase --quit tests
 - t3407: strengthen rebase --abort tests
 - t3407: use test_path_is_missing
 - t3407: rename a variable
 - t3407: use test_cmp_rev
 - t3407: use test_commit
 - t3407: run tests in $TEST_DIRECTORY

 "git rebase <upstream> <tag>" failed when aborted in the middle, as
 it mistakenly tried to write the tag object instead of peeling it
 to HEAD.

 Will merge to 'next'?

I think so; the series looks good to me, and it appears Phillip
addressed everyone else's feedback.

On Thu, Sep 23, 2021 at 04:22:00PM -0700, Junio C Hamano wrote:

* js/win-lazyload-buildfix (2021-09-23) 2 commits
 - lazyload.h: use an even more generic function pointer than FARPROC
 - lazyload.h: fix warnings about mismatching function pointer types

 Compilation fix.

 Will merge to 'next'.

Sorry to hijack this thread with this minor point, but I was hoping[1]
from a reroll of this topic from Hannes.

Alternatively the patch below the scissors would be nice to squash or
it will be harder to fix later.

Carlo

CC: +Hannes
[1] https://lore.kernel.org/git/CAPUEspivB=07OponiMrfXFBrC+L7qjSUuZEV9q-Ug5Z_ShnFNA@mail.gmail.com/
----- >8 -----
Subject: [PATCH] fixup! lazyload.h: fix warnings about mismatching function
 pointer types

The original patch will require the declaration this macro creates
to be moved to the end of the local variables or will trigger
-Wdeclaration-after-statement because it will likely end in ";;" if
the macro call has one, as it is common.

Remove trailing ';' from macro definition, for easy of use.

Signed-off-by: Carlo Marcelo Arenas Belón <redacted>
---
 compat/win32/lazyload.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/win32/lazyload.h b/compat/win32/lazyload.h
index c688e545ad..2b3637135f 100644
--- a/compat/win32/lazyload.h
+++ b/compat/win32/lazyload.h

@@ -29,7 +29,7 @@ struct proc_addr {
 	static struct proc_addr proc_addr_##function = \
 	{ #dll, #function, NULL, 0 }; \
 	typedef rettype (WINAPI *proc_type_##function)(__VA_ARGS__); \
-	static proc_type_##function function;
+	static proc_type_##function function
 
 /*
  * Loads a function from a DLL (once-only).

-- 
2.33.0.955.gee03ddbf0e

Am 24.09.21 um 11:14 schrieb Carlo Marcelo Arenas Belón:

Good find! This looks correct. The trailing semicolon was not present
before I added it with my change. Thank you very much for fixing up my
carelessness.

-- Hannes

On 24/09/2021 01:22, Junio C Hamano wrote:

* ah/connect-parse-feature-v0-fix (2021-09-23) 1 commit
  - connect: also update offset for features without values

  Protocol v0 clients can get stuck parsing a malformed feature line.

  Will merge to 'next'.

I hope it's not too late - I ended up sending out a V2 at:
https://public-inbox.org/git/e1395ff2-e697-83b2-082b-d5468b7a11ac@ahunt.org/T/#md3a45bb0fdf9cfd49e0fabdb1b21cd045df523c5

The differences are:
- Peff's test (and most importantly: test stability) improvements - which you might already have incorporated - from https://public-inbox.org/git/e1395ff2-e697-83b2-082b-d5468b7a11ac@ahunt.org/T/#m5cac36b2e4aa03d452a391a3c9d2495c3a423810
- An attempt at improving the commit message, which isn't crucial.

ATB,

    Andrzej