- Dec 05, 2020
-
-
Jörg Sonnenberger authored
The new experimental.single-head-per-branch:public-changes-only option restricts the single-head-per-branch filter to public changesets. This is useful when serving one repository with different views as publishing and non-publishing repository. Differential Revision: https://phab.mercurial-scm.org/D9525
-
- Dec 10, 2020
-
-
Martin von Zweigbergk authored
I think it was mistake to let the `-r` flag accept two revisions in `hg diff` in 98633e60067c (Support for 0, 1, or 2 diff revs, 2005-05-07). The command clearly acts on two revisions and having a single flag to indicate which those are is unclear. It got worse when it started accepting revsets as input. This patch introduces `--from` and `--to` flags, each taking a single revision and each defaulting to the working copy. That means that `hg
-
- Dec 01, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9481
-
- Oct 30, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9266
-
- Nov 08, 2020
-
-
sliquister authored
As discussed at the 5.2 sprint, replace strip extension by a core command, debugstrip. Obviously, the extension stays for backwards compatibility. As an implementation note, I moved the strip file as is into core, which is not done elsewhere, AFAIK. I could have inlined it into debugcommands, but that doesn't sound great. Differential Revision: https://phab.mercurial-scm.org/D9285
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9282
-
- Nov 02, 2020
-
-
Augie Fackler authored
-
- Oct 29, 2020
-
-
Martin von Zweigbergk authored
The same procedure as every year^Wcycle. Differential Revision: https://phab.mercurial-scm.org/D9263
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9258
-
- Oct 17, 2020
-
-
Yuya Nishihara authored
-
- Sep 21, 2020
-
-
Martin von Zweigbergk authored
We have very few callers left that call the low-level `merge.update()` function. I think it's time to make it private. I'll remove the remaining callers in coming patches, except for one call from the `rebase` module. I hope to eventually fix that too, but it's more complex because it requires teaching `merge.graft()` to work with a dirty working copy. Differential Revision: https://phab.mercurial-scm.org/D9065
-
- Jul 28, 2020
-
-
Martin von Zweigbergk authored
I had previously only added support for `--at-rev` to `hg cp`, but not to `hg mv`. This patch adds that support. Just like for `hg cp`, it marks the destination as copied from the source, and doesn't care if the source file still exists (because it only supports the `-A` mode, aka "don't touch files" mode). It works whether or not the source file still exists. This matches the behavior of `hg mv -A` in the working copy. Differential Revision: https://phab.mercurial-scm.org/D8840
-
Martin von Zweigbergk authored
The same procedure as every year^Wcycle. Differential Revision: https://phab.mercurial-scm.org/D8839
-
- Jul 20, 2020
-
-
Manuel Jacob authored
After having written the notes, I realized that the added points contain changes that were part of the 5.4.2 release. These were never included in any release notes. I asked on IRC whether they should be added to this file or not, but didn’t get an answer to this question. If they should not be added here, I can remove them. Differential Revision: https://phab.mercurial-scm.org/D8770
-
Manuel Jacob authored
The two points were written by me. For some reason, I missed the fact that the other points were indented by one space. Differential Revision: https://phab.mercurial-scm.org/D8769
-
Manuel Jacob authored
Differential Revision: https://phab.mercurial-scm.org/D8768
-
- Jul 18, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D8767
-
- Jun 21, 2020
-
-
Jörg Sonnenberger authored
The new REQUIREDRAM option allows a client to skip bundles it isn't expected to handle well, e.g. without swapping. This allows a fallback path to be provided e.g. using zstd level 10 instead of 22. Differential Revision: https://phab.mercurial-scm.org/D8645
-
- Jun 04, 2020
-
-
Manuel Jacob authored
The more flexible command was used recently while finding a solution for a buffering bug (eventually fixed in f9734b2d59cc (the changeset description uses a different benchmark)). In comparison to the previous version, the new version is much more flexible. While using it, the focus was on testing small writes. For this reason, by default it calls ui.write() 100 times with a single byte plus one newline byte, for 100 lines. To get the previous behavior, run `hg perfwrite --nlines=100000 --nitems=1 --item='Testing write performance' --batch-line`.
-
- May 30, 2020
-
-
sliquister authored
I think the rust work may have been mentioned in the release notes, but if so only in passing, and not as an invitation to try it out. I think the next version is a decent time to do this, because the rust doesn't come with performance regressions AFAIK, speeds up status noticeably when it applies, which is the case for most invocations of status, and doesn't have the undesirable restriction of regex around empty patterns anymore. I am cheating a bit, because I'm giving numbers for `hg status` in mozilla-central, but they have one hgignore pattern that uses lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took out as it would cause a fallback to python when unknown files are requested. But it seems that they could express their hgignore differently if they were so inclined. Not sure if there are limitation other than linux-only that I am not thinking of but would be worth mentioning upfront, to avoid disappointing users? Differential Revision: https://phab.mercurial-scm.org/D8604
-
Manuel Jacob authored
This ensures that Mercurial never downgrades the minimum TLS version from TLS 1.1+ to TLS 1.0+ and enables us to remove that compatibility code. It is reasonable to expect that distributions having Python 2.7.9+ or having backported modern features to the ssl module (which we require) have a OpenSSL version supporting TLS 1.1 or TLS 1.2, as this is the main reason why distributions would want to backport these features. TLS 1.1 and TLS 1.2 are often either both enabled or both not enabled. However, both can be disabled independently, at least on current Python / OpenSSL versions. For the record, I contacted the CPython developers to remark that unconditionally defining ssl.PROTOCOL_TLSv1_1 / ssl.PROTOCOL_TLSv1_2 is problematic: https://github.com/python/cpython/commit/6e8cda91d92da72800d891b2fc2073ecbc134d98#r39569316
-
Manuel Jacob authored
-
- May 18, 2020
-
-
Augie Fackler authored
There's already some pretty reasonable encapsulation here, but I want to make the mergestate storage a property of the context so memctx instances can do a reasonable thing. This is the first step in a reshuffle to make that easier. Differential Revision: https://phab.mercurial-scm.org/D8550
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D8549
-
Martin von Zweigbergk authored
This is the same thing as we've done for the previous few releases. Differential Revision: https://phab.mercurial-scm.org/D8546
-
- Mar 13, 2020
-
-
Martin von Zweigbergk authored
Same reasoning as for the previous patch. Rebase has worked well with `--base 'A + B'` since 51e7c83e05ee (rebase: calculate ancestors for --base separately (issue5420), 2016-11-28). Differential Revision: https://phab.mercurial-scm.org/D8293
-
Martin von Zweigbergk authored
I think it's a little surprising that `hg rebase -s A -s B` rebases only `B::` and ignores `A`. That's because the `-s` flag is not a repeated flag. This patch makes it a repeated flag. Differential Revision: https://phab.mercurial-scm.org/D8292
-
- Feb 29, 2020
-
-
Pulkit Goyal authored
This introduces a new flag to pull command `--confirm` and also a config option named `pull.confirm` which if used will prompt user describing changes which are pulled and asking whether to accept them or not. Differential Revision: https://phab.mercurial-scm.org/D8200
-
- Feb 28, 2020
-
-
Martin von Zweigbergk authored
If the mergestate has resolved conflicts and a commit is successfully created (either because there are changes in the working copy or because ui.allowemptycommit=yes), we will also clear the merge state. However, if the working copy is clean (and ui.allowemptycommit=no), we leave the mergestate there. The user may notice it in `hg resolve -l` output (but not in `hg status -v` output). It's not clear how the user should clear it, but probably via `hg co -C .`. It's also quite likely that they won't even notice it and it will get cleared by a later `hg commit` (of unrelated changes). This patch makes it so that `hg commit` also clears resolved merge conflicts even if the command doesn't end up writing a commit because the working copy was empty. That's probably a little weird (commands that abort should generally avoid changing the repo), but it still seems mostly harmless, and it reduces the risk of more bugs like https://bz.mercurial-scm.org/show_bug.cgi?id=5494. I just ran into a version of that bug in the Evolve extension and that's what triggered this series. Differential Revision: https://phab.mercurial-scm.org/D8196
-
- Jan 24, 2020
-
-
Martin von Zweigbergk authored
Many callers already have a repo, so we might as well pass that. `merge.update()` will look up the context object later. This patch is part of making it so we pass around the context object all the way down instead. I also removed the `repo` argument since it can be retrieved from the context. Differential Revision: https://phab.mercurial-scm.org/D7999
-
- Feb 26, 2020
-
-
sliquister authored
The motivation is simply to make hg work better out of the box. This is a slight backwards compatibility break, because client extensions could have assumed that the list of heads the client sees during discovery will be the list of heads during the entirety of the push. It seems unlikely to matter, and not worth mentioning. There's a fair amount of diff in tests, but this is just due to sending a few more bytes on the wire, except for test-acl.t. The extra "invalid branch cache" lines in test-acl.t don't seem to indicate a problem: the branchcache now get computed during the bundle application (because of the check:updated-heads bundle part), but doesn't get rolled back when transactions rollback, thus causing a message in the next operation computing the branch cache. Before this change, I assume the branchcache was only computed on transaction commit, so not computed at all when the transactions roll back, thus no messages. Differential Revision: https://phab.mercurial-scm.org/D8202
-
Martin von Zweigbergk authored
The only caller that passed a value for either `force` or `mergeforce` passed the same value for both, so let's simplify the interface by accepting only `force`. Differential Revision: https://phab.mercurial-scm.org/D8167
-
- Feb 14, 2020
-
-
Martin von Zweigbergk authored
Our IntelliJ team wants to be able to read the merge state in order to help the user resolve merge conflicts. They had so far been reading file contents from p1() and p2() and their merge base. That is not ideal for several reasons (merge base is not necessarily the "graft base", renames are not handled, commands like `hg update -m` is not handled). It will get especially bad as of my D7827. This patch makes the output s a templated. I haven't bothered to make it complete (e.g. merge driver states are not handled), but it's probably good enough as a start. I've done a web search for "debugmergestate" and I can't find any indication that any tools currently rely on its output. If it turns out that we get bug reports for it once this is released, I won't object to backing this patch out on the stable branch (and then perhaps replace it by a separate command, or put it behind a new flag). The changes in test-backout.t are interesting, in particular this: ``` - other path: foo (node not stored in v1 format) + other path: (node foo) ``` I wonder if that means that we actually read v1 format incorrectly. That seems to be an old format that was switched away from in 2014, so it doesn't matter now anyway. Differential Revision: https://phab.mercurial-scm.org/D8120
-
- Feb 26, 2020
-
-
Valentin Gatien-Baron authored
It appears a conflict resolution went wrong. Differential Revision: https://phab.mercurial-scm.org/D8151
-
Pierre-Yves David authored
I updated the changeset, but forgot to phabsend apparently. Differential Revision: https://phab.mercurial-scm.org/D8165
-
- Feb 14, 2020
-
-
sliquister authored
Before this change, such bookmarks are write-only: a client can push them but not pull/read them. And because these bookmark can't be read, even pushes are limited (for instance trying to delete such a bookmark fails with a vanilla client because the client thinks the bookmark is neither on the local nor the remote). This change makes the server refuses such bookmarks, and for earlier errors, makes the client refuse to send them. I think the change of behavior is acceptable because I think this is a bug in push/pull, and I don't think we change the behavior of `hg unbundle`, because it doesn't seem that `hg bundle` ever store bookmarks (and even if it did, it would seem weird anyway to try to send divergent bookmarks). Differential Revision: https://phab.mercurial-scm.org/D8117
-
- Feb 15, 2020
-
-
sliquister authored
`hg push -f -B remote-only-bookmark` can raise server-side in `bookmarks._del` (specifically in `self._refmap.pop(mark)`), if the remote-only bookmark got deleted concurrently. Fix this by simply not deleting the non-existent bookmark in that case. For avoidance of doubt, refusing to delete a bookmark that doesn't exist when the push starts is taking care of elsewhere; no change of behavior there. Differential Revision: https://phab.mercurial-scm.org/D8124
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D8123
-
- Dec 20, 2019
-
-
Martin von Zweigbergk authored
The simplest way I'm aware of to mark a file as copied/moved after committing is this: hg uncommit --keep <src> <dest> # <src> needed for move, but not copy hg mv --after <src> <dest> hg amend This patch teaches `hg copy` a `--at-rev` argument to simplify that into: hg copy --after --at-rev . <src> <dest> In addition to being simpler, it doesn't touch the working copy, so it can easily be used even if the destination file has been modified in the working copy. Differential Revision: https://phab.mercurial-scm.org/D8035
-
- Jan 28, 2020
-
-
Martin von Zweigbergk authored
The simplest way I'm aware of to unmark a file as copied after committing is this: hg uncommit --keep <dest> hg forget <dest> hg add <dest> hg amend This patch teaches `hg copy --forget` a `-r` argument to simplify that into: hg copy --forget --at-rev . <dest> In addition to being simpler, it doesn't touch the working copy, so it can easily be used even if the destination file has been modified in the working copy. I'll teach `hg copy` without `--forget` to work with `--at-rev` next. Differential Revision: https://phab.mercurial-scm.org/D8030
-