Summary:
The phabdiff template mapping returns the phabricator diff id for the commit
(based on commit message).
for example:
$ hg log -r master --template '{phabdiff}\n'
D1485506
Test Plan: - unit tests addded
Reviewers: sid0, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1622192
Tasks: 5124920
Summary:
Use `first()` instead of `[0]`.
Also fix coloring under non-ANSI terminals (required to get the test working).
Test Plan: Ran the tests. Also ran `hg sl` with this in a few of my repos.
Reviewers: durham, davidsp, akushner, daviser, rmcelroy, pyd
Reviewed By: pyd
Differential Revision: https://phabricator.fb.com/D1623808
Tasks: 5375006
Upstream no longer always uses bookmark.write to write. Sometimes it goes
through the transaction API and uses bookmark._write. So now we wrap that
instead.
Also adds a test that would have caught this, since the existing commit/bookmark
tests did not exercise this new write path.
Summary:
Add 'stop' verb to histedit. This is the version I submited to the ML
which got rejected because it doesn't preserve hashes. However as arc will
always modify the hash anyway that's save for us anyawy.
Test Plan: run tests, worked.
Reviewers: durham, sid0
Subscribers: akushner
Differential Revision: https://phabricator.fb.com/D1606075
fb666f865e02 fixed gitlookup to work with upstream Mercurial, but we aren't
ready to deploy upstream Mercurial yet. So I'm backing it out so we can deploy
the fb-hgext rpms in the mean time.
Summary:
This adds an extension that tracks the locations of the working copy and
bookmarks over time. It's still a proof of concept, but I want to get it
deployed to start getting feedback.
Running `hg reflog` by default shows the previous locations of the working
copy (most recent first).
~/myrepo> hg reflog
Previous locations of '.':
35a5fcfee452 rebase -d master
32eee5e2d406 up .^
b5d6dab4f900 up foo -C
Specifying a bookmark name shows the locations of that bookmark over time.
~/myrepo> hg reflog foo
Previous locations of 'foo':
d1a696044ec0 rebase -d master
35a5fcfee452 rebase -d master
32eee5e2d406 book foo -f
--verbose will show more information about each entry.
~/myrepo> hg reflog foo -v
Previous locations of 'foo':
35a5fcfee452 -> d1a696044ec0 durham 2014-10-01 18:32:14 rebase -d master
32eee5e2d406 -> 35a5fcfee452 durham 2014-10-01 17:28:54 rebase -d master
000000000000 -> 32eee5e2d406 durham 2014-10-01 17:28:30 book foo -f
It's currently stored as a single .hg/reflog file that is append only. Each
entry can store an arbitrary number of hashes (like storing 2 hashes for a merge
state working copy), which means we could also potentially use this to track
heads in branches as well.
It also (sorta) works with '-T json' for machine readable output:
~/myrepo> hg reflog foo -T json
[
{
"command": "up .^",
"date": "2014-10-02 13:54:45",
"newhashes": "474ff61d1a36",
"oldhashes": "d1a696044ec0",
"user": "durham "
},
{
"command": "book foo",
...
]
Test Plan: Added tests. Ran them.
Reviewers: sid0, pyd, mpm, davidsp, akushner
Differential Revision: https://phabricator.fb.com/D1592875
Summary:
sshing to the hg server could result in stdout containing 'remote: ...' (like if
the user had an extension enabled that wasn't on the server). This interefered
with fbmake being able to parse the git hash and broke fbmake for people with
such configs.
The fix is to redirect it to stderr instead. I tried using ui.push/popbuffer
but it doesn't actually work because the ui that is being used is newly
constructed as part of the peer being created, and therefore doesn't respect the
buffer stack. I also tried ui.quiet=True, but that also failed, as newly created
ui's don't inherit the original quiet value, but instead look at the main
config['quiet'].
Test Plan:
Added a bogus extension to my ~/.hgrc
hh log -r 1095d3a297300405f679826fc78d52c8a6c1da85 -T '{gitnode}\n' 2>/dev/null
hh log -r g988fa44ff4bebf4093b09ef27b5e24702ebda6ab 2>/dev/null
Verified there was no 'remote:' output.
Reviewers: sid0, mpm, pyd
Differential Revision: https://phabricator.fb.com/D1604547
Summary:
Previously, `hg grep` would follow symlinks because that's what `grep` does. This is a problem in fbcode because of all the tp2 and dewey symlinks. Handroll our iteration and ignore all files recorded as symlinks in the dirstate. This isn't perfect, but it's good enough and it's a lot faster than stating all the files.
Presumably we can integrate this with hgwatchman at some point.
Now, `hg grep <random string>` in fbcode takes just 2.6 seconds. (`git grep` takes 4.)
Test Plan: Ran tests.
Reviewers: daviser, akushner, davidsp, pyd, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1587863
Summary:
Previously we wrapped commands at global initialization time, which is just
plain wrong (since other commands may not have even be initialized yet). Now we
do it inside extsetup. It's mildly important that we do it in extsetup (vs
uisetup) because other extensions, like remotefilelog, wrap commands in the
uisetup and we want to make sure that our tweaks (like passing -f to log) come
first. And by wrapping last, we get invoked first.
Test Plan: Ran the tests
Reviewers: sid0, davidsp, pyd
Differential Revision: https://phabricator.fb.com/D1578154
Summary:
Add a bunch of features to make `hg grep` full-featured.
- Support for basic, extended and Perl regexps.
- Support for filter patterns, including filesets.
- Support for color in the output.
Test Plan: Ran the tests, and ran `hg grep` against the repo.
Reviewers: davidsp, akushner, pyd, daviser, durham
Reviewed By: durham
Subscribers: robarnold
Differential Revision: https://phabricator.fb.com/D1578743
Summary: The hg equivalent of git grep is hg grep now.
Test Plan: I used the extension and called hg githelp -- git grep and it said hg grep
Reviewers: sid0, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1576499
Tasks: 5162839
Summary: I added a grep command that does the wgrep alias. I also moved the traditional functionality of grep to histgrep. One thing missing is the help strings.
Test Plan:
I used both wgrep and my new grep on a couple queries in www. They returned the same results. I did similar things with the traditional grep and my histgrep.
I wrote tests in fb-hgext/tests/test-tweakdefaults.t and they passed.
Reviewers: pyd, davidsp, akushner, durham, sid0
Reviewed By: durham, sid0
Subscribers: akushner, micha
Differential Revision: https://phabricator.fb.com/D1572855
Tasks: 5162839
Summary: Allow git hashes to work with a `g` suffix, sort of like Subversion's `r`.
Test Plan: Ran the tests, and tested it out in fbandroid-hg.
Reviewers: davidsp, akushner, pyd, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1571258
Summary: With tweakdefaults `hg rebase` broke when the destination contained a hyphen. This made me sad :(
Test Plan: Tested rebase with hyphen, and ran tests.
Reviewers: pyd, durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1565265
Summary: The location of `bundle2caps` changed.
Test Plan: Ran the tests, saw that they no longer failed.
Reviewers: durham, davidsp, akushner, pyd
Reviewed By: pyd
Differential Revision: https://phabricator.fb.com/D1562466
Tasks: 5170539
Summary:
Adds a wip extension which will allow clients to checkout
bookmarks from their peers instead of using arc patch.
This is accomplished by writing metadata about every
commit to a mysql database. When the user attempts to
checkout another user's bookmark, eg `hg checkout mjberger/test`,
the extension queries the mysql server to see if the bookmark
'test' exists on mjberger's dev server. If so, the extension
will use 'hg pull' to download the bookmark.
This is a wip and should not be used in production. Besides being
a hacky implementation, it currently relies on fbcode and does
not remove bookmarks from the mysql server when the client deletes
them.
Test Plan: doitlive
Reviewers: durham
Reviewed By: durham
Subscribers: njormrod, agallagher
Differential Revision: https://phabricator.fb.com/D1542144
Summary: This makes the error easier to read.
Test Plan: Ran `hg update`, saw that the error was printed across two lines.
Reviewers: durham
Reviewed By: durham
Differential Revision: https://phabricator.fb.com/D1542591
Summary:
The tweakdefaults extension broke 'hg update -r'. This fixes it and
adds a test.
Test Plan: Added a test.
Reviewers: sid0
Reviewed By: sid0
Differential Revision: https://phabricator.fb.com/D1506040
Summary:
This makes tweaks to the Mercurial defaults, to improve the user experience:
- hg update without arguments now aborts
- hg log now defaults to -f
- hg rebase without -d now aborts
- hg rebase will fast forward a bookmark if possible
Test Plan: Added a test, ran it.
Reviewers: mpm, sid0, davidsp, dschleimer, akushner
Differential Revision: https://phabricator.fb.com/D1501398
This will allow simple synchronisation between the public facing and the
external repository. Change to the Facebook only extension should be done on in
the fbonly branch. Fix the public facing extension should happens in the default
branch.
Merge should always happen from default to fbonly. Never the other way around.
Beware that facebook only changesets exist on the default branch before this
merge.
Summary:
We couldn't handle the git case (fbandroid-hg) at all. This fixes that.
I changed my .hg/hgrc to have
```[phrevset]
callsign = FA```
but I've no idea how to do that globally.
Test Plan:
```
[diffrev] Starting Conduit call
[diffrev] echo '{"revision_id": "1153911"}' | arc call-conduit differential.getdiff
[diffrev] Starting log walk
[diffrev] Traversing log for 1153911
[diffrev] Conduit call returned 0
[diffrev] VCS is git
[diffrev] GIT rev is 34838a7f1d68531f385e471bf76f89c6620ea563
Path: ssh://hg.vip.facebook.com//data/scm/fbandroid opts: {}
running ssh hg.vip.facebook.com 'hg -R /data/scm/fbandroid serve --stdio'
sending hello command
sending between command
remote: 199
remote: capabilities: lookup changegroupsubset branchmap pushkey known getbundle unbundlehash batch stream-preferred streamreqs=lz4revlog,revlogv1 unbundle=HG10GZ,HG10BZ,HG10UN httpheader=1024 remotefilelog
remote: 1
sending lookup command
[diffrev] HG rev is e67eac10eef35a21a3b61f8aa8caa330884d48d4
...
```
Reviewers: sid0, davidsp
Reviewed By: davidsp
Differential Revision: https://phabricator.fb.com/D1458491
Summary: phrevset was completely broken, even for the case where it does a linear search.
Test Plan:
Tested before and after in fbandroid-hg. It was finding the revision but
`hg log -r 'DXX'` wasn't printing anything.
Reviewers: sid0, davidsp
Reviewed By: davidsp
Differential Revision: https://phabricator.fb.com/D1458472
Summary: Fix the import of the time package for calls to strftime() and localtime().
Test Plan:
* Edited /usr/lib/python2.6/site-packages/backups.py, cleared .pyo & .pyc, and verified
that `python -c "import backups"` didn't error out on import
Reviewers: durham
Differential Revision: https://phabricator.fb.com/D1456741
Summary: hg githelp blame didn't work
Test Plan: not sure how to test this
Reviewers: pyd, davidsp, durham
Reviewed By: durham
Subscribers: sameen
Differential Revision: https://phabricator.fb.com/D1411080