facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-09 08:18:15 +03:00
Code Issues Projects Releases Wiki Activity
2f15f80957
sapling/eden/scm/tests/test-amend-nextrebase.t

505 lines
10 KiB
Perl
Raw Normal View History

tests: enable chg for 572 tests Summary: Add `#chg-compatible` to 572 tests that seem to pass with chg enabled. This should make them run faster. Reviewed By: xavierd Differential Revision: D18870507 fbshipit-source-id: fe895e733efffc9286cd3d17c7a156c803124395
2019-12-10 02:24:31 +03:00
#chg-compatible
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
Set up test environment.
$ cat >> $HGRCPATH << EOF
> [extensions]
amend: replace with the fbamend extension Summary: The functionality we care about is provided by the `fbamend` extension. Therefore, lets replace the `amend` extension with the `fbamend` extension. Reviewed By: farnz Differential Revision: D10320739 fbshipit-source-id: 5700d39f488777fcc4033f60ce0a51cda15ef2ad
2018-10-11 16:55:19 +03:00
> amend=
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
> rebase=
> [experimental]
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
> evolution=
> [mutation]
> record=true
> enabled=true
> date=0 0
> [visibility]
> enabled=true
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
> EOF
$ mkcommit() {
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
> echo "$1" > "$1"
> hg add "$1"
> echo "add $1" > msg
> hg ci -l msg
> }
$ reset() {
> cd ..
> rm -rf nextrebase
> hg init nextrebase
> cd nextrebase
> }
$ showgraph() {
> hg log --graph -T "{rev} {desc|firstline}"
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
> }
$ hg init nextrebase && cd nextrebase
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Cannot --rebase and --merge.
$ hg next --rebase --merge
abort: cannot use both --merge and --rebase
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
[255]
test the "hg next" behaviour in case of obs/non-obs ambiguity Summary: The next commit introduces a heurestic to resolve those. Reviewed By: zertosh Differential Revision: D14560585 fbshipit-source-id: b62b59e4b254e59e88cfc7859aa21feffc360b05
2019-03-22 13:35:53 +03:00
Build dag with instablility
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg debugbuilddag -n +4
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
test the "hg next" behaviour in case of obs/non-obs ambiguity Summary: The next commit introduces a heurestic to resolve those. Reviewed By: zertosh Differential Revision: D14560585 fbshipit-source-id: b62b59e4b254e59e88cfc7859aa21feffc360b05
2019-03-22 13:35:53 +03:00
Check the next behaviour in case of ambiguity between obsolete and non-obsolete
$ showgraph
@ 4 amended
|
| o 3 r3
| |
| o 2 r2
| |
| x 1 r1
|/
o 0 r0
$ hg prev
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
[612462] r0
$ hg next
changeset 61246295ee1e has multiple children, namely:
[e8ec16] r1
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f03405] amended
choosing the only non-obsolete child: f03405deb52b
test the "hg next" behaviour in case of obs/non-obs ambiguity Summary: The next commit introduces a heurestic to resolve those. Reviewed By: zertosh Differential Revision: D14560585 fbshipit-source-id: b62b59e4b254e59e88cfc7859aa21feffc360b05
2019-03-22 13:35:53 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f03405] amended
test the "hg next" behaviour in case of obs/non-obs ambiguity Summary: The next commit introduces a heurestic to resolve those. Reviewed By: zertosh Differential Revision: D14560585 fbshipit-source-id: b62b59e4b254e59e88cfc7859aa21feffc360b05
2019-03-22 13:35:53 +03:00
Rebasing single changeset.
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next
abort: current changeset has no children
[255]
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[8fb200] r2
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 5 r2
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 4 amended
|
| o 3 r3
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 2 r2
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 0 r0
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
fbamend: add --clean flag to hg prev/next Summary: This patch adds a `--clean` flag to `hg prev` and `next` that discards any pending changes, similar to `hg update --clean`. Test Plan: See included test changes. Reviewers: #fbhgext Differential Revision: https://phab.mercurial-scm.org/D140
2017-07-19 06:13:25 +03:00
Test --clean flag.
$ touch foo
$ hg add foo
$ hg status
A foo
$ hg next --rebase
abort: uncommitted changes
(use --clean to discard uncommitted changes or --merge to bring them along)
[255]
$ hg next --rebase --clean
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 137d867d71d5 "r3"
fbamend: add --clean flag to hg prev/next Summary: This patch adds a `--clean` flag to `hg prev` and `next` that discards any pending changes, similar to `hg update --clean`. Test Plan: See included test changes. Reviewers: #fbhgext Differential Revision: https://phab.mercurial-scm.org/D140
2017-07-19 06:13:25 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f12433] r3
fbamend: add --clean flag to hg prev/next Summary: This patch adds a `--clean` flag to `hg prev` and `next` that discards any pending changes, similar to `hg update --clean`. Test Plan: See included test changes. Reviewers: #fbhgext Differential Revision: https://phab.mercurial-scm.org/D140
2017-07-19 06:13:25 +03:00
$ hg status
? foo
$ showgraph
@ 6 r3
|
o 5 r2
|
o 4 amended
|
o 0 r0
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Rebasing multiple changesets at once.
$ reset
$ hg debugbuilddag -n +5
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase --top
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
rebasing 137d867d71d5 "r3"
rebasing daa37004f338 "r4"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[d25685] r4
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 8 r4
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 7 r3
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 6 r2
|
o 5 amended
|
o 0 r0
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Rebasing a stack one changeset at a time.
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ reset
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg debugbuilddag -n +5
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[8fb200] r2
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 137d867d71d5 "r3"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f12433] r3
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 7 r3
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 6 r2
|
o 5 amended
|
| o 4 r4
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 3 r3
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 2 r2
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 0 r0
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing daa37004f338 "r4"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[d25685] r4
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ showgraph
@ 8 r4
|
o 7 r3
|
o 6 r2
|
o 5 amended
|
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Rebasing a stack two changesets at a time.
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ reset
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg debugbuilddag -n +6
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase 2
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
rebasing 137d867d71d5 "r3"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f12433] r3
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 8 r3
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 7 r2
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 6 amended
|
| o 5 r5
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 4 r4
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 3 r3
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 2 r2
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 0 r0
$ hg next --rebase 2
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing daa37004f338 "r4"
rebasing 5f333e6f7274 "r5"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[dd153e] r5
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ showgraph
@ 10 r5
|
o 9 r4
|
o 8 r3
|
o 7 r2
|
o 6 amended
|
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Rebasing after multiple amends.
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ reset
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg debugbuilddag -n +5
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amend 1" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg amend -m "amend 2"
$ hg amend -m "amend 3"
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 7 amend 3
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 4 r4
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 3 r3
| |
| o 2 r2
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase --top
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
rebasing 137d867d71d5 "r3"
rebasing daa37004f338 "r4"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[5d31c6] r4
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 10 r4
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 9 r3
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 8 r2
|
o 7 amend 3
|
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Rebasing from below the amended changeset with the --newest flag.
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ reset
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg debugbuilddag -n +6
$ hg up 2
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of 776c07fa2b12 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg up 0
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 6 amended
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 5 r5
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 4 r4
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 3 r3
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 2 r2
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 1 r1
|
@ 0 r0
$ hg next --rebase --top --newest
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 137d867d71d5 "r3"
rebasing daa37004f338 "r4"
rebasing 5f333e6f7274 "r5"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[2d8122] r5
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ showgraph
@ 9 r5
|
o 8 r4
|
o 7 r3
|
o 6 amended
|
o 1 r1
|
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Test aborting due to ambiguity caused by a rebase. The rebase should be
rolled back and the final state should be as it was before `hg next --rebase`.
$ reset
$ hg debugbuilddag -n +6
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ mkcommit a
$ hg prev
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[f03405] amended
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 7 add a
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 6 amended
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 5 r5
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 4 r4
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
| |
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 3 r3
| |
| o 2 r2
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 0 r0
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
changeset f03405deb52b has multiple children, namely:
[c9239a] add a
[8fb200] r2
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
transaction abort!
rollback completed
abort: ambiguous next changeset
fbamend: add --towards flag to hg next Summary: This diff adds a `--towards` flag to `hg next`. This flag tells `hg next` to always proceed in a linear fashion towards the specified commit. This is useful in situations where the user has a very branchy stack. For example, if the user has a local stack with several branches, each with a feature bookmark at the top, if the user wants to go up a particular stack they can do so with something like `hg next 3 --towards bookmark`. Test Plan: Here is an example of basic usage. Also see test file. ``` $ hg debugbuilddag "+5 *2 +2" $ hg book -r 4 feature1 $ hg book -r 7 feature2 $ hg up 0 $ hg sl o 92eaf3 debugbuilddag feature2 | r7 | o 8bbe84 debugbuilddag | r6 | o 914970 debugbuilddag | r5 | | o bebd16 debugbuilddag feature1 | | r4 | | | o 2dc09a debugbuilddag | | r3 | | | o 012414 debugbuilddag |/ r2 | o 66f7d4 debugbuilddag | r1 | @ 1ea734 debugbuilddag r0 $ hg next 3 --towards feature1 0 files updated, 0 files merged, 0 files removed, 0 files unresolved [2dc09a] r3 $ hg sl o 92eaf3 debugbuilddag feature2 | r7 | o 8bbe84 debugbuilddag | r6 | o 914970 debugbuilddag | r5 | | o bebd16 debugbuilddag feature1 | | r4 | | | @ 2dc09a debugbuilddag | | r3 | | | o 012414 debugbuilddag |/ r2 | o 66f7d4 debugbuilddag | r1 | o 1ea734 debugbuilddag r0 ``` Reviewers: #mercurial, simonfar Reviewed By: simonfar Subscribers: simonfar, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4695861 Signature: t1:4695861:1489325959:1145a29ba87f99d07ede1e81415804723dc48818
2017-03-12 20:09:12 +03:00
(use the --newest or --towards flags to specify which child to pick)
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
[255]
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
o 7 add a
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
@ 6 amended
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 5 r5
| |
| o 4 r4
| |
| o 3 r3
| |
| o 2 r2
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 r1
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
|/
o 0 r0
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Test a situation where there is a conflict.
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ reset
$ mkcommit a
$ mkcommit b
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ mkcommit c
$ mkcommit d
$ hg up 1
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ echo "conflict" > c
$ hg add c
fbamend: autorestack children for simple rebases Today, if you run 'hg amend' while in the middle of a stack of commits, it amends the commit and leaves the top of the stack behind. Users then have to run 'hg amend --restack' or 'hg restack' to bring the old top of the stack onto the new version of the commit. Add heuristic code so that an automatic restack can be performed if amending a commit did not change its manifest, nor did it leave behind a dirty working copy. This optimization can be avoided by providing the --no-rebase commandline option. Fix the existing tests that relied on the previous behaviour (so their original intent is kept), and add new ones to cover the new heuristic. Differential Revision: https://phab.mercurial-scm.org/D1784
2017-12-28 09:54:03 +03:00
$ hg amend -m "amended to add c" --no-rebase
amend: use hint framework for restack Summary: This allows people to silence the hint. Reviewed By: markbt Differential Revision: D7392127 fbshipit-source-id: ac16f952a178d567ce13e22946127456972ebe85
2018-04-07 10:36:52 +03:00
hint[amend-restack]: descendants of 7c3bad9141dc are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
amend: fixing tests following the removal of redundant commit in amend Summary: cmdutil.amend was changed recently to get rid of the redundant commit during the amend operation. As a result, we need to update the tests which were aware of the redundant commit. This commit achieves the same. Note that as a result of the amend behavior change, the dirsync and copytrace extensions were broken. They will be be fixed in subsequent commits on top of this commit. For now, the broken tests for these extensions were removed from the commit. Eventually, I will fold all the fixes together so that revision history of the tests is not messed up. This is primarily done only to aid the review. Test Plan: Ran the test suite after updating the tests.
2017-09-08 19:58:14 +03:00
@ 4 amended to add c
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 3 add d
| |
| o 2 add c
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 add b
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
o 0 add a
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ hg next --rebase --top
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 4538525df7e2 "add c"
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
merging c
filemerge: add number of textual conflicts in each file to error message Summary: When you get an error, let's print the number of conflicts in each file. This will give the user some sense of how much work they have to do. The code change is entirely in `filemerge.py`, and `tests/test-merge-conflict-count.t` adds a new test. Reviewed By: quark-zju Differential Revision: D9815243 fbshipit-source-id: 1b73a1db293902ac7242997a7d6ae09478344068
2018-10-22 22:45:46 +03:00
warning: 1 conflicts while merging c! (edit, then use 'hg resolve --mark')
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
$ showgraph
amend: fixing tests following the removal of redundant commit in amend Summary: cmdutil.amend was changed recently to get rid of the redundant commit during the amend operation. As a result, we need to update the tests which were aware of the redundant commit. This commit achieves the same. Note that as a result of the amend behavior change, the dirsync and copytrace extensions were broken. They will be be fixed in subsequent commits on top of this commit. For now, the broken tests for these extensions were removed from the commit. Eventually, I will fold all the fixes together so that revision history of the tests is not messed up. This is primarily done only to aid the review. Test Plan: Ran the test suite after updating the tests.
2017-09-08 19:58:14 +03:00
@ 4 amended to add c
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
|
| o 3 add d
| |
| @ 2 add c
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 add b
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
|/
o 0 add a
In this mid-rebase state, we can't use `hg previous` or `hg next`:
$ hg previous
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
abort: rebase in progress
(use 'hg rebase --continue' or 'hg rebase --abort')
[255]
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
Now resolve the conflict and resume the rebase.
$ rm c
$ echo "resolved" > c
$ hg resolve --mark c
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
(no more unresolved files)
continue: hg rebase --continue
$ hg rebase --continue
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 4538525df7e2 "add c"
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
$ showgraph
amend: fixing tests following the removal of redundant commit in amend Summary: cmdutil.amend was changed recently to get rid of the redundant commit during the amend operation. As a result, we need to update the tests which were aware of the redundant commit. This commit achieves the same. Note that as a result of the amend behavior change, the dirsync and copytrace extensions were broken. They will be be fixed in subsequent commits on top of this commit. For now, the broken tests for these extensions were removed from the commit. Eventually, I will fold all the fixes together so that revision history of the tests is not messed up. This is primarily done only to aid the review. Test Plan: Ran the test suite after updating the tests.
2017-09-08 19:58:14 +03:00
o 5 add c
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|
amend: fixing tests following the removal of redundant commit in amend Summary: cmdutil.amend was changed recently to get rid of the redundant commit during the amend operation. As a result, we need to update the tests which were aware of the redundant commit. This commit achieves the same. Note that as a result of the amend behavior change, the dirsync and copytrace extensions were broken. They will be be fixed in subsequent commits on top of this commit. For now, the broken tests for these extensions were removed from the commit. Eventually, I will fold all the fixes together so that revision history of the tests is not messed up. This is primarily done only to aid the review. Test Plan: Ran the test suite after updating the tests.
2017-09-08 19:58:14 +03:00
@ 4 amended to add c
Make hg next --rebase intelligently obsolete/inhibit changesets Summary: This change updates the behavior hg next --rebase. Specifically: - Only one changeset can be rebased at a time. If there are multiple candidate changesets, the command aborts. - Each time a changeset is rebased, its precursor is marked as obsolete, inhibition markers are stripped from it and its ancestors, and its preamend bookmark is deleted, if one exists. - The result of this is that if no non-obsolete changesets depend on the existence of the pre-rebased changeset, that changeset and its ancestors will be stripped, resulting in a cleaner user experience. - This change also adds back the --evolve flag, but makes it show in error instead of working. It turns out that removing the flag outright breaks the evolve extension. Test Plan: See updated unit tests for the exact commands to run to test this, as well as an overview of all of the new situations where behavior was changed. A basic test plan would be: 1. Initialize a new repository, and create a stack of 4 commits. 2. Amend the second commit in the stack. 3. Do `hg next --rebase`. It should work as before. 4. Do `hg next --rebase` again. This time, the entire old stack should "disappear" from hg sl. Additionally, attempting to run `hg next --rebase` when there are multiple possible child changesets should fail. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: quark, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D3941922 Tasks: 13570554 Signature: t1:3941922:1475205056:58a8d1726cfcccbf14a38727be0220a09532ec97
2016-09-30 20:40:58 +03:00
|
fbamend: add new implementations of `hg previous` and `hg next` Summary: This diff replaces the `hg previous` and `hg next` commands from the evolve extension with new implementations. The new commands have several features not found in evolve: - Users can now move by multiple commits at a time. Example: `hg next 3` - Users can move all the way to the top or bottom of the current stack with the following new flags: `hg next --top` and `hg prev --bottom` - Users can rebase child commits on demand with `hg next --rebase`. This flag can be combined with the others to specify exactly how many commits to rebase. Example: `hg next --rebase 4` (move 4 commits up the stack, rebasing as needed) `hg next --rebase --top` (rebase all the way to the top of the stack) - When a user lands on a particular commit, if there is a bookmark it will be automatically activated. The user can also move to the previous or next commit with a bookmark with the `--bookmark` flag. - The user can pass the `--newest` flag to resolve ambiguity in situations where history is nonlinear. With the flag the command will always choose the commit with the higher rev number at each step. - The commands now show commit hashes instead of rev numbers when showing the user what commit they landed on. Apologies in advance for the large diff. I've tried splitting it up as best as I could, but the unit tests introduced here significantly increase the size. I figured the unit tests should be part of this diff instead of being added in a separate one. This diff is almost entirely new code, so I hope that helps a little bit. Let me know if there's a better way to split this up. Test Plan: See the new unit tests for an extensive look at the new commands in action. Essentially, all of the features mentioned above should work as expected. Reviewers: quark, #sourcecontrol, durham Reviewed By: durham Subscribers: stash, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4121778 Tasks: 14119420 Signature: t1:4121778:1478774243:a7131593222bc329f541e77e1d3ebd8222e47e79
2016-11-16 05:46:56 +03:00
| o 3 add d
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 2 add c
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
| |
inhibit: update existing code to work with the rewritten version Summary: debuginhibit was removed since we no longer have a separate inhibit state. smartlog hack about changing "o" to "x" was removed since "obsolete()" revset is correct and the hack is unnecessary now. directaccess was removed from tests since inhibit does not depend on it. `- obsolete()` was added to some revsets to avoid divergence and other surprises. Use `inhibit.revive` API in infinitepush and reset to revive changesets properly. Remove various hacky code that mangle inhibit state in corner cases. Most test changes are `o` changed to `x` in output since we draw `obsolete()` state correctly now. `test-infinitepush-backup-remotefilelog.t` change was because output could be `bytes/sec` instead of `KB/sec`. Test Plan: arc unit Reviewers: #mercurial, kulshrax Reviewed By: kulshrax Subscribers: kulshrax, medson, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5391361 Signature: t1:5391361:1499722618:d3c1cf629f0c59ecdf1dfd5e653c1eb6176646b8
2017-07-11 01:45:31 +03:00
| x 1 add b
Add hg next --rebase Summary: This diff adds the --rebase option to the `hg next` command by extending the evolve extension in the fbamend extension. The --rebase option finds any child commits of the obsolete precursor to the current commit, and rebases them onto the current commit before performing `hg next`. This way, one can be in the middle of a stack of commits, amend one in the middle, and do `hg next` without running `hg amend --fixup`. The next commit will be correctly found, rebased, and updated to. This is equivalent to: hg rebase -d . -r "children(OLD_HASH)" -k && hg next Test Plan: I tested this command by hand and created some unit tests. The basic way to test it is: 1. `hg init` a new repository. 2. Create a chain of 3 commits. 3. Amend the 2nd commit. 4. Run `hg next --rebase` and confirm that the 3rd commit was rebased and switched to. The exact commands to do this are in tests/test-fbamend-nextrebase.t. This file also contains test cases in which there are multiple child commits on the precursor, and cases where there is a rebase conflict. Reviewers: #sourcecontrol, durham Reviewed By: durham Subscribers: mjpieters, nain Differential Revision: https://phabricator.intern.facebook.com/D3910568 Tasks: 13347995 Signature: t1:3910568:1474650102:8c7dd712afb9d36f29e1e73bb781e1d8e0870371
2016-09-23 20:39:36 +03:00
|/
o 0 add a
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
Rebase when other predecessors are still visible
$ reset
$ hg debugbuilddag -n +4
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg amend -m "amended 1" --no-rebase
hint[amend-restack]: descendants of e8ec16b776b6 are left behind - use 'hg restack' to rebase them
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing 776c07fa2b12 "r2"
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[bd2075] r2
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
$ hg prev
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
[80573e] amended 1
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
$ hg amend -m "amended 2" --no-rebase
mutation: convert test-amend-nextrebase to mutation and visibility Summary: Convert the test case `test-amend-nextrebase` to use new mutation and visibility tracking. In doing so, reveals a bug where `hg next --rebase` can rebase obsolete commits. Reviewed By: quark-zju Differential Revision: D17136483 fbshipit-source-id: dcda88d1e8c1f435d6211cf5b76791c5a76ee343
2019-09-02 13:12:07 +03:00
hint[amend-restack]: descendants of 80573e6618ae are left behind - use 'hg restack' to rebase them
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
hint[hint-ack]: use 'hg hint --ack amend-restack' to silence these hints
$ showgraph
@ 6 amended 2
|
| o 5 r2
| |
| x 4 amended 1
|/
| o 3 r3
| |
| x 2 r2
| |
| x 1 r1
|/
o 0 r0
$ hg next --rebase
rebase: remove rev number from rebase output Summary: Revision numbers are deprecated, let's not print them in the rebase output. The tests were automatically fixed with run-tests.py -i Reviewed By: quark-zju Differential Revision: D17936451 fbshipit-source-id: a8f0403b6af4573421ca874e9311f26931eba697
2019-10-16 02:28:01 +03:00
rebasing bd2075358087 "r2"
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
amend: do not rebase obsoleted commits for `next --rebase` Summary: I hit this when editing the dag stack. This resolves a "BUG" in the test-amend-nextrebase.t test. Reviewed By: singhsrb Differential Revision: D17357387 fbshipit-source-id: 309efe34dee71180abdbdb5a9fe2e7b731230051
2019-09-13 05:58:56 +03:00
[88a893] r2
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
$ showgraph
mutation: don't allow divergence when rebasing Summary: In general, mutation tracking doesn't care about divergence. However, in the case of rebase, it doesn't make sense to allow divergence to occur if we can avoid it by omitting some of the commits to rebase. This makes rebase behaviour more like old obsmarker-based behaviour. This breaks a test for mutation copying markers, so update those to use metaedit, which has the copying behaviour for both obsmarkers and mutation. At some point we should make rebase behave better in these cases. Reviewed By: quark-zju Differential Revision: D17136480 fbshipit-source-id: 9e465b7fc8bda33e7a746e4df68410713e2be37e
2019-09-02 13:12:07 +03:00
@ 7 r2
amend: add a test for next --rebase with visible predecessors Summary: Add a new test for `hg next --rebase` for when a predecessor of the commit being rebased is also visible. The predecessor should not be rebased. Reviewed By: quark-zju Differential Revision: D17136482 fbshipit-source-id: fa2c91ebc14c72f6a8c13c4549447809090489b3
2019-09-02 13:12:07 +03:00
|
o 6 amended 2
|
| o 3 r3
| |
| x 2 r2
| |
| x 1 r1
|/
o 0 r0
Reference in New Issue Copy Permalink