- Jul 01, 2019
-
-
Martin von Zweigbergk authored
I've realized only recently how many cases there are where a file is treated differently if it's considered "related" to another file (not deleted and re-added). I'll add more tests for some of these cases soon. Differential Revision: https://phab.mercurial-scm.org/D6598
-
- Jun 24, 2019
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6572
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6571
-
- Jun 30, 2019
-
-
Yuya Nishihara authored
This is modeled after std::path::Path::ancestors(). find_dirs(b"") yields b"" because Mercurial's util.finddirs() works in that way, and the test case for DirsMultiset expects such behavior.
-
- Jul 10, 2019
-
-
Matt Harbison authored
These changes correspond with f802a75da585. Differential Revision: https://phab.mercurial-scm.org/D6624
-
- Jun 27, 2019
-
-
Taapas Agrawal authored
This patch adds the support for `histedit` in `hg abort` plan. As seperate `hgaborthistedit()` function is created to handle independent calls for abortion of `histedit`. This function is then registered as `abortfunc` for state detection API. hg abort in case of `histedit` also supports ` history-editing-backup` config option. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6582
-
- Jun 23, 2019
-
-
Taapas Agrawal authored
This adds support of `rebase` to `hg abort` plan. An independent abort logic for `rebase` is created under `abortrebase()` function. For this a seperate `rebaseruntime` object is created under the function to handle an unfinished `rebasestate` and abort that using abort logic under `_prepareabortorcontinue`. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6568
-
Taapas Agrawal authored
This adds support of `graft` to `hg abort` plan. The patch creates a seperate function `cmdutil.hgabortgraft` so that abort logic for graft can be called independently. This logic is registered to the statedetection API as `abortfunc`. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6567
-
Taapas Agrawal authored
This is part of `GSoC19` project `Implement abort and continue commands`. This patch is part of the `abort plan`. This adds the basic logic for `hg abort`. This command aborts an multistep operation like graft, histedit, rebase, merge and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under `statemod`. This API is extended to support `hg abort` by adding a method to register the abort logic as a function (here `abortfunc`). Once the unfinished operation is determined the registered logic is used to abort the command. The benefit of this kind of framework is that any new extension developed can support `hg abort` by registering the command and logic under statedetection API. `hg abort` currently supports `--dry-run/-n` flag only. It is used to dry run `hg abort` Further patches sequentially add support for `graft`, `rebase`, `unshelve`, `histedit` and `merge`. Differential Revision: https://phab.mercurial-scm.org/D6566
-
- Jul 09, 2019
-
-
Augie Fackler authored
-
Taapas Agrawal authored
This patch disallows `hg merge --abort` in case an operation of higher precedence i.e unshelve, rebase, histedit are in unfinished states. This is done so as to avoid partial abort of these operations in case merge abort is called at an interrupted step. The patch adds a `cmdutil.getunfinishedstate` function which checks for operations under progress and returns a `statecheck` object for it. Differential Revision: https://phab.mercurial-scm.org/D6607
-
- Jul 08, 2019
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6622
-
- Jul 04, 2019
-
-
Taapas Agrawal authored
Differential Revision: https://phab.mercurial-scm.org/D6606
-
- Jul 08, 2019
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6616
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6615
-
Martin von Zweigbergk authored
It's unclear why the source transformer runs on hgext3rd. It's been like that since it was introduced in 1c22400db72d (mercurial: implement a source transforming module loader on Python 3, 2016-07-04), and that commit didn't say anything about it (but it says that it doesn't have "support [...] for extensions"). I find that the current handling of hgext3rd just makes it harder to convert extensions to Python 3. It makes you convert a bunch of strings passed to getattr() and kwargs[] to r'' that could otherwise have been left alone. It's also really confusing that the source transformer runs when you import the extension as "extensions.foo=", but not as "extension.foo=/some/path". I suppose there is small number of (very simple) extensions that would have worked without this patch that would now be broken. It seems okay to me to break those. Differential Revision: https://phab.mercurial-scm.org/D6614
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6621
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6620
-
Kyle Lippincott authored
This shouldn't actually change any behavior, I only noticed it since I started using KEY_UP in tests, and it was complaining when it got down to the ^L handler that initscr hadn't been called yet. Differential Revision: https://phab.mercurial-scm.org/D6619
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6618
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6617
-
- Jul 06, 2019
-
-
Taapas Agrawal authored
This patch moves `abortgraft` and `readgraft` to `cmdutil`. Various callers are updated accordingly. This is done because these serve as ulitlity functions for command `graft` and so that new functions regarding graft can be built from them. Differential Revision: https://phab.mercurial-scm.org/D6608
-
- Jun 20, 2019
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D6556
-
Kyle Lippincott authored
See issue6158 and the previous commit for examples of what might go wrong if we have some combinations of readline version and terminal and need to wrap the line. Briefly: readline may not display the beginning of the last line of the prompt, or it may print over it with the end of the prompt, making it difficult for users to know what's going on. Differential Revision: https://phab.mercurial-scm.org/D6563
-
Kyle Lippincott authored
I've chosen <40 as the target so that other languages that may have a 2x blowup in character count can still have a chance to fit into an 80 column screen. Previously, we would show a prompt like: ``` keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path? ``` On at least some systems, if readline was in use then the last line of the prompt would be wrapped strangely if it couldn't fit entirely on one line. This strange wrapping may be just a carriage return without a line feed, overwriting the beginning of the line; example (100 columns wide, 65 character filename, and yes there's 10 spaces on the end, I assume this is to handle the user inputting longest word we provide as an option, "unresolved"): ``` ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon ``` In some cases it may partially wrap onto the next line, but still be missing earlier parts in the line, such as below (60 columns wide, 65 character filename): ``` rev], or leave (u)nresolved for some/long/dir/name/that/do s/not/work/well/with/readline/file.txt? ``` With this fix, this looks like this on a 60 column screen: ``` tool vim_with_markers (for pattern some/long/dir/name/that/d oes/not/work/well/with/readline/file.txt) can't handle binar y tool meld can't handle binary tool vim_with_markers can't handle binary tool internal:merge3 can't handle binary tool merge can't handle binary no tool found to merge some/long/dir/name/that/does/not/work /well/with/readline/file.txt file 'some/long/dir/name/that/does/not/work/well/with/readli ne/file.txt' needs to be resolved. You can keep (l)ocal [working copy], take (o)ther [merge rev ], or leave (u)nresolved. What do you want to do? ``` Differential Revision: https://phab.mercurial-scm.org/D6562
-
- Jul 09, 2019
- Jul 08, 2019
-
-
Augie Fackler authored
Python 3 already does this, so skip it there. Consider the program: #include <stdio.h> int main() { FILE *f = fopen("narf", "w"); fprintf(f, "narf\n"); fclose(f); f = fopen("narf", "a"); printf("%ld\n", ftell(f)); fprintf(f, "troz\n"); printf("%ld\n", ftell(f)); return 0; } on macOS, FreeBSD, and Linux with glibc, this program prints 5 10 but on musl libc (Alpine Linux and probably others) this prints 0 10 By my reading of https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html this is technically correct, specifically: > Opening a file with append mode (a as the first character in the > mode argument) shall cause all subsequent writes to the file to be > forced to the then current end-of-file, regardless of intervening > calls to fseek(). in other words, the file position doesn't really matter in append-mode files, and we can't depend on it being at all meaningful unless we perform a seek() before tell() after open(..., 'a'). Experimentally after a .write() we can do a .tell() and it'll always be reasonable, but I'm unclear from reading the specification if that's a smart thing to rely on. This matches what we do on Windows and what Python 3 does for free, so let's just be consistent. Thanks to Yuya for the idea.
-
- Jul 06, 2019
-
-
sliquister authored
Pulkit suggested it in https://phab.mercurial-scm.org/D4379, and a discussion with Octobus people reminded me that people still use the error-prone default behavior of `hg resolve`. Differential Revision: https://phab.mercurial-scm.org/D6610
-
- Jul 04, 2019
-
-
Navaneeth Suresh authored
This is a follow-up patch to 3de4f17f4824. Differential Revision: https://phab.mercurial-scm.org/D6605
-
- Jul 01, 2019
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D6593
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D6592
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D6591
-
- Jul 03, 2019
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Jul 02, 2019
-
-
Pierre-Yves David authored
If the file has no full snapshot (eg: was always empty), `hg debugrevlog` would fails when trying to compute their average size.
-
- Jul 01, 2019
-
-
Martin von Zweigbergk authored
Before this patch, when an empty value was found in the changeset, we would get a ValueError, which would result in None being returned for addedfiles/removedfiles and p1copies/p2copies. That made 278dcb24e535 (copies: write empty entries in changeset when also writing to filelog, 2019-04-23) ineffective at helping the read path not look for copies in the filelogs. Differential Revision: https://phab.mercurial-scm.org/D6595
-
- Jun 30, 2019
-
-
Sushil Khanchi authored
Differential Revision: https://phab.mercurial-scm.org/D6590
-
- Jun 11, 2019
-
-
Pulkit Goyal authored
I don't like this patch but this is the easiest way I could fix it. There are some callers which pass name which is bytes, some pass name which is str. I just encode() that if that's str. This does makes test-paths.t pass, but I am not confident whether the whole of zeroconf will work on py3 or not. Differential Revision: https://phab.mercurial-scm.org/D6511
-
Pulkit Goyal authored
This addresses more failures related to zeroconf on py3. Differential Revision: https://phab.mercurial-scm.org/D6510
-