From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Elijah Newren <newren@gmail.com>, git@vger.kernel.org
Subject: Re: bug in en/header-split-cache-h-part-3, was Re: What's cooking in git.git (Jun 2023, #05; Tue, 20)
Date: Wed, 21 Jun 2023 15:03:52 -0700 [thread overview]
Message-ID: <xmqqjzvwfp6f.fsf@gitster.g> (raw)
In-Reply-To: <20230621202642.GA1423@coredump.intra.peff.net> (Jeff King's message of "Wed, 21 Jun 2023 16:26:42 -0400")
Jeff King <peff@peff.net> writes:
> Yeah. I guess the real build problem is actually in the merge of split-2
> (it conflicted with a simultaneous topic, hence the fix coming in the
> merge). So another option to address that here would be to amend the
> 4bd872e0ed (Merge branch 'en/header-split-cache-h-part-2' into
> en/header-split-cache-h-part-3, 2023-05-08) to include that fixup.
>
> As for the others, I'd consider:
>
> 1. (optional) Drop the #ifndef at the very start of the series, before
> we touch anything, with the rationale that it is not doing anything
> and masks errors. I don't _think_ this can ever backfire, because
> we unconditionally set DEFAULT_GIT_TEMPLATE_DIR (unlike some other
> things like DEFAULT_PAGER, where the Makefile might leave it
> unset). But we can also leave this out, or do it as a separate
> topic, if we want to minimize changes / risk of screwing something
> up.
>
> 2. Squash the Makefile fix into the "adopt shared init-db" patch
> (currently 0d652b238).
>
> And that would leave the result fully bisectable. But if we prefer to
> keep the history closer to reality, I can prepare the Makefile thing as
> a patch on top.
I've done the messiest, I guess ;-)
* revert merge of the part-3 topic and Dscho's cmake fix out of 'next'.
* rebase part-3 on top of the more recent 'master'.
* squash in the two hunks (including setup.c change) from you into
the "setup: adopt shared init-db & clone code" step.
* squash in Dscho's cmake fix into "cache.h: remove this
no-longer-used header" step.
The result is not in 'next' yet until I hear something from those
who have been involved in the topic, including Elijah and Dscho.
Thanks.
next prev parent reply other threads:[~2023-06-21 22:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 0:04 What's cooking in git.git (Jun 2023, #05; Tue, 20) Junio C Hamano
2023-06-21 8:55 ` bug in en/header-split-cache-h-part-3, was " Jeff King
2023-06-21 17:05 ` Junio C Hamano
2023-06-21 20:26 ` Jeff King
2023-06-21 22:03 ` Junio C Hamano [this message]
2023-06-23 6:33 ` Elijah Newren
2023-06-23 16:38 ` Junio C Hamano
2023-06-24 1:25 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqjzvwfp6f.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).