Summary:
If tracking was set up, 'hg push' was not invoking the pushrebase logic, like it
would if the user ran 'hg push --to master'.
This is required for us to unify all pushes through pushrebase, so we can move
the hooks out of the lock and into prepushrebase.
Test Plan: Added a test
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.fb.com/D2635253
Summary:
Previously the output just said "searching for changes" then "updating
bookmark", which was kind of terse. It also showed the "adding XX changesets"
output without any context, which is kind of scary to see "adding 100
changesets" when I'm only pushing one commit.
Now we mention how many commits we're pushing, what the hash range is, and how
many commits are being downloaded.
Test Plan: Ran ze tests
Reviewers: #sourcecontrol, mitrandir
Reviewed By: mitrandir
Subscribers: mitrandir
Differential Revision: https://phabricator.fb.com/D2594007
Signature: t1:2594007:1446081446:99b77f4982acafc1f1940ba07b094a27dd05e354
Summary:
Since pushrebase allows running hooks outside of the lock, we want to force all
pushes to go through pushrebase. Step #1 of that is making push --force go
through the pushrebase flow.
The initial version is pretty naive. A future version might avoid the whole
graft process for performance sake.
Test Plan:
Added a test that creates a new bookmark. I also tested the same test
doing a force push.
Reviewers: #sourcecontrol, rmcelroy
Reviewed By: rmcelroy
Subscribers: rmcelroy
Differential Revision: https://phabricator.fb.com/D2588894
Signature: t1:2588894:1446076583:12b58048742b112a5d7cab839204c6219414f9ee
Summary:
To do so, we had to change some path variables and change the output of some
tests. Removed a few dependencies that provided by hg.
Test Plan:
Ran the tests. There was some ignorable output changed (about devel-warn) caused by other code not
related to this change.
Reviewers: #sourcecontrol, pyd, rmcelroy
Reviewed By: rmcelroy
Subscribers: rmcelroy, durham
Differential Revision: https://phabricator.fb.com/D2499721
Signature: t1:2499721:1443745230:9d4e53e83356807f3343c8343e28d10f1b9dc35f
Summary:
Also added an additional test to show a case that fails now (and should fail),
but would have succeeded with the previous code.
Test Plan: Additional unit test
Reviewers: #sourcecontrol, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D2502396
Signature: t1:2502396:1443809922:18ec6697b7c135c37c10f7bdd9544901c4a54c99
Summary:
The old check moved the bookmark old node after the prepushkey hooks
had ran, bypassing the non-ff prevention logic. This moves the old node rewrite
to before the prepushkey hook and also checks that old node is moved in a
ff-only way.
Test Plan: updated unit test
Reviewers: #sourcecontrol, mitrandir
Reviewed By: mitrandir
Subscribers: durham
Differential Revision: https://phabricator.fb.com/D2499633
Signature: t1:2499633:1443733890:4c84150bd0f21adb97feb23e54727bb4e8be38cf
Summary:
In pushrebase, we expect bookmarks to be moving after discovery but
before we grab the lock. With this patch, we rewrite the incoming bookmark
changes so that they do not fail if the bookmark moves after discovery.
Test Plan:
Wrote a new test to cover this behavior and verified that the test failed before
this change but works afterwards.
Reviewers: #sourcecontrol, durham
Reviewed By: durham
Subscribers: durham
Differential Revision: https://phabricator.fb.com/D2488675
Signature: t1:2488675:1443503039:660f88da9727a74f7c9a21f0767efb5d7379d16d
Summary:
This tests were A) unreadable, and B) not deterministic. Let's remove all that
text and have a special test just for making sure the hook vars we care about
are present.
Also break the output into multiple lines for easier reading and diffing.
And fix a change in order for the remotenames test.
Test Plan: Ran the tests
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.fb.com/D2479274
Summary:
pushrebase doesn't support pushing non-fastward heads when remotenames is on
(since --to implies both remotenames and do a rebase). Long term we want --new
and --replace to indicate bookmark movements, but for now we can use the
existing -f to imply that we don't want a rebase to happen.
Test Plan: Added a test
Reviewers: #sourcecontrol, lcharignon
Reviewed By: #sourcecontrol, lcharignon
Subscribers: lcharignon
Differential Revision: https://phabricator.fb.com/D2307585
Summary:
Previously pushrebase could not create new bookmarks, because the rebase target
did not exist. This fixes that.
Also fixes some output text to match the core Mercurial behavior, so tools can
rely on the text in certain cases.
Test Plan: Added a test
Reviewers: lcharignon, pyd, rmcelroy, ericsumner
Reviewed By: ericsumner
Differential Revision: https://phabricator.fb.com/D2240418
Signature: t1:2240418:1436895571:2f56298969e09490f6f5e6a44857eedc2bfcace4
Summary:
This makes the pushrebase extension work with the remotenames extension. It does
a few things:
1) rename --onto to be --to for consistency
2) configures remotenames to allow non-fastforward pushes
3) changes the push wrapper to happen after remotenames is loaded
Test Plan: Added a test
Reviewers: pyd, rmcelroy, lcharignon, ericsumner
Reviewed By: ericsumner
Differential Revision: https://phabricator.fb.com/D2200222
Signature: t1:2200222:1435695629:a92d8b20d158aa40bad1f3963af0348b6680d52d
