- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
As far as I can tell, this was previously used to "detect" an initial clone. Unfortunately, that logic is incorrect: like Mercurial, hg-git should consider pulling into an empty repository distinct from cloning. As an apparent aside, it also kind-of-sort-of handled the case where you pulled from a local Git repository into a location that happened to be default. To fix this, we do two things: 1) Expand relative local paths before comparing them to other paths. 2) Detect clone from the source of the default `default` path. The end result is: 1) You can pull from e.g. `../repo` to update remotes, with an equivalent path specified in the configuration 2) Pulls from entirely foreign remotes are no longer saved. 3) We always activate the desired bookmarks on clone. Although the two changes might seem unrelated, their effect is combined, and either alone would break the tests.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, we'd only write that when pushing to a named remote, rather than directly to its path or URL, which seems weirdly inconsistent.
-
- May 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This code was quite hard to read.
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Aug 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This is handled by testutil these days; having it in each test is pointless clutter.
-
Dan Villiom Podlaski Christiansen authored
We currently imply a default path when pushing to unknown Git remotes, and add corresponding git-remote tags. Only one of our tests relies on this. To document the differences, run it with and without a path.
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This makes it easier to see what's going on.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
(it does not)
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is a premature optimisation, since Dulwich does a lot caching internally anyway. I have been unable to demonstrate any benefit from this; a bit of profiling shows that this stage of an incoming command takes ~12 seconds, even with more than 100k commits. Generally speaking, the actual conversion will take significantly longer time than caching these objects. In fact, the cache might actually be harmful for very long-running conversions, as they tend to run into memory constraints.
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Dulwich has the add_thin_pack() function for adding a pack to the repository which may be thin, i.e. refer to objects outside the pack. We can avoid that on an initial clone, however, as we know that we just created the Git repository, meaning that the pack is never thin. The overhead is negligible on smaller repositories, but can be comparable to network transfer on a fast connection. The only downside is that it just might break something if the user specifies a preexisting Git repository in the configuration, but that seems a bit esoteric.
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, we'd just load fetched data into memory, but that seems a bit wasteful. After all, some repositories can be quite large. Use a spooled temporary file instead when fetching repositories, and allow the customising the buffer size.
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This allows us to check progress more thoroughly.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Sep 08, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Mercurial core changed and simplified the batchable API in c424ff4807e6, breaking our base peer. This abstracts the batchable functionality into a method in `compat.py`, and simplifies the code in `gitrepo.py` a bit, removing a class that's now mostly redundant. https://phab.mercurial-scm.org/D11212
-
- Aug 27, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, Dulwich would make object files writable, which is inconsistent with Git; this test implicitly relied on that bug.
-
- Jul 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 27, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
pip install --pre mercurial~=5.9.0 doesn't work as expected, so we extract the versions using the PyPI API.
-
Dan Villiom Podlaski Christiansen authored
The mercurial-scm.org is somewhat unreliable, and only includes published changes. We want to notice breakage as soon as possible.
-
Dan Villiom Podlaski Christiansen authored
currently, the various branches use the same container images, meaning that we have to keep them compatible (hopefully, this doesn't break building tags)
-
- Jul 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Mercurial 5.8 and earlier would delete such a directory on errors, and the test accidentally relied on that behaviour. To work around that, we clone into the _current_ directory, which Mercurial never deletes. The test now reveals the incorrect behaviour, but the current design makes that difficult to address without tracking unnecessary state.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, users would have to set this manually to make long running conversions safely resumable. Now that we disregard it for clone, we should make our defaults safer for pull. The value of 1000 is essentially a compromise, as it isn't so small that it makes converting repositories with more commits than files slow, and not so large that it becomes infrequent with large and slow commits.
-