All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Elijah Newren <newren@gmail.com>, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH] pack-bitmap.c: ensure pack validity for all reuse packs
Date: Wed, 18 Dec 2024 20:31:06 -0500	[thread overview]
Message-ID: <Z2N3WkMj34ACPEoy@nand.local> (raw)
In-Reply-To: <xmqqplloo4jw.fsf@gitster.g>

On Wed, Dec 18, 2024 at 05:16:35PM -0800, Junio C Hamano wrote:
> >> I wonder what we can do better to make sure the work a contributor has
> >> already done (in this case, resolve interaction between two topics) is
> >> not wasted and recreated (possibly incorrectly) by the maintainer.
> >
> > I am not sure. During the interim maintainer period, Patrick sent a
> > couple of rounds of ps/build with a final patch to the effect of
> > "unbreak everything in seen", which could be dropped.
> >
> > But I think an easier thing to do would have been for myself to indicate
> > that you'd run into a non-trivial conflict here and provide the
> > resolution proactively.
>
> A trick used by recent series from Patrick say things like "this is
> based on X, with Y and Z merged".  This patch could have done the
> same way.  It of course makes two topics entangled and one takes the
> other hostage, so we need to carefully judge if such a dependency is
> worth it.  So far, I found Patrick's judgement on the choice of
> dependencies quite solid (essentially, Y and Z must be cooked enough
> at least for 'next', and can reasonably be expected to graduate while
> we iterate on the new topic that is being built).

I typically try and do the same, but I didn't want to base this topic on
top of tb/incremental-midx-part-2, since that topic isn't mature enough
and I didn't want to hold this one hostage as a result.

I forgot that the other topic was still being held in 'seen'; I should
have remembered and mentioned the conflict in the patch earlier. Sorry
again for the trouble :-<.

Thanks,
Taylor

      reply	other threads:[~2024-12-19  1:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 19:20 [PATCH] pack-bitmap.c: ensure pack validity for all reuse packs Taylor Blau
2024-12-18 12:33 ` Jeff King
2024-12-18 19:41 ` Junio C Hamano
2024-12-18 23:49   ` Taylor Blau
2024-12-19  1:16     ` Junio C Hamano
2024-12-19  1:31       ` Taylor Blau [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z2N3WkMj34ACPEoy@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.