- 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.
-
- Jun 21, 2021
-
-
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
-
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 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
The method moved to stringutil, so lets add some compat layer for it.
-
Pierre-Yves David authored
-
- Jun 17, 2021
-
-
Pierre-Yves David authored
We will need it to test the obsolescence inference.
-
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.
-
Dan Villiom Podlaski Christiansen authored
Dulwich 0.19.3, release in June 2018, added a few string contants. While at it, adjust README to be more accurate
-
- 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.
-
- Jun 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
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.
-
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.
-
- Jun 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- May 19, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-