Summary:
`test-duplicateoptions` complains about `-h` being a duplicate, since it's a default help option.
Depends on D6683248
Test Plan: - run the test, see the mention of this option disappear
Reviewers: stash, #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6683266
Summary:
`formatteropts` already give us the `-T`.
Depends on D6683245
Test Plan: - run `test-duplicateoptions`, see this particular thing disappear
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6683248
Summary:
We have our fbsparse, which we are using. We can rename it later when configs
are in the same repo as the extension files.
Test Plan: - run tests, see only the failures related to the other commits in the stack
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6683245
Summary: This fixes a test-check issue and makes the code safer.
Test Plan: run-tests.py
Reviewers: ikostia, #mercurial
Reviewed By: ikostia
Differential Revision: https://phabricator.intern.facebook.com/D6682545
Signature: 6682545:1515505853:0e9f81c33bbf4c2579ec16f14153fab5fea832fd
Summary:
These fixes are related to documentation-related check-style tests.
Depends on D6675344
Test Plan: - more tests pass
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6675351
Summary:
This commit moves most of the stuff in hgext3rd and related tests to
hg-crew/hgext and hg-crew/test respectively.
The things that are not moved are the ones which require some more complex
imports.
Depends on D6675309
Test Plan: - tests are failing at this commit, fixes are in the following commits
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6675329
Summary:
Moves the remotefilelog extension into hgext/ and it's tests into
tests/.
I did not fix up all the check-module errors, since it's a ton of work for
very little impact at this point.
Test Plan: make local && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6680030
Summary:
Moves ctreemanifest into hgext/extlib/. It will be built in a later
step when we add cstore to the build.
Test Plan: make local && cd tests && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6678844
Summary:
Move the rust libraries and extensions to their new locations, and integrate
them with the hg-crew setup.py.
Test Plan: Run `python setup.py build` and verify rust extensions are built.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: fried, jsgf, mitrandir
Differential Revision: https://phabricator.intern.facebook.com/D6677251
Tasks: T24908724
Signature: 6677251:1515450235:920faf40babbce9b09e3283ff9ca328d1c5c51e6
Summary:
Move hgsql into the hgext directory, and the tests to tests/test-hgsql-*.
Update the tests to refer to the new places for things.
Test Plan: Run the hgsql tests and make sure they pass.
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6660499
Tasks: T24908724
In preparation for adding more conditions that will disable IMM, let's make
this framework more extensible and log the reason IMM wasn't used.
The `whynotimm` variable name matches the `why_not_eden` name in
`hg/eden/__init__.py`.
Differential Revision: https://phab.mercurial-scm.org/D1785
Some callers to rebase.rebase(), like `_moverelative` in `fbamend/movement.py`,
wrap the entire rebase call in a transaction. This raises havoc when IMM tries
to retry the rebase when it hits merge conflicts, because the abort will fail
the whole transaction, not the subset. It also fails at the end, losing any
conflict resolution, as @sid0 noticed.
The right long-term fix that @quark and I have discussed is to change the
restarting logic such that it doesn't abort at all, but simply switches between
IMM and non-IMM fluidly for each commit, which has other nice properties. In
the meantime this will do for now.
Differential Revision: https://phab.mercurial-scm.org/D1782
We need hash-preserving unamend. Therefore remove the core version.
(grafted from 86e055fbb0c974e041dbd72cd95df6e3b37a0f6b)
(grafted from 129f15c3acd81d4390212430ea6b500412bc74ab)
(grafted from fbb42eb996d5bcddac4ba4e86a915a3bc62b3e16)
02c30db0443d (lfs: add a repo requirement for this extension once an lfs
file is committed) introduced a regression that prevents committing file
deletion. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1717
This will allow developers to test against various server implementations. I
didn't put it under [devel] because it's possible that some user needs to use it
in the field.
As we were trying to transition off of the non production lfs-test-server for
further experimenting, one of the problems we ran into was interoperability. A
coworker setup gitbucket[1] to act as the blob server, tested with git, and
passed it off to me. But push failed with a message saying "abort: LFS server
returns invalid JSON:", and then proceeded to dump a huge HTML page to the
screen. It turns out that it is assuming that git is the only thing that wants
to do a blob transfer, and everything else is a web browser wanting HTML.
It's only a single data point, but I suspect other things may be doing this too.
RFC7231 gives an example [2] of listing multiple products in decreasing order of
significance. Since the standard provides for this, and since it works with the
one problematic server I found, I'm just enabling this by default for a better
UX.
There's nothing significant about the version of git chosen, other than it is
the current version.
[1] https://github.com/gitbucket/gitbucket/
[2] https://tools.ietf.org/html/rfc7231#page-46
I don't see why unamend should be disallowed when allowunstable is
set. By switching to rewriteutil.precheck() we fix that and get more
consistent error messages (and some additional ones).
Differential Revision: https://phab.mercurial-scm.org/D1682
This significantly speeds up lfs prefetch. With fast network we are
seeing ~50% improvement of overall prefetch times
Because of worker's API in posix we do lose finegrained progress update and only
see progress when a file finished downloading.
Test Plan:
Run tests:
./run-tests.py -l test-lfs*
....
# Ran 4 tests, 0 skipped, 0 failed.
Run commands resulting in lfs prefetch e.g. hg sparse --enable-profile
Differential Revision: https://phab.mercurial-scm.org/D1568
The branch information was properly preserved in the changeset, but the
"active" branch of the working copy could be lost (the branch of the base
being used).
Histedit used to behave properly in this regard but the case was not tested
and regressed 4 years ago in c038baa4b6f0.
This effectively conditionalizes 7ac081713920. Some Linux distributions (like
CentOS 7) use really old versions, and the change referenced was causing
exceptions to be thrown.
Even though the deprecation warning says 'since 2.5.0', it wasn't marked as such
in 2.5.1, but is by 2.6.0. This was tested with 2.4.2 and 2.6.0 with
PYTHONWARNINGS=::DeprecationWarning, and both paths were exercized.
Previously, the largefile for a dropped standin would be deleted here, and then
restored from the cache. This had the effect of clobbering uncommitted changes
if a revert caused the file to be forgotten, which is not what happens with a
normal file. Now the removal and update is skipped for dropped largefiles, and
the corresponding standin is deleted from disk.
This was noticed when working on issue5738 because the forgotten standin files
were left behind, and that changes the behavior of the next rename to that
directory. My first attempt was to cleanup the standins before calling this.
That failed, because this function deletes the largefile if the corresponding
standin is missing.
This function is called by the revert command, merge (and therefore update), and
patch, via the scmutil.marktouched() override. So it should be pretty narrow in
scope.
I didn't mark issue5738 as fixed because the move related issues can still
happen if the main tree and the .hglf subtree get out of sync somehow. I don't
see an easy fix for that, but that should be an edge case. If whoever queues
this thinks it is good enough to close out the bug and can cram it into the
summary, go for it.
The `hg lfconvert --to-normal` command uses the convert extension internally to
work its magic, but that produced devel-warn messages if the convert extension
wasn't loaded by the user. The test in 658e7a6d93e0 (modified here) wasn't
showing the warnings because the convert extension was loaded via $HGRCPATH.
Most of the config options default to None/False, but 'hg.usebranchnames' and
'hg.tagsbranch' are supposed to default to True and 'default' respectively.
The first iteration of this was to ui.setconfig() inside lfconvert, to force the
convert extension to load. But there really is no precedent for doing this, and
check-config complained that 'extensions.convert' isn't documented. Yuya
suggested this alternative.
This partially backs out 448e09d8859d.
These config items control share behavior that is implemented in core.
Since the functionality is implemented in core, extensions may
leverage it.
Mozilla has one such extension. And, it needs to access share.pool.
Before this patch, a devel warning regarding accessing an unregistered
config option would be issued unless the share extension were loaded.
Moving the registration of the config options to core fixes this.
If the legacy pager extension is enabled, a pager is started through repo.ui
at dispatch._runcommand(). After that, mqcommand() creates a qrepo with a
fresh repo.baseui, at which point pager information was lost and another pager
would be spawned by the modern pager interface.
This is a minimal workaround for the problem.
5c25fe7fb1e broke something in the hgsubversion test path, causing it raise an
abort (Abort: nothing to merge) during a perfectly good rebase. I tracked it
down to this change. It's probably not hgsubversion related.
I suspect that using the same `wctx` from before the initial update causes
problems with the wctx's cached manifest property. I noticed we also sometimes
stick random gunk on the wctx object in other places (like in `copies.py`) so
it's probably best to reset it for now.
The line I added before was actually useless since we don't pass wctx to the
initial `merge.update`, so it defaults to `repo[None]`. So I just removed it.
Differential Revision: https://phab.mercurial-scm.org/D1679
committablefilectx has three subclasses: workingfilectx, memfilectx,
and overlayfilectx. committablefilectx takes an optional (change) ctx
instance to its constructor. If it's provided, it's set on the
instance as self._changectx. If not, that property is supposed to be
defined by the class. However, only workingfilectx does that. The
other two will have the property undefined if it's not passed in the
constructor. That seems bad to me. This patch makes the changectx
argument to the memfilectx constructor mandatory because that fixes
the failure I ran into. It seems like we should also fix the
overlayfilectx case.
Differential Revision: https://phab.mercurial-scm.org/D1658
