From: Toon Claes <toon@iotcl.com>
To: Tian Yuchen <cat@malon.dev>, git@vger.kernel.org
Cc: Justin Tobler <jltobler@gmail.com>,
Siddharth Asthana <siddharthasthana31@gmail.com>,
Yee Cheng Chin <yeecheng.chin@gmail.com>
Subject: Re: [PATCH 3/3] replay: allow to specify a ref with option --ref
Date: Wed, 25 Mar 2026 13:50:06 +0100 [thread overview]
Message-ID: <87h5q413b5.fsf@iotcl.com> (raw)
In-Reply-To: <b0d49276-a9d3-435d-bb39-8cf7a08fbd11@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> Hi Toon,
>
> On 3/24/26 00:09, Toon Claes wrote:
>
>
>> + die_for_incompatible_opt2(!!opts.ref, "--ref",
>> + !!opts.contained, "--contained");
>
>> + /*
>> + * Reference to update with the result of the replay. This stops replay
>> + * from taking refs from `onto`, `advance`, and `revert`. Ignores
>> + * `contained`.
>> + */
>> + const char *ref;
>> +
>
> Do the comment and the code implementation match up here?
The comment is a bit misleading. A user cannot set the field `contained`
in the struct when it passed `--ref`. But if a bug is made somewhere,
but both fields can be set, that's what the comment is saying.
I can add a check to verify in replay.c that not both are set, and
update the comment they are incompatible?
>> @@ -427,13 +446,9 @@ int replay_revisions(struct rev_info *revs,
>> goto out;
>> }
>>
>> - /* In --advance or --revert mode, update the target ref */
>> - if (advance || revert) {
>> - const char *ref = advance ? advance : revert;
>> - replay_result_queue_update(out, ref,
>> - &onto->object.oid,
>> + if (ref)
>> + replay_result_queue_update(out, ref, &old_oid,
>> &last_commit->object.oid);
>> - }
>>
>> ret = 0;
>
> It doesn't seem like there's anything here to prevent users from
> inputting multiple branches? I think this will result in at least one
> branch becoming orphaned, without any error being reported.
>
> Consider this command:
>
> git replay --onto main --ref refs/heads/target topic1 topic2
That's interesting, I didn't think of that.
>
> In replay.c we have:
>
>> if (onto_name) {
>> *onto = peel_committish(repo, onto_name, "--onto");
>> if (rinfo.positive_refexprs <
>> strset_get_size(&rinfo.positive_refs))
>> die(_("all positive revisions given must be references"));
>> *update_refs = xcalloc(1, sizeof(**update_refs));
>> **update_refs = rinfo.positive_refs;
>> memset(&rinfo.positive_refs, 0, sizeof(**update_refs));
>
>
> After topic1 and topic2 are put into update_refs, only one ref
> (refs/heads/target) is updated, since what is written in the patch is:
>
> > + if (ref)
> > + replay_result_queue_update(out, ref, &old_oid,
> > &last_commit->object.oid);
>
> I believe this is not what we expect :P
Let me look into that how we can deal with that.
--
Cheers,
Toon
next prev parent reply other threads:[~2026-03-25 12:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 16:09 [PATCH 0/3] Add option --ref to git-replay(1) Toon Claes
2026-03-23 16:09 ` [PATCH 1/3] t3650: use option with value consistenly with equal sign Toon Claes
2026-03-23 19:17 ` Kristoffer Haugsbakk
2026-03-23 20:06 ` Junio C Hamano
2026-03-25 12:43 ` Toon Claes
2026-03-23 16:09 ` [PATCH 2/3] builtin/replay: improve documentation on options Toon Claes
2026-03-23 16:09 ` [PATCH 3/3] replay: allow to specify a ref with option --ref Toon Claes
2026-03-23 18:01 ` Tian Yuchen
2026-03-25 12:50 ` Toon Claes [this message]
2026-03-23 19:07 ` Kristoffer Haugsbakk
2026-03-25 12:49 ` Toon Claes
2026-03-25 15:59 ` [PATCH v2 0/3] Add option --ref to git-replay(1) Toon Claes
2026-03-25 15:59 ` [PATCH v2 1/3] builtin/replay: mark options as not negatable Toon Claes
2026-03-25 15:59 ` [PATCH v2 2/3] replay: use stuck form in documentation and help message Toon Claes
2026-03-25 15:59 ` [PATCH v2 3/3] replay: allow to specify a ref with option --ref Toon Claes
2026-03-25 18:44 ` Junio C Hamano
2026-03-31 7:56 ` Toon Claes
2026-03-25 18:34 ` [PATCH v2 0/3] Add option --ref to git-replay(1) Junio C Hamano
2026-03-26 21:20 ` Junio C Hamano
2026-03-31 7:55 ` Toon Claes
2026-03-31 21:42 ` Junio C Hamano
2026-04-01 20:55 ` [PATCH v3 " Toon Claes
2026-04-01 20:55 ` [PATCH v3 1/3] builtin/replay: mark options as not negatable Toon Claes
2026-04-01 20:55 ` [PATCH v3 2/3] replay: use stuck form in documentation and help message Toon Claes
2026-04-01 20:55 ` [PATCH v3 3/3] replay: allow to specify a ref with option --ref Toon Claes
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=87h5q413b5.fsf@iotcl.com \
--to=toon@iotcl.com \
--cc=cat@malon.dev \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=siddharthasthana31@gmail.com \
--cc=yeecheng.chin@gmail.com \
/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.