- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- 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.
-
Dan Villiom Podlaski Christiansen authored
Given that Mercurial will delete the repository on any error, using anything more than a single transaction is a waste of resources. In fact, the only way to “recover” a partial clone using hg-git is to forcibly KILL the process. This makes us match the behaviour of Mercurial: clone isn't resumable, period, and not even inspecting the repository during the clone suggests otherwise. This currently doesn't affect the current defaults, though, which are to always use a single transaction.
-
Dan Villiom Podlaski Christiansen authored
Now that we always save the map at the end of a transaction, the previous logic for a final save is redundant.
-
Dan Villiom Podlaski Christiansen authored
By using a transaction, we can avoid unnecessary I/O and let Mercurial do whatever it does to keep things fast. This is a significant optimisation, as cloning Dulwich from Github goes from ~1m40s to ~52s on a Mac, and ~49s to ~32s on Linux.
-
- Jun 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The Git metadata files are located directly within '.hg' in the store repository. To use the vfs directly, we have to lock the working directory. The Mercurial push and pull commands — reasonably — don't do that, so without this change, we cannot save or load the map during them. Ideally, we'd move these files into the store, but that's too invasive, and would break backward compatibility rather significantly, unless we add some form of upgrade/downgrade support. Instead, we simply add them to the list of files that don't need the lock.
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
When the map save frequency is set, we would previously save it the very start of the pull. That doesn't make much sense, so we switch it one commit later to avoid the unnecessary I/O.
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
When the map save frequency is set, we would previously save it the very start of the push. That doesn't make much sense, so we switch it one commit later to avoid the unnecessary I/O.
-
Dan Villiom Podlaski Christiansen authored
for extra debuggability, log where we're saving it to as well
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The default for `hggit.use-phases` is to publish the remote HEAD and tags. We want to do this on push as well, so that pushing to e.g. `master` _immediately_ publishes the relevant changesets. However, we run into the fact that we don't actually know or store the remote HEAD anywhere, so we have to do an extra round-trip to obtain it.
-
Dan Villiom Podlaski Christiansen authored
Tags normally point to fixed commits, and the Git documentation[1] is quite explicit that you shouldn't move them around willy-nilly. In other words, they rather neatly correspond to Mercurial's public phase, hence a sensible default is to always publish them, along with head. [1] https://git-scm.com/docs/git-tag#_discussion
-
Dan Villiom Podlaski Christiansen authored
-
- May 12, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This essentially makes our behaviour match the documentation, which states that ``git.public`` refers to “a list of Git branches”. It didn't: it actually referred to a list of Mercurial changesets that we would publish on push. Previously, this would lead to a rather nonsensical situation: * The remote ``stable`` points to commit A * The local, corresponding ``stable`` bookmark points to commit B * ``git.public`` is configured to list ``stable`` * The user performs a pull. Whatever you'd expect to happen in that case, it mostly likely _wouldn't_ be for B to be published, which was what happened. Please note that this change breaks backwards compatibility; previously, having ``git.public`` point to e.g. ``default/master`` would cause that to be published. But that was always undocumented.
-
- Jun 17, 2021
-
-
Pierre-Yves David authored
This give more options to the test of the code.
-
- Jun 16, 2021
-
-
Pierre-Yves David authored
We will needs that logic for obsolescence inference, so we extract it first.
-
- Jun 15, 2021
-
-
Pierre-Yves David authored
This is a small gratuitous improvement to help other answer the question I just had to ask myself.
-
- Jun 16, 2021
-
-
Pierre-Yves David authored
The previous code and checking if we had heads. Checking for changes seems more appropriate.
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
We obtain most of these directly from Dulwich; there's no constant for remotes, though, so we add our own.
-
- May 08, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Sep 15, 2020
-
-
Dan Villiom Podlaski Christiansen authored
This is adjusted by a new option, git.prune-remotes, which is true by default.
-
- Jun 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 28, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- May 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This was broken under Python 3.
-
- May 13, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 10, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Git allows two kinds of tags: annotated and plain. Plain tags are simple refs pointing to a commit, and annotated tags point to a Tag object then pointing to the commit. The code previously assumed that all exported tags where plain tags, which would overwrite annotated tags. We recently fixed this, in cc4f3340afc9, when exporting tags from Mercurial to Git; this applies the same fix during Git discovery. Fixes #358
-
- May 12, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 26, 2020
-
-
Dan Villiom Podlaski Christiansen authored
The current behaviour is quite unhelpful, given that it either allows you to abort the conversion or generate a bogus repository. As an example, GitHub rejects anything with a `.git` in it. Instead, the new default is to issue a warning and simply discard the dangerous files. Although this might cause problems down the line, I'd much rather have those problems than just have hg-git give up. As an example of such a bogus repository, look no further than this one. c43c02cc803a committed some tests from Dulwich with nested Git repositories, and a061dce264b7 renamed them. Prior to this change, hg-git could not push its own repository to GitHub. Further more, Mercurial disallows paths containing carriage return (CR) and newline (NL) characters; as noted in the original Mercurial bug report that enabled this behaviour,[1] such paths appear for folder icons on macOS. This was reported on the list by Uwe Brauer.[2] Since Mercurial simply cannot store these files, we always either skip them or abort the conversion. [1] https://bz.mercurial-scm.org/show_bug.cgi?id=352 [2] https://groups.google.com/g/hg-git/c/Rz3oRzrMS3Q/m/RRq4AIMsBAAJ
-
- Feb 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-