- Jan 26, 2022
-
-
Dan Villiom Podlaski Christiansen authored
That one was merged into core in 1.8, or something like that...
-
- Jan 21, 2022
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 27, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
One of the tests was legitimately broken in the meantime.
-
- Dec 30, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
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!
-
- Dec 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 17, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Some Mercurial APIs return passwords as unicode strings, others as byte strings. I've given up trying to understand this, but let's just assume it's either a Unicode string, or a byte string using UTF-8. Fixes: #360
-
Dan Villiom Podlaski Christiansen authored
Some Mercurial APIs return passwords as unicode strings, others as byte strings. I've given up trying to understand this, but let's just assume it's either a Unicode string, or a byte string using UTF-8. Fixes: #360
-
- 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
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- May 03, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 16, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This fixes storing passwords using the credentials extension I wrote.[1] [1] https://foss.heptapod.net/mercurial/hg-credentials
-
Dan Villiom Podlaski Christiansen authored
This fixes storing passwords using the credentials extension I wrote.[1] [1] https://foss.heptapod.net/mercurial/hg-credentials
-
- 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
-
- May 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This used to be for compatibility with old versions of Mercurial, but in practice it just hides the transaction.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is an area where we have no choice but diverging from stock Mercurial, as Git does not allow anonymous heads. We can only push something that has either a bookmark or a tag. In order to lessen confusion for users, we output a message inspired by Mercurial's (ignoring %d secret commits) — which serves a similar purpose.
-
- Nov 03, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
I think this was added in Mercurial 2.1, or something.
-
- Oct 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
By default, Mercurial shows the last 20 characters of the current item, but commits are usually shortened from the front.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
Generally speaking, Mercurial refers to commits as “changesets”. And mention how many we're processing while at it.
-