The old error message "cannot use revision REV as base, result would have 3
parents" is confusing - why use REV as base? why add a new parent?.
This patch changes it to "cannot move parent", which seems better.
martinvonz |
hg-reviewers |
The old error message "cannot use revision REV as base, result would have 3
parents" is confusing - why use REV as base? why add a new parent?.
This patch changes it to "cannot move parent", which seems better.
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
hgext/rebase.py | ||
---|---|---|
1087–1096 | I feel like "Cannot rebase merge commit %d without rebasing at least one its parents" would be more specific and still be accurate. It would be nice if we could detect the case upfront, but if we determine the destination dynamically including looking at obsmarkers, that may be difficult |
hgext/rebase.py | ||
---|---|---|
1087–1096 | I like the new error message. Will change. A dry-run of rebase is not feasible until we have in-memory DAG operations, which is one of my future interests. |
I guess the old error message was intended for the below case:
$ hg debugdrawdag <<'EOF' > H > /| > D F > | |\ > C E G > \|/ > B Z > |/ > A > EOF $ hg rebase -d Z -r 'C+E+G+H'
Removing D, having C connected to H directly is another interesting case. I think adjustdest could be changed to detect that situation (when adjusting H's destination considering its parent F, there are multiple candidates - E and G that may worth a warning or an error. Things could be more fun if E and G has obsolete or ancestor relationship).
I feel like "Cannot rebase merge commit %d without rebasing at least one its parents" would be more specific and still be accurate.
It would be nice if we could detect the case upfront, but if we determine the destination dynamically including looking at obsmarkers, that may be difficult