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
28facd7ed5
sapling/tests/test-fbamend-nextrebase.t

425 lines
8.0 KiB
Perl
Raw Normal View History

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]
fbamend: move to a package Summary: `fbamend.py` is already long. It will become more complex so let's move it. Test Plan: arc unit Reviewers: #mercurial, ikostia Reviewed By: ikostia Differential Revision: https://phabricator.intern.facebook.com/D5209475 Signature: t1:5209475:1497260957:e84aec4a2f90c8dd1d247b2b0caef48cfbb59c55
2017-06-14 03:08:20 +03:00
> fbamend=$TESTDIR/../hgext3rd/fbamend
codemod: use vendored directaccess and inhibit extension in tests Summary: This diff makes the tests use the vendored directaccess and inhibit instead the foreign ones. Test Plan: arc unit Reviewers: #mercurial, sid0 Reviewed By: sid0 Subscribers: mjpieters Differential Revision: https://phabricator.intern.facebook.com/D5142981 Signature: t1:5142981:1496173851:3a8f3a1c689711dbef517c893bf72c90ab144761
2017-05-30 22:56:40 +03:00
> inhibit=$TESTDIR/../hgext3rd/inhibit.py
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=
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
> [fbamend]
> userestack=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
> [experimental]
allowunstable: remove from tests The extension was removed so the test needs update. It wasn't discovered because the system `allowunstable` was used. `check-code` logic will be updated to make it harder to use system extensions.
2017-06-17 07:33:17 +03:00
> evolution = createmarkers, allowunstable
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]
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 single changeset.
$ hg debugbuilddag -n +4
$ hg up 1
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg amend -m "amended"
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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:776c07fa2b12 "r2"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[fe8ffc] 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
rebasing 3:137d867d71d5 "r3"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[7d603c] r3
$ 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
$ hg amend -m "amended"
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:776c07fa2b12 "r2"
rebasing 3:137d867d71d5 "r3"
rebasing 4:daa37004f338 "r4"
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
[55b98e] 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
$ hg amend -m "amended"
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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:776c07fa2b12 "r2"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[fe8ffc] r2
$ hg next --rebase
rebasing 3:137d867d71d5 "r3"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[7d603c] 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
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 4:daa37004f338 "r4"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[55b98e] r4
$ 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
$ hg amend -m "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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:776c07fa2b12 "r2"
rebasing 3:137d867d71d5 "r3"
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
[7d603c] 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
rebasing 4:daa37004f338 "r4"
rebasing 5:5f333e6f7274 "r5"
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
[c01a35] r5
$ 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
$ hg amend -m "amend 1"
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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:776c07fa2b12 "r2"
rebasing 3:137d867d71d5 "r3"
rebasing 4:daa37004f338 "r4"
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
[66772e] 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
$ hg amend -m "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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 3:137d867d71d5 "r3"
rebasing 4:daa37004f338 "r4"
rebasing 5:5f333e6f7274 "r5"
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
[bd05f8] r5
$ 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
$ hg amend -m "amended"
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
[dc00ac] 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
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 2:776c07fa2b12 "r2"
changeset dc00accb61d3 has multiple children, namely:
[fe8ffc] r2
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
[4e13d3] 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
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
$ hg amend -m "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
warning: the changeset's children were left behind
fbamend: change hint text to suggest running `restack` Summary: Instead of referencing `hg rebase` --restack option, just reference the `restack` subcommand. Test Plan: 1. Make a few commits 1, 2, 3, 4 on any branch 2. `hg update 1` 3. Try to amend commit 1 4. Warning message should appear about children left behind expected: Hint text does not mention `hg rebase --restack` Reviewers: durham, kulshrax Reviewed By: kulshrax Subscribers: medson, mjpieters, kkrewink Differential Revision: https://phabricator.intern.facebook.com/D5313108 Tasks: 19601780 Signature: t1:5313108:1498249314:98f31f4424341ef51997687293bf99b7297b6cd0
2017-06-26 17:31:28 +03:00
(use 'hg restack' to rebase them)
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
rebasing 2:4538525df7e2 "add c"
merging c
warning: 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
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 2: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
Reference in New Issue Copy Permalink