From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
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, 04 Aug 2025 11:24:22 -0700 [thread overview]
Message-ID: <xmqqa54f54ix.fsf@gitster.g> (raw)
In-Reply-To: <aJBYdBqmPtfS-ocR@pks.im> (Patrick Steinhardt's message of "Mon, 4 Aug 2025 08:51:32 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> There shouldn't be any textual conflicts between these two series.
What I meant was this. This series is built on top of an older
iteration of the other series. The other series however has a newer
iteration. We would eventually want to both topics in the system,
so as an early preview, both would be merged to 'seen'.
The topic branch for the other series has patches from iteration vN+1.
The topic branch for this series is, since it is built on top of the
merge of the other series at iteration vN into 'master'.
We merge the former into 'seen'; we now have patches from the other
series at iteration vN+1. We then merge the latter into 'seen'. It
wants to _also_ merge the patches from the other series at iteration
vN, that duplicates vN+1 but in different ways. If there wouldn't
be any textual conflicts between vN and vN+1 of the other series, it
may resolve cleanly, but is the result sane? These two iterations
are trying to be moral equivalents, with the difference that the
newer iteration is trying to be better than the older one.
And they in practice are most likely to textually conflict with each
other. After all they are different iteration of the same topic.
prev parent reply other threads:[~2025-08-04 18:24 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
2025-08-04 18:24 ` Junio C Hamano [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=xmqqa54f54ix.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jhcarl0814@gmail.com \
--cc=jltobler@gmail.com \
--cc=karthik.188@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 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).