@matheusbsbs / matheus-bagliano / commits / 5425771568

replay: support empty commit ranges

In a subsequent commit we're about to introduce a new user of the replay subsystem. With that new user, the range of commits that we'll want to replay will be identified implicitly via a single commit, and will include all descendants of that commit to any branch. If that commit has no descendants (because it's the tip of some branch), then the range of revisions that we're asked to replay becomes empty. This case does not make sense with git-replay(1), but with the new command it will. This case is not currently supported by `replay_revisions()` though because we zero-initialize `struct merge_result`. This includes its `.clean` member, which indicates whether the merge ran into a conflict or not. But given that we don't have any revision to replay, we won't ever perform any merge at all, and consequently that member will never be set to `1`. We thus later think that there's been a merge conflict and return an error from `replay_commits()`. Address this issue by initializing the `.clean` member to `1`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Patrick Steinhardt committed Jan 13, 2026 at 10:54 UTC 5425771568ee286ed7ee848b8886cfdc98806b7a

1 file changed +3 -2

replay.c

+3 -2

@@ -266,7 +266,9 @@ int replay_revisions(struct rev_info *revs,

266 struct commit *commit;

267 struct commit *onto = NULL;

268 struct merge_options merge_opt;

269 - struct merge_result result;

269 + struct merge_result result = {

270 + .clean = 1,

271 + };

272 char *advance;

273 int ret;

274

@@ -282,7 +284,6 @@ int replay_revisions(struct rev_info *revs,

284 }

285

286 init_basic_merge_options(&merge_opt, revs->repo);

285 - memset(&result, 0, sizeof(result));

287 merge_opt.show_rename_progress = 0;

288 last_commit = onto;

289 replayed_commits = kh_init_oid_map();