mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 09:17:30 +03:00
af8ecd5f80
Summary: Rewriting a set of commits where there are replacement relationship among the commits do not have an optimal UX today. For example, `rebase -s A -d Z` or `metaedit A` in the below graph. B1, B2, C will all be replaced. But the new B1 and B2 replacement won't have the B1 -> B2 relationship, and the "new B1" appears to be revived. ``` o C | x B1 (amended as B2) | | o B2 |/ o A o Z ``` One solution is to avoid rebasing `obsolete()::`, as implemented in D7067121 for metaedit. That would result in ``` o C | x B1 (amended as B2) o new B2 | | x A o new A ``` The stack of A, B1, C is forced to break into two parts. This is fine for power users. But n00b users would wonder why C is left behind. Per discussion with simpkins at an internal post about the metaedit case, we think a more linear history is more user-friendly. That is: ``` o new C | x new B1 (amended as *new* B2) | | o new B2 |/ o new A ``` The stack stays in a same shape. This diff implements the "copying obsmarkers" behavior at the "createmarkers" level so everything using that API would get the feature for free, including metaedit and rebase. D7067121 is reverted since the new UX is preferred. The test added is for `metaedit` command, changes to rebase will be added in a later patch. Differential Revision: D7121487 fbshipit-source-id: fd3c8a96ab434b131fb86d9882ccbdff8f63f05e |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| common.py | ||
| fold.py | ||
| hiddenoverride.py | ||
| hide.py | ||
| metaedit.py | ||
| movement.py | ||
| prune.py | ||
| restack.py | ||
| revsets.py | ||
| split.py | ||
| unamend.py | ||