- Mar 03, 2022
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
* mark it as supported * stop testing the branches with Python 2.7
-
- Dec 30, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This removes the need to set configure `receive.denyCurrentBranch` in Git, which is in part bad form, and also explicitly covered `test-push-to-head.t`. Pushing to a checked out branch in a non-bare repository is confusing, and leads to weird results in Git. More than anything, this is just a slight simplification.
-
Dan Villiom Podlaski Christiansen authored
This leads to unstable commit IDs.
-
- Jan 27, 2022
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jan 21, 2022
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jan 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jan 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Some upcoming checks access the repository created by Heptapod on the CI infrastructure; we'd rather not that fail the run.
-
- Dec 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is a potential pitfall: it is most likely, but not necessarily, a user error at some point.
-
Dan Villiom Podlaski Christiansen authored
Thorsten Kampe reported that he ran into this message in issue #376. We had some handling for this previously, but we would only handle converting commits with missing parents; this fixes it so that we also handle pushing truly missing commits rather than only when actually converting them. The previous error message was confusing and unhelpful, though, but this should make it clear what's going on. Fortunately, he _also_ provided a relatively simple way to trigger it, and as it was previously uncovered by the test suite, I added a test that triggers it!
-
Dan Villiom Podlaski Christiansen authored
`mv` on darwin — and probably other BSD-derived systems as well — prompts for whether to overwrite a non-writable file, and fails to do so in a noninteractive session. That's what the `-f` flag is for.
-
- Dec 11, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The latest version of Git, 2.34, seemed to change something with relation to the default strategy. As long as the hashes remain the same, we don't care. In addition, it seems to have some logic related to templates, and might warn if the directory doesn't exist. Suppress that.
-
- Nov 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The previous logic was kind of weird. It parsed the messages rather thoroughly, but ignored a crucial distinction: * Anything that ends with a newline is most likely a remote message. * Anything that ends with a carriage return is most likely a progress message. * Lines ending with newline always flush a progress session. Most things ending with newline are interesting, but we explicitly disregard the “totals” stuff. Things ending with carriage return are either progress, or at least something we shouldn't print.
-
- Dec 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This makes it hit more edge-cases related to force pushes.
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
We do this in both regular mode and with a suffix; the results are subtly different.
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The latest version of Git, 2.34, seemed to change something with relation to the default strategy. As long as the hashes remain the same, we don't care.
-
- Nov 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Although a nice idea, it breaks the tests with Mercurial < 5.7
-
- Nov 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Not only is this easier to view and edit, but it also avoids causing issues with coverage.
-
- Jun 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Even if a change doesn't pull any new changes, it should synchronise phases. So merely setting the phase when committing the change doesn't suffice.
-
- Nov 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, setting phases.new-commit to `secret` would trigger an error in clone: abort: filtered revision '7fe02317c63d9ee324d4b5df7c9296085162da1b' I'm not entirely sure why that happens, I didn't delve too deeply. Essentially, pulls from hg-git _should_ be draft, so I fixed that instead. The `secret` phase is for stuff neither to push to Mercurial nor Git; it does not distinguish commits based on their origin. The bug report dates from several years ago; so long ago that one might reasonably debate whether this is a bug fix or an enhancement. Since fixing old code is significantly easier on default, that's where I've put this change. This is only a partial fix, that focuses on the bug specifically; it doesn't address edge-cases where a pull might only affect phases. For clarity and documentation, I've left the incorrect behaviour in the tests. Fixes #266
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-