mirror of
https://github.com/martinvonz/jj.git
synced 2024-10-27 00:51:35 +00:00
3967f637dc
This follows up on @matts1 's #2609. We still allow the `-r` commit to become empty. I would be more comfortable if there was a test for that, but I haven't done that (yet?) and it seems pretty safe. If that's a problem, I'm happy to forbid `-r --skip-empty` entirely, since it is far less useful than `-s --skip-empty` or `-b --skip-empty`. I think it is undesired to abandon emptied descendants. As far as descendants of `A` are concerned, `jj rebase -r A` should be equivalent to `jj abandon A`, and `jj abandon` does not remove emptied commits. It also doesn't seem very useful to do that, since I think descendant commits of an abandoned (or moved with `-r`) commit only become empty in pathological cases. Additionally, if we did want -r to empty descendants of `A`, we'd have to add thorough tests and possibly improve the algorithm. I want to refactor `rebase -r` and add features to it, and having to consider cases of commits becoming abandoned makes everything harder. For example, if we have ``` root -> A -> B -> C ``` and `jj rebase -r A -d C` empties commit `B` (or `C`), I do not know whether the current algorithm will work correctly. It seems possible that it would, but that depends on the fact that empty merge commits are not abandoned for descendants. That seems dangerous to rely on without tests. I hope (but can't promise) that in the near future, making DescendantRebaser return more information should help make it possible to create such functionality in a more robust way. I am likely to attempt this as part of implementing `-r --after`. |
||
|---|---|---|
| .. | ||
| benches | ||
| gen-protos | ||
| src | ||
| tests | ||
| testutils | ||
| Cargo.toml | ||
| LICENSE | ||