summaryrefslogtreecommitdiffstats
path: root/contrib/persistent-https
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2026-01-13 10:54:35 +0100
committerJunio C Hamano <gitster@pobox.com>2026-01-13 05:41:16 -0800
commit5425771568ee286ed7ee848b8886cfdc98806b7a (patch)
tree2f22bd2f1930d1b09286f2b5b99ed23a652b1e6e /contrib/persistent-https
parent410e3780602a5da36a91d7456daf8b1427d80318 (diff)
downloadgit-5425771568ee286ed7ee848b8886cfdc98806b7a.tar.gz
git-5425771568ee286ed7ee848b8886cfdc98806b7a.zip
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>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions