git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  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).