Before this patch, if we try to hg prune (without any successors) an
already obsoleted cset which has at least one successor, it would false
warn about new content-divergence. As we know, pruning cset without any
successors can not create any divergence.
Details
- Reviewers
martinvonz marmoute Alphare - Group Reviewers
hg-reviewers - Commits
- rHGd4752aeb20f1: precheck: fix false warning about content-divergence creation
Diff Detail
- Repository
- rHG Mercurial
- Branch
- stable
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
mercurial/rewriteutil.py | ||
---|---|---|
92 | Depending on action seems ugly. What if I create my own hg pare command with similar behavior, then I still need to pass "prune" here and my users would see that in error messages? Also successors is used only here... Can we simply pass a check_divergence=True instead? |
mercurial/rewriteutil.py | ||
---|---|---|
92 | I agree with martin that we should not use the action here. The actions are purely here to provides some information to the users, and shouldn't be used for logic. |
β
refresh by Heptapod after a successful CI run (π π)
β This patch is intended for stable β
β
refresh by Heptapod after a successful CI run (π π)
β This patch is intended for stable β
I'm assuming that the callers that would use check_divergence=False exist in evolve? This patch does not introduce any such calls.
Correct. There's no prune or similar command in core: everything that uses precheck() creates successors for revs (which can potentially diverge). So the only user would be prune command in evolve.
If the histedit discussion finds something that needs to be adjusted there, it can be resolved in a separate patch
What happens in histedit is it calls precheck() for all revisions in the stack, with no easy way to see what operations are planned for each changeset. To be able to use check_divergence=False only for some changesets (that are going to be dropped), we could iterate over the stack and call precheck() for every revision separately, somewhere where we know the planned operation. I can't think of anything better right now.
Having check_divergence keyword argument still works for that case, so this patch should be okay to land.
Depending on action seems ugly. What if I create my own hg pare command with similar behavior, then I still need to pass "prune" here and my users would see that in error messages? Also successors is used only here... Can we simply pass a check_divergence=True instead?