- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- 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
-
- 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.
-
- Jun 21, 2021
-
-
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.
-
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.
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 18, 2021
-
-
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 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This avoids cluttering the tests data with infrastructure files, and adjust the name to be consistent with Mercurial's naming conventions.
-
- Jun 22, 2021
-
-
Pierre-Yves David 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 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This makes clear what we expect to change, and also ensures that we test the behaviour with tags.
-
- Jun 11, 2020
-
-
Aay Jay Chan authored
Added tests that show the current effects of git.public and hggit.usephases.
-
- Jun 17, 2021
-
-
Pierre-Yves David authored
We will need it to test the obsolescence inference.
-
- May 08, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
It started giving some odd errors. Personally, I'm getting a bit tired of this one; it's too finicky.
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Having it per-repository is somewhat esoteric.
-
- Sep 15, 2020
-
-
Dan Villiom Podlaski Christiansen authored
This is adjusted by a new option, git.prune-remotes, which is true by default.
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 13, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
Specifically: * "git push --quiet --set-upstream" was not quiet when setting the upstream branch configuration, which has been corrected.
-
- May 19, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Apr 16, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This was broken under Python 3.
-
- 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
-
Dan Villiom Podlaski Christiansen authored
This is mostly based on a script provided by @jmb in #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
-
- Dec 22, 2020
-
-
Dan Villiom Podlaski Christiansen authored
The doctests are hard to read & modify.
-