From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Han Jiang <jhcarl0814@gmail.com>,
Justin Tobler <jltobler@gmail.com>,
Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH v2 0/6] builtin/remote: rework how remote refs get renamed
Date: Mon, 4 Aug 2025 08:51:32 +0200 [thread overview]
Message-ID: <aJBYdBqmPtfS-ocR@pks.im> (raw)
In-Reply-To: <xmqqpldfm1ps.fsf@gitster.g>
On Fri, Aug 01, 2025 at 09:43:59AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > On Thu, Jul 31, 2025 at 12:15:42PM -0700, Junio C Hamano wrote:
> >> Patrick Steinhardt <ps@pks.im> writes:
> >>
> >> > The series is built on top of e4ef0485fd7 (The fourteenth batch,
> >> > 2025-07-24) with ps/reflog-migrate-fixes at de7cc0782a7 (refs: fix
> >> > invalid old object IDs when migrating reflogs, 2025-07-25) merged into
> >> > it.
> >>
> >> I'll use the newer iteration of the other topic that ends at
> >> f0fde561 (refs: fix invalid old object IDs when migrating reflogs,
> >> 2025-07-29) instead; that was what was used in the version in 'seen'.
> >
> > Okay, makes sense. I'll adapt my local base to match then.
>
> Curious. You had sent v3 but based your other topic on v2 and
> expected the result will merge well?
Well, the only reason why this series depends on the migration fixes for
reflogs is that the renamed reflogs for a remote would have invalid old
object IDs without it. We basically hit the bug that this other series
aims to fix.
There shouldn't be any textual conflicts between these two series.
Patrick
next prev parent reply other threads:[~2025-08-04 6:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 13:08 [PATCH 0/4] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-07-28 13:08 ` [PATCH 1/4] refs: pass refname when invoking reflog entry callback Patrick Steinhardt
2025-07-28 15:59 ` Justin Tobler
2025-07-28 16:07 ` Junio C Hamano
2025-07-29 20:30 ` Karthik Nayak
2025-07-31 8:28 ` Patrick Steinhardt
2025-07-28 13:08 ` [PATCH 2/4] refs: simplify logic when migrating reflog entries Patrick Steinhardt
2025-07-28 16:08 ` Justin Tobler
2025-07-28 16:21 ` Junio C Hamano
2025-07-28 13:08 ` [PATCH 3/4] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-07-28 17:19 ` Junio C Hamano
2025-07-29 8:43 ` Patrick Steinhardt
2025-07-28 18:47 ` Justin Tobler
2025-07-28 18:57 ` Junio C Hamano
2025-07-29 8:43 ` Patrick Steinhardt
2025-07-29 8:16 ` Jeff King
2025-07-29 12:24 ` Patrick Steinhardt
2025-08-02 10:48 ` Jeff King
2025-07-28 13:08 ` [PATCH 4/4] builtin/remote: only iterate through refs that are to be renamed Patrick Steinhardt
2025-07-28 17:43 ` Junio C Hamano
2025-07-30 7:53 ` Karthik Nayak
2025-07-31 8:28 ` Patrick Steinhardt
2025-07-28 15:43 ` [PATCH 0/4] builtin/remote: rework how remote refs get renamed Junio C Hamano
2025-07-31 14:56 ` [PATCH v2 0/6] " Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 1/6] refs: pass refname when invoking reflog entry callback Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 2/6] refs: simplify logic when migrating reflog entries Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 3/6] builtin/remote: fix sign comparison warnings Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 4/6] builtin/remote: determine whether refs need renaming early on Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 5/6] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-08-02 10:45 ` Jeff King
2025-08-04 6:54 ` Patrick Steinhardt
2025-07-31 14:56 ` [PATCH v2 6/6] builtin/remote: only iterate through refs that are to be renamed Patrick Steinhardt
2025-07-31 19:15 ` [PATCH v2 0/6] builtin/remote: rework how remote refs get renamed Junio C Hamano
2025-08-01 4:59 ` Patrick Steinhardt
2025-08-01 16:43 ` Junio C Hamano
2025-08-04 6:51 ` Patrick Steinhardt [this message]
2025-08-04 18:24 ` Junio C Hamano
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=aJBYdBqmPtfS-ocR@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jhcarl0814@gmail.com \
--cc=jltobler@gmail.com \
--cc=karthik.188@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.
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 NNTP newsgroup(s).