Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 May 2019 22:56:58 -0700] rev 42328
changelog: define changelogrevision.p[12]copies for null revision
Looks like I missed these in 5382d8f8530b (changelog: parse copy
metadata if available in extras, 2017-12-27). `hg debugp[12]copies -r
null` fails before this patch.
Differential Revision: https://phab.mercurial-scm.org/D6376
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 13:29:13 -0700] rev 42327
copies: write empty entries in changeset when also writing to filelog
When writing to both changeset and filelog (during transition), we
don't want the reader to waste time by falling back to reading from
the filelog when there is no copy metadata. Let's write out empty copy
metadata instead (the read path is already prepared for this
case). Thanks to Greg for pointing this out.
Differential Revision: https://phab.mercurial-scm.org/D6306
timeless <timeless@mozdev.org> [Mon, 13 May 2019 14:19:36 -0400] rev 42326
rebase: hide help for revisions.Predicates._destautoorphanrebase
timeless <timeless@mozdev.org> [Fri, 03 May 2019 16:07:57 -0400] rev 42325
unshelve: add space to help
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 22:24:47 -0700] rev 42324
context: default to using branch from dirstate only in workingctx
Same reasoning as previous commits: only the workingctx should know
about the dirstate.
committablectx now seems free of dirstate references.
Differential Revision: https://phab.mercurial-scm.org/D6374
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 22:51:33 -0700] rev 42323
context: let caller pass in branch to committablectx.__init__()
committablectx.__init__() currently looks up the branch from the
dirstate unless it's passed in the extras. memctx.__init__() has a
branch argument, but since committablectx.__init__() doesn't accept
it, it lets that constructor look up the branch from the dirstate
before it overwrites it, which seems awkward.
Differential Revision: https://phab.mercurial-scm.org/D6366
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 21:55:59 -0700] rev 42322
context: move contents of committablectx.markcommitted() to workingctx
Same reasoning as previous commits: this function updates the
dirstate. By not updating the dirstate here, we also fix the
close-head test.
Differential Revision: https://phab.mercurial-scm.org/D6365
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 22:18:11 -0700] rev 42321
tests: demonstrate that close-head command updates working copy
The help text for the command says "...it doesn't change the working
directory", so I don't think this is intentional.
Differential Revision: https://phab.mercurial-scm.org/D6364
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 21:53:41 -0700] rev 42320
context: move walk() and match() overrides from committablectx to workingctx
Same reasoning as previous commit: these functions update the dirstate.
Differential Revision: https://phab.mercurial-scm.org/D6363
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 21:35:30 -0700] rev 42319
context: move flags overrides from committablectx to workingctx
These read from the dirstate, so they shouldn't be used in other
subclasses.
Differential Revision: https://phab.mercurial-scm.org/D6362
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 13:41:42 -0700] rev 42318
context: reuse changectx._copies() in all but workingctx
This moves the dirstate-specific _copies() implementation from
committablectx into workingctx where it should be (I think all
dirstate-specific stuff should be moved into workingctx). The part of
changectx._copies() that is for producing changeset-wide copy dicts
from the filectxs is moved into basectx so it's reused by the other
subclasses. The part of changectx._copies() that's about reading copy
information from the changeset remains there. This fixes in-memory
rebase (and makes `hg convert` able to write copies to changesets).
Differential Revision: https://phab.mercurial-scm.org/D6219
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 14:27:22 -0700] rev 42317
overlayworkingctx: don't include added-then-deleted files in memctx
If a file (such as a .orig file) is temporarily added to the
overlayworkingctx and then deleted, it's still going to be in the
_cache dict. In tomemctx(), we created the list of files from
_cache.keys(), so the memctx.files() would include the temporary
file. That was fine because the list of files was only used in
localrepo.commitctx() (I think), where there's an extra filtering of
incorrectly removed files (annotated with an inaccurate "update
manifest" comment). I'd like to call memctx.files() in another case,
but first we need to make it accurate.
Differential Revision: https://phab.mercurial-scm.org/D6361
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 10:23:46 -0700] rev 42316
tests: demonstrate loss of changeset copy metadata on rebase
Differential Revision: https://phab.mercurial-scm.org/D6360
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 11:03:54 -0700] rev 42315
overlaycontext: allow calling copydata() on clean context
We should just report no copy if the context is clean.
Differential Revision: https://phab.mercurial-scm.org/D6358
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 May 2019 10:23:08 -0700] rev 42314
tests: demonstrate another failure with in-memory rebase and copies
This is a similar to dd1ab72be983 (test: demonstrate crash with
in-memory rebase and copies, 2019-03-14). The new failure started with
57203e0210f8 (copies: calculate mergecopies() based on pathcopies(),
2019-04-11). It happens in the call to mergemod.update() on
rebase.py:1268 where we call mergemod.update() to graft a node. Since
the mergecopies() rewrite, that calls _related() with the filectx from
the overlaywctx instead of a filectx from the changectx where the file
was last modified. Either should be fine, so I don't think that's
a bug.
Differential Revision: https://phab.mercurial-scm.org/D6357
Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 May 2019 16:40:49 -0700] rev 42313
commit: fix a typo ("form p1" -> "from p1")
Differential Revision: https://phab.mercurial-scm.org/D6375
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 27 Apr 2019 11:48:26 -0700] rev 42312
automation: initial support for running Linux tests
Building on top of our Windows automation support, this commit
implements support for performing automated tasks on remote Linux
machines. Specifically, we implement support for running tests
on ephemeral EC2 instances. This seems to be a worthwhile place
to start, as building packages on Linux is more or less a solved
problem because we already have facilities for building in Docker
containers, which provide "good enough" reproducibility guarantees.
The new `run-tests-linux` command works similarly to
`run-tests-windows`: it ensures an AMI with hg dependencies is
available, provisions a temporary EC2 instance with this AMI, pushes
local changes to that instance via SSH, then invokes `run-tests.py`.
Using this new command, I am able to run the entire test harness
substantially faster then I am on my local machine courtesy of
access to massive core EC2 instances:
wall: 16:20 ./run-tests.py -l (i7-6700K)
wall: 14:00 automation.py run-tests-linux --ec2-instance c5.2xlarge
wall: 8:30 automation.py run-tests-linux --ec2-instance m5.4xlarge
wall: 8:04 automation.py run-tests-linux --ec2-instance c5.4xlarge
wall: 4:30 automation.py run-tests-linux --ec2-instance c5.9xlarge
wall: 3:57 automation.py run-tests-linux --ec2-instance m5.12xlarge
wall: 3:05 automation.py run-tests-linux --ec2-instance m5.24xlarge
wall: 3:02 automation.py run-tests-linux --ec2-instance c5.18xlarge
~3 minute wall time to run pretty much the entire test harness is
not too bad!
The AMIs install multiple versions of Python. And the run-tests-linux
command specifies which one to use:
automation.py run-tests-linux --python system3
automation.py run-tests-linux --python 3.5
automation.py run-tests-linux --python pypy2.7
By default, the system Python 2.7 is used. Using this functionality,
I was able to identity some unexpected test failures on PyPy!
Included in the feature is support for running with alternate
filesystems. You can simply pass --filesystem to the command to
specify the type of filesystem to run tests on. When the ephemeral
instance is started, a new filesystem will be created and tests
will run from it:
wall: 4:30 automation.py run-tests-linux --ec2-instance c5.9xlarge
wall: 4:20 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem xfs
wall: 4:24 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem tmpfs
wall: 4:26 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem ext4
We also support multiple Linux distributions:
$ automation.py run-tests-linux --distro debian9
total time: 298.1s; setup: 60.7s; tests: 237.5s; setup overhead: 20.4%
$ automation.py run-tests-linux --distro ubuntu18.04
total time: 286.1s; setup: 61.3s; tests: 224.7s; setup overhead: 21.4%
$ automation.py run-tests-linux --distro ubuntu18.10
total time: 278.5s; setup: 58.2s; tests: 220.3s; setup overhead: 20.9%
$ automation.py run-tests-linux --distro ubuntu19.04
total time: 265.8s; setup: 42.5s; tests: 223.3s; setup overhead: 16.0%
Debian and Ubuntu are supported because those are what I use and am
most familiar with. It should be easy enough to add support for other
distros.
Unlike the Windows AMIs, Linux EC2 instances bill per second. So
the cost to instantiating an ephemeral instance isn't as severe.
That being said, there is some overhead, as it takes several dozen
seconds for the instance to boot, push local changes, and build
Mercurial. During this time, the instance is largely CPU idle and
wasting money. Even with this inefficiency, running tests is
relatively cheap: $0.15-$0.25 per full test run. A machine running
tests as efficiently as these EC2 instances would cost say $6,000, so
you can run the test harness a >20,000 times for the cost of an
equivalent machine. Running tests in EC2 is almost certainly cheaper
than buying a beefy machine for developers to use :)
# no-check-commit because foo_bar function names
Differential Revision: https://phab.mercurial-scm.org/D6319
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 23 Apr 2019 21:57:32 -0700] rev 42311
automation: move image operations to own functions
An upcoming commit will need this functionality with slightly different
values and it is enough code to not want to duplicate. Let's refactor
into standalone functions so it can be reused.
Differential Revision: https://phab.mercurial-scm.org/D6318
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 09:18:23 -0700] rev 42310
automation: add --version argument to build-all-windows-packages
This lets us pass a version string through when building all
Windows packages, just like we can do with the individual commands
which produce installers.
Differential Revision: https://phab.mercurial-scm.org/D6317
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 08:32:24 -0700] rev 42309
automation: do a force push to synchronize
We don't know what the state of the remote is. Force pushing will
be more resilient.
Differential Revision: https://phab.mercurial-scm.org/D6316
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 08:21:02 -0700] rev 42308
automation: add check that hg source directory is a repo
Synchronizing from e.g. source distributions is not yet supported.
Let's add a check so we fail with an error message indicating
such.
Differential Revision: https://phab.mercurial-scm.org/D6315
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 07:34:55 -0700] rev 42307
automation: shore up rebooting behavior
There was a race condition in the old code. Use
instance.stop()/instance.start() to eliminate it.
As part of debugging this, I also found another race condition
related to PowerShell permissions after the reboot. Unfortunately,
I'm not sure the best way to work around it. I've added a comment
for now.
Differential Revision: https://phab.mercurial-scm.org/D6288
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 06:07:00 -0700] rev 42306
automation: wait longer for WinRM connection
I got a few timeouts waiting for only 120s for the WinRM connection
to become available. Increasing to 180s seems to fix. I guess
AWS isn't as consistent as I would like :(
Differential Revision: https://phab.mercurial-scm.org/D6287
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 27 Apr 2019 11:38:58 -0700] rev 42305
automation: wait for instance profiles and roles
Otherwise there is a race condition between creating the resources
and us attempting to use them / them becoming available.
The role waiter API was recently introduced, so we had to upgrade
the boto3 package to get it. Other packages were also updated
to latest versions just because.
Even with this change, I still run into issues with the IAM instance
profile not being available when we attempt to create an EC2 instance
using a just-created profile. I'm not sure what's going on. Possibly
a bug on Amazon's end. But the new behavior is "more correct."
Differential Revision: https://phab.mercurial-scm.org/D6286
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 05:20:33 -0700] rev 42304
automation: don't create resources when deleting things
Otherwise running these commands can result in resources being
created. In the case of `purge-ec2-resources`, we will create
resources only to delete them immediately afterwards!
With this change, `purge-ec2-resources` now no-ops if no
resources exist.
# no-check-commit because foo_bar function name
Differential Revision: https://phab.mercurial-scm.org/D6285
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 05:15:43 -0700] rev 42303
automation: detach policies before deleting role
You can't delete an IAM role that has attached policies.
With this change, the purge-ec2-resources command now works.
Differential Revision: https://phab.mercurial-scm.org/D6284
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Apr 2019 05:07:44 -0700] rev 42302
automation: only iterate over our AMIs
We can't delete AMIs that we don't own. Iterating over other
AMIs won't work and slows down execution.
Differential Revision: https://phab.mercurial-scm.org/D6283
Martin von Zweigbergk <martinvonz@google.com> [Wed, 01 May 2019 15:34:03 -0700] rev 42301
remotefilelog: move most setup from onetimesetup() to uisetup()
All the wrappers moved in this patch check if remotefilelog is enabled
before they change behavior, so it's safe to always wrap.
Differential Revision: https://phab.mercurial-scm.org/D6334
Martin von Zweigbergk <martinvonz@google.com> [Wed, 01 May 2019 15:24:16 -0700] rev 42300
remotefilelog: move most functions in onetimeclientsetup() to top level
This is how most extensions seem to do it. It makes sure we don't
accidentally depend on the captured ui instance.
Differential Revision: https://phab.mercurial-scm.org/D6333
Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 May 2019 09:46:38 -0700] rev 42299
tests: avoid the word "dirty" to mean "not a descendant of merge base"
The term "dirty" is no longer used in the code since 57203e0210f8
(copies: calculate mergecopies() based on pathcopies(), 2019-04-11).
Differential Revision: https://phab.mercurial-scm.org/D6373
Martin von Zweigbergk <martinvonz@google.com> [Wed, 01 May 2019 20:54:27 -0700] rev 42298
releasenotes: add a file in which to record release notes
I've just spent a few very boring hours going through the changelog
for the 5.0 release (829 commits). We only had 5 commits that used the
syntax that the release notes extension expects. This commit adds a
file in which we can record important changes. The file should
preferably be edited in the patch that makes the important change, but
it can also be edited after (I think this is an important benefit
compared to the release notes extension).
I'm thinking that we can rename the file from "next" to "5.1" or
something when it's time, and then we'd create a new "next" file on
the default branch.
I've used the syntax that we use on the our wiki in the template, but
I don't care much that we use any valid syntax at all. The idea is
mostly to record important changes when they happen. I expect that
some copy editing will be needed at release time anyway.
Differential Revision: https://phab.mercurial-scm.org/D6332
Matt Harbison <matt_harbison@yahoo.com> [Sat, 11 May 2019 22:08:57 -0400] rev 42297
record: avoid modifying the matcher passed as a method parameter
No problem observed, but I remember the previous pattern causing problems with
largefiles and/or subrepos. This special matcher was added in 419ac63fe29c, so
directly modifying the `fail` callback was probably an oversight in
44611ad4fbd9.
Differential Revision: https://phab.mercurial-scm.org/D6371
Augie Fackler <augie@google.com> [Sat, 04 May 2019 23:31:42 -0400] rev 42296
sslutil: add support for SSLKEYLOGFILE to wrapsocket
I recently learned of a Firefox/Chrome feature that allows
wiresharking otherwise-TLS'd network connections. Gloriously, there's
a pypi module that enables this same feature on Python, so let's add
support for it to Mercurial in case we need to wireshark some HTTPs
connections.
Differential Revision: https://phab.mercurial-scm.org/D6343
Ian Moody <moz-ian@perix.co.uk> [Sun, 05 May 2019 17:04:48 +0100] rev 42295
phabricator: add custom vcr matcher to match request bodies
Currently when the phabricator extension's conduit output changes the tests
don't notice since the default vcr matcher only matches on 'method' and 'uri',
not the body.
Add a custom matcher that checks the same params are in the body (ignoring
ordering).
vcr's in-built body matcher can't be used since it fails under py3 with a
"UnicodeEncodeError" on the "€ in commit message" tests.
The DREV ids have decreased since the recordings were generated against a
different phabricator instance to avoid spamming mercurial-devel.
Differential Revision: https://phab.mercurial-scm.org/D6347
Augie Fackler <augie@google.com> [Thu, 09 May 2019 18:37:37 -0400] rev 42294
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 08 May 2019 21:25:23 -0700] rev 42293
absorb: be more specific when erroring out on merge commit
When you have a merge commit checked out and run `hg absorb`, it would
tell you
abort: no mutable changeset to change
That makes it sound like the problem is public commits when isn't
really. Let's be more specific in this case.
There was already a test case that test this, so that now prints the
new message. I added a new test case that shows the old message (when
a public commit is checked out).
Differential Revision: https://phab.mercurial-scm.org/D6354
Augie Fackler <augie@google.com> [Wed, 08 May 2019 18:11:33 -0400] rev 42292
remotefilelog: log when we're about to fetch files
I'm debugging a slow client situation and knowing how many files are
in the batch request would be a nice thing.
Differential Revision: https://phab.mercurial-scm.org/D6353
Yuya Nishihara <yuya@tcha.org> [Tue, 30 Apr 2019 15:15:57 +0900] rev 42291
revset: populate wdir() by its hash or revision number
It belongs to the same category as the null hash/revision, and we do handle
these virtual identifiers in id()/rev() predicates. Let's do that more
consistently.
Yuya Nishihara <yuya@tcha.org> [Tue, 30 Apr 2019 15:10:07 +0900] rev 42290
revset: extract private constant of {nullrev, wdirrev} set
I'll add a few more users of this constant to get around wdir identifiers.
Yuya Nishihara <yuya@tcha.org> [Tue, 30 Apr 2019 15:22:03 +0900] rev 42289
help: suggest merge() revset instead of -m/--only-merges
Suggested by Dr Rainer Woitok.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 06 May 2019 22:06:23 -0700] rev 42288
tests: update annotate tests to work around simplemerge bug
test-annotate.t and test-fastannotate.hg were failing with --pure
since 57203e0210f8 (copies: calculate mergecopies() based on
pathcopies(), 2019-04-11). It turned out to be because the pure file
merge code behaved differently. I'm guessing it's the
mdiff.get_matching_blocks() that behaves differently, but I haven't
confirmed that.
With this content in the base:
a
a
a
And this on the local side:
a
z
a
And this on the other side:
a
a
a
b4
c
b6
It produced this conflict:
a
z
a
<<<<<<< working copy: b80e3e32f75a - test: c
||||||| base
a
=======
a
b4
c
b5
>>>>>>> merge rev: 64afcdf8e29e - test: mergeb
I don't care enough about the pure Python code to fix it, so this
patch just updates the tests to manually resolve the conflict.
Differential Revision: https://phab.mercurial-scm.org/D6351
Martin von Zweigbergk <martinvonz@google.com> [Tue, 07 May 2019 14:42:15 -0700] rev 42287
copies: delete misplaced comment
The comment was added in 78d760aa3607 (duplicatecopies: do not mark
items not in the dirstate as copies, 2013-03-28). It became misplaced
in 3666331164bb (cmdutil: add copy-filtering support to
duplicatecopies, 2014-06-07). Then the relevant code was moved far
away in 754b5117622f (context: add workingfilectx.markcopied,
2017-10-15).
Differential Revision: https://phab.mercurial-scm.org/D6352
Ian Moody <moz-ian@perix.co.uk> [Mon, 22 Apr 2019 18:55:27 +0100] rev 42286
phabricator: include branch in the phabread output
Depends on D6301
Differential Revision: https://phab.mercurial-scm.org/D6302
Ian Moody <moz-ian@perix.co.uk> [Mon, 22 Apr 2019 18:55:26 +0100] rev 42285
phabricator: fallback to reading metadata from diff for phabread
Differential Revision: https://phab.mercurial-scm.org/D6301
Ian Moody <moz-ian@perix.co.uk> [Sat, 20 Apr 2019 16:11:23 +0100] rev 42284
phabricator: include commit (node) and parent in the local:commits metadata
Differential Revision: https://phab.mercurial-scm.org/D6298
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:34:45 -0700] rev 42283
copies: remove redundant filtering of ping-pong renames in _chain()
We already handle the ping-pong rename case in the filtering step, so
there's very little point in doing it in the chaining loop (ping-pong
renames are very rare, so I'm not worried about the cost of adding it
and then removing it again).
Differential Revision: https://phab.mercurial-scm.org/D6344
Augie Fackler <augie@google.com> [Fri, 03 May 2019 15:43:44 -0400] rev 42282
repair: reword comments that I noticed while working on source formatting
I think this is clearer, and one will also keep us from upsetting
check-code when other formatting cleanups happen.
Differential Revision: https://phab.mercurial-scm.org/D6339
Sietse Brouwer <sbbrouwer@gmail.com> [Fri, 26 Apr 2019 12:41:48 +0200] rev 42281
gendoc: nest command headers under category headers
Differential Revision: https://phab.mercurial-scm.org/D6329
Sietse Brouwer <sbbrouwer@gmail.com> [Fri, 26 Apr 2019 12:40:26 +0200] rev 42280
minirst: support subsubsubsubsections (header level 5) with marker ''''
Differential Revision: https://phab.mercurial-scm.org/D6328
Sietse Brouwer <sbbrouwer@gmail.com> [Fri, 03 May 2019 15:37:08 +0200] rev 42279
gendoc: guarantee that all commands were processed
The new logic renders the commands belonging to each category in turn.
Commands with an unregistered category are at risk of getting skipped
because their category is not in the list. By comparing the list of all
commands to a log of processed commands, we can detect commands with
unregistered categories and fail with an error message.
Differential Revision: https://phab.mercurial-scm.org/D6327
Sietse Brouwer <sbbrouwer@gmail.com> [Fri, 26 Apr 2019 17:53:01 +0200] rev 42278
gendoc: group commands by category in man page and HTML help
Make Mercurial's man page and HTML help group commands by category, and
present the categories in a helpful order. `hg help` already does this;
this patch uses the same metadata.
This patch uses the same header level for command categories and for
commands. A subsequent patch will push the command headers down one
level.
Differential Revision: https://phab.mercurial-scm.org/D6326
Sietse Brouwer <sbbrouwer@gmail.com> [Thu, 25 Apr 2019 19:15:17 +0200] rev 42277
gendoc: indent loop to make next patch more legible
Differential Revision: https://phab.mercurial-scm.org/D6325
Augie Fackler <augie@google.com> [Fri, 03 May 2019 15:53:56 -0400] rev 42276
contrib: have byteify-strings explode if run in Python 2
Differential Revision: https://phab.mercurial-scm.org/D6341
Augie Fackler <augie@google.com> [Fri, 03 May 2019 15:46:09 -0400] rev 42275
repair: reword comment about bookmarks logic
Again, this will help auto-formatting shortly.
Differential Revision: https://phab.mercurial-scm.org/D6340
Augie Fackler <augie@google.com> [Fri, 03 May 2019 15:42:13 -0400] rev 42274
monotone: fix a bogus _() wrapper that was caught when formatting code
There was a spurious space after `debug`, which hid the _() inside
ui.debug() from check-code. Sigh.
While here, wrap things more concisely.
Differential Revision: https://phab.mercurial-scm.org/D6338
Anton Shestakov <av6@dwimlabs.net> [Fri, 03 May 2019 14:11:16 +0800] rev 42273
commit: add ability to print file status after each successful invocation
When commands.commit.post-status is enabled, `hg commit` will effectively run
`hg status -mardu` after committing. It can help catch mistakes like not
committing all needed files or not adding unknown files that should've been
part of the just created commit.
Anton Shestakov <av6@dwimlabs.net> [Fri, 03 May 2019 14:07:14 +0800] rev 42272
tests: flatten repo structure in test-commit.t
Let's move to parent directory before `hg init` repos, since they don't need to
be nested. It makes amend/strip messages that include full path to the backup
bundle shorter, for instance.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 04 May 2019 01:16:42 -0400] rev 42271
lfs: add a TODO file
This is a cleaned up and reorganized list of items I sent out about a year ago.
But tracking this in the repo (like the narrow extension) gives more visibility
in case anyone wants to help out.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 27 Apr 2019 22:08:45 -0700] rev 42270
copies: make "limit" argument to _tracefile() mandatory
We always pass a limit. I think the fact that it was optional was also
the reason we checked ">=limit" before we used it. So now we can
remove that condition too.
Differential Revision: https://phab.mercurial-scm.org/D6335
Martin von Zweigbergk <martinvonz@google.com> [Fri, 03 May 2019 08:37:10 -0700] rev 42269
localrepo: don't use defaults arguments that will never be overridden
The commithook() callback will be called when the lock is
released. lock.release() calls the callback without arguments, so it
was quite confusing to me that this function declared extra
arguments. We can just close on the variables in the outer scope
instead.
Differential Revision: https://phab.mercurial-scm.org/D6336