- Nov 19, 2021
-
-
Pierre-Yves David authored
Now that all¹ stored mtime are non ambiguous, we no longer need to apply the `need_delay` step. The need delay logic was not great are mtime gathered during longer operation could be ambiguous but younger than the `dirstate.write` call time. So, we don't need that logic anymore and can drop it This make the code much simpler. The code related to the test extension faking the dirstate write is now obsolete and associated test will be migrated as follow up. They currently do not break. [1] except the ones from `hg update`, but `need_delay` no longer help for them either. Differential Revision: https://phab.mercurial-scm.org/D11796
-
- Oct 28, 2021
-
-
Pierre-Yves David authored
The previous code was overlooking fallback when neither symlink not exec was supported. The number of "variants" is getting too high, so I am consolidating this in a single closure that should be easier to maintains. This also ensure that fallback flags are always taken into account. (they are not user code yet, but small experimentation shown that the feature was working as intended.) A a small side effect we need to check for symlink support more lazily and this show up in the test in a couple of places. Differential Revision: https://phab.mercurial-scm.org/D11728
-
- Dec 08, 2020
-
-
Matt Harbison authored
I didn't track down where this change occurred. I assume it's related to some buffering changes, and/or an explicit flush somewhere. Differential Revision: https://phab.mercurial-scm.org/D9539
-
- Nov 23, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9380
-
Martin von Zweigbergk authored
Some types of exceptions had a trailing "!" printed after the message from the exception itself. I guess some of these errors seem a little more severe (?), but it seems more likely that the inconsistency was just an oversight. Differential Revision: https://phab.mercurial-scm.org/D9378
-
- Apr 10, 2020
-
-
Jörg Sonnenberger authored
BSD-derived systems will use "ls -A" when running as root. Adjust the test cases to always use the flag and include .hg and related output as appropiately. Differential Revision: https://phab.mercurial-scm.org/D8397
-
- Oct 06, 2019
-
-
Augie Fackler authored
Done with python3.7 contrib/byteify-strings.py -i $(hg files 'set:mercurial/**.py - mercurial/thirdparty/** + hgext/**.py - hgext/fsmonitor/pywatchman/** - mercurial/__init__.py') black -l 80 -t py33 -S $(hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**" - hgext/fsmonitor/pywatchman/**') # skip-blame mass-reformatting only Differential Revision: https://phab.mercurial-scm.org/D6972
-
- Jul 12, 2019
-
-
Matt Harbison authored
The test runner doesn't always guess the right location when optional output is missing. This goes with f6540aba8e3e. Differential Revision: https://phab.mercurial-scm.org/D6640
-
- Jun 24, 2019
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6572
-
- Apr 12, 2019
-
-
Martin von Zweigbergk authored
I'm about to rewrite mergecopies() and this message will no longer be emitted then. Let's remove the message now to remove a distraction from that patch. Differential Revision: https://phab.mercurial-scm.org/D6249
-
- Mar 22, 2019
-
-
Matt Harbison authored
Most other commands support implied recursion based on file names already.
-
- Mar 14, 2019
-
-
Pierre-Yves David authored
The manifest full text cache is tightly related to the working copy. We should use the `wcache` directory for it, instead of the `cache`. Otherwise, multiple shares would keep overwriting each other cache entry and we loose its benefit. This is also more consistent with the fact this cache file is protected by `wlock`.
-
- Feb 17, 2019
-
-
Martin von Zweigbergk authored
The fix is to pass in a "subuipathfn" as we do everywhere else. Differential Revision: https://phab.mercurial-scm.org/D5978
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D5977
-
- Dec 04, 2018
-
-
Matt Harbison authored
This goes with 47e3f554df35::d5622dfe4ba3. I'm not sure if it was really expected that there would be no wcache directory if neither execbit nor symlink is supported.
-
- Nov 15, 2018
-
-
Boris Feld authored
The cache directory will be needed very quickly, so it seems simpler to create it early to make sure it has the same owner and permission than the other directory in the repository.
-
Boris Feld authored
Some cache are relevant or affected by the working copy used. So the `.hg/cache` directory is not the best place for them because multiple shared repository can end up fighting over them. To address this issue, we introduce a new 'wcache' directory to host this kind of cache. The first user are the `checkisexec` type file. These files describe property of the working copy and fit the use-case well.
-
- Nov 16, 2018
-
-
Matt Harbison authored
I ran into a problem where I tried updating to a different branch, and the process appeared to hang. It turned out that the subrepo revision wasn't available locally, and I must have originally cloned it from an `hg serve -S` on a machine that currently wasn't serving anything. It took 2+ minutes to timeout, and didn't mention what it was connecting to even then. There are a couple of other issues in this scenario too. - The repo is dirty after the failed checkout because the top level repo is updated first. We should probably make 2 passes- top down to pull everything needed, and then do an update once everything is in place. - Something must be reading .hgsubstate from wdir because if the same merge command is run after the timeout, a prompt is issued that the local and remote subrepo diverged, instead of hanging. But it lists the local version and remote version as having the same hash.
-
- Aug 05, 2018
-
-
Yuya Nishihara authored
Note that {path} in status is either relative-to-cwd or repository-absolute depending on the command argument and config knob, which can't be reproduced by using the {path|relpath} filter. The default template is updated to always use a relative path. .. bc:: ``{abspath}`` and ``{file}`` in generic templates are renamed to ``{path}``. Any ``{path}`` is a repository-absolute path. Use ``{path|relpath}`` to convert it to a filesystem path.
-
- Jun 19, 2018
-
-
Yuya Nishihara authored
Since a75d24539aba "convert: fix convert dropping p2 contents during filemap merge", wctx is not always a committablectx because the convert extension passes in repo[n] as wctx. If wctx is a committed changeset, its manifest dict shouldn't be mutated reflecting to the working directory.
-
- Jan 08, 2018
-
-
Pulkit Goyal authored
Currently we don't have a good functionality to abort the merge and tell user to do `hg update -C .` which can leads to different results if user missed the '.' and moreover does not align with other abort functionalities like rebase, shelve etc. This patch adds `hg merge --abort` which will abort the ongoing merge and take us back to the chagneset where we started from. Works in both cases when merge resulted in conflicts and when there were no conflicts. .. feature:: A `--abort` flag to merge command to abort the ongoing merge. Differential Revision: https://phab.mercurial-scm.org/D1829
-
- Dec 11, 2017
-
-
Matt Harbison authored
# skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
-
- Nov 25, 2017
-
-
Yuya Nishihara authored
Mercurial subrepos support any match patterns.
-
- Nov 07, 2017
-
-
Gregory Szorc authored
We change subrepos.allowed from a list of allowed subrepo types to a combination of a master switch and per-type boolean flag. If the master switch is set, subrepos can be disabled wholesale. If subrepos are globally enabled, then per-type options are consulted. Mercurial repos are enabled by default. Everything else is disabled by default.
-
- Nov 05, 2017
-
-
Yuya Nishihara authored
This allows us to minimize the behavior change introduced by the next patch. I have no idea which config style is preferred in UX POV, but I decided to get things done. a) list: 'allowed = hg, git, svn' b) sub option: 'allowed.hg = True' or 'allowed:hg = True' c) per-type action: 'hg = allow', 'git = abort'
-
Yuya Nishihara authored
This is an alternative workaround for the issue5730. Perhaps this is the simplest way of disabling subrepo operations. It does nothing clever, but just aborts if Mercurial starts accessing to a subrepo. I think Greg's patch is more useful since it allows us to at least check out the parent repository. However, that would be confusing if the default is flipped to checkout=False and subrepos are silently ignored. I don't like the config name 'allowed', but I couldn't get any better name.
-
- Oct 16, 2017
-
-
Matt Harbison authored
Previously, only the top level repo was shared, and then any subrepos were cloned on demand. This is problematic because commits to the parent repo would write an updated .hgsubstate to the share source, but the corresponding subrepo commit would be stuck in the local subrepo. That would prevent an update in the source repo. We already go to great lengths to avoid having inconsistent repos (e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't referenced in one of the parent's outgoing commits). Therefore, this seems like a bug fix, and there's no option to get the old behavior. I can't imagine the previous behavior was useful to anybody. There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir can be used for git subrepos, but I'll leave that to someone more familiar with git. An integer was previously being implicitly returned from commands.share(), which caused dispatch() to start crashing when changing over to returning the shared repo. All error paths appear to raise, so this can be hardcoded to success. The clone command checks for 'is None' in a similar pattern, but since hg.clone() always returns a tuple, that seems wrong? .. fix:: Issue 5675 Creating a share of a repository with a Mercurial subrepository will now share the subrepository. and .. bc:: Mercurial subrepositories are now shared instead of cloned when the parent repository is shared. This prevents dangling subrepository references in the share source. Previously shared repositories with cloned subrepositories will continue to function unchanged.
-
- Oct 12, 2017
-
-
Denis Laxalde authored
Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
-
- Aug 07, 2017
-
-
Yuya Nishihara authored
This vulnerability was fixed by the previous patch and there were more ways to exploit than using '|shellcmd'. So it doesn't make sense to reject only pipe character. Test cases are updated to actually try to exploit the bug. As the SSH bridge of git/svn subrepos are not managed by our code, the tests for non-hg subrepos are just removed. This may be folded into the original patches.
-
- Jul 31, 2017
-
-
Sean Farley authored
'ssh://' has an exploit that will pass the url blindly to the ssh command, allowing a malicious person to have a subrepo with '-oProxyCommand' which could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' is able to execute arbitrary commands. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
-
- Jul 09, 2017
-
-
Matt Harbison authored
Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.
-
- Jun 06, 2017
-
-
Pulkit Goyal authored
Currently when we have multiple heads on the same branch, update tells us that there some more heads for the current branch but does not tells us the head to which the repository has been updated to. It makes more sense showing the head we updated to and then telling there are some more heads.
-
- Jun 05, 2017
-
-
Matt Harbison authored
-
- May 25, 2017
-
-
Yuya Nishihara authored
This is an example showing how formatter can handle the --output option. git subrepo isn't supported for now.
-
- Apr 02, 2017
-
-
Matt Harbison authored
-
- Mar 20, 2017
-
-
Simon Farnsworth authored
Prompts weren't available in the else clause
-
- Jan 08, 2017
-
-
Matt Harbison authored
The extra glob in test-command-template.t caused it to say no result was reported. It used to be (within the past year), that both this and the missing glob cases could be fixed simply by editing any output in the test, and re-running it in interactive mode. But that no longer works, and I had to diff *.t against *.t.err. I didn't dig into what changed.
-
- Nov 30, 2016
-
-
Jun Wu authored
The POSIX documentation about "cp" [1] says: .... RATIONALE .... Earlier versions of this standard included support for the -r option to copy file hierarchies. The -r option is historical practice on BSD and BSD-derived systems. This option is no longer specified by POSIX.1-2008 but may be present in some implementations. The -R option was added as a close synonym to the -r option, selected for consistency with all other options in this volume of POSIX.1-2008 that do recursive directory descent. The difference between -R and the removed -r option is in the treatment by cp of file types other than regular and directory. It was implementation-defined how the - option treated special files to allow both historical implementations and those that chose to support -r with the same abilities as -R defined by this volume of POSIX.1-2008. The original -r flag, for historic reasons, did not handle special files any differently from regular files, but always read the file and copied its contents. This had obvious problems in the presence of special file types; for example, character devices, FIFOs, and sockets. .... .... Issue 6 The -r option is marked obsolescent. .... Issue 7 .... The obsolescent -r option is removed. .... (No "Issue 8" yet) Therefore it's clear that "cp -R" is strictly better than "cp -r". The issue was discovered when running tests on OS X after 0d87b1caed92. [1]: pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
-
- Nov 19, 2016
-
-
Kostia Balytskyi authored
The way default marker template was defined before this patch, the spacing before dash in conflict markes was dependent on whether changeset is a tip one or not. This is a relevant part of template: '{ifeq(tags, "tip", "", "{tags} "}' If revision is a tip revision with no other tags, this would resolve to an empty string, but for revisions which are not tip and don't have any other tags, this would resolve to a single space string. In the end this causes weirdnesses like the ones you can see in the affected tests. This is a not a big deal, but double spacing may be visually less pleasant. Please note that test changes where commit hashes change are the result of marking files as resolved without removing markers.
-
- Oct 07, 2016
-
-
Simon Farnsworth authored
Now that we present the conflict labels in prompts, it's useful to have better names than "local" and "other" for every command.
-