- 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.
-
- Oct 08, 2016
-
-
Simon Farnsworth authored
This is the last place that doesn't respect conflict labels in merge output. Teach subrepos to use subrepo merge output too.
-
- Sep 20, 2016
-
-
timeless authored
-
- Aug 03, 2016
-
-
Pierre-Yves David authored
The only remaining usage of the experimental config were enforcing bundle2 on. These are very old remains of when bundle2 was off by default. This was also useful to highlight the fact that this was a bundle2 run and that a bundle1 one was nearby. However, we want a future developer working on bundle3 to notice possible output/behavior change on these tests and take them in account. So we do not enforce bundle2 for these runs. We leave a comment around to make sure dev still notice the bundle1 version.
-
Pierre-Yves David authored
The new option will stay around. The experimental option was only meant to be temporary. We update various tests that validate both bundle1 and bundle2 version side by side. This changeset only takes care of enforcing bundle1. The other use of 'experimental.bundle2-exp=True' will be taken care of in the next changeset.
-
- Jul 27, 2016
-
-
Hannes Oldenburg authored
Previously a subrepository "sub" would cause no warnings to be issued for a file "subnot/a", if it's not present in the corresponding changeset when calling: hg cat subnot/a
-
- Jul 22, 2016
-
-
Hannes Oldenburg authored
Previously a subrepository "sub" would cause no warnings to be issued for a file "subnot/a" if it is not removed when calling: hg remove -S "subnot/a"
-
- Feb 29, 2016
-
-
Matt Harbison authored
-
- Feb 02, 2016
-
-
Pierre-Yves David authored
A concern around the user experience of Mercurial is user getting stuck on there own topological branch forever. For example, someone pulling another topological branch, missing that message in pull asking them to merge and getting stuck on there own local branch. The current way to "address" this concern was for bare 'hg update' to target the tipmost (also latest pulled) changesets and complain when the update was not linear. That way, failure to merge newly pulled changesets would result in some kind of failure. Yet the failure was quite obscure, not working in all cases (eg: commit right after pull) and the behavior was very impractical in the common case (eg: issue4673). To be able to change that behavior, we need to provide other ways to alert a user stucks on one of many topological head. We do so with an extra message after bare update: 1 other heads for branch "default" Bookmark get its own special version: 1 other divergent bookmarks for "foobar" There is significant room to improve the message itself, and we should augment it with hint about how to see theses other heads or handle the situation (see in-line comment). But having "a" message is already a significant improvement compared to the existing situation. Once we have it we can iterate on a better version of it. As having such message is an important step toward changing the default destination for update and other nicety, I would like to move forward quickly on getting such message. This was discussed during London - October 2015 Sprint.
-
- Jan 15, 2016
-
-
Ruslan Sayfutdinov authored
Add --no-commit flag to prevent it. This should make the hg user experience a little better. Some discussion can be found here: http://markmail.org/message/7jm7ro2ias6hxywy
-
- Nov 25, 2015
-
-
Siddharth Agarwal authored
Just like binary and symlink conflicts, change/delete conflicts influence the tool picked.
-
- Oct 12, 2015
-
-
Siddharth Agarwal authored
We perform all that we can non-interactively before prompting the user for input via their merge tool. This allows for a maximally consistent state when the user is first prompted. The test output changes indicate the actual behavior change happening.
-
- Oct 09, 2015
-
-
Siddharth Agarwal authored
The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
-
- Oct 12, 2015
-
-
Siddharth Agarwal authored
This means that in ms.resolve we must call merge after calling premerge. This doesn't yet mean that all premerges happen before any merges -- however, this does get us closer to our goal. The output differences are because we recompute the merge tool. The only user-visible difference caused by this patch is that if the tool is missing we'll print the warning twice. Not a huge deal, though.
-
- Oct 08, 2015
-
-
Pierre-Yves David authored
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
-
- Oct 07, 2015
-
-
Siddharth Agarwal authored
In upcoming patches we're going to present these names in the UI -- it would be good not to present deprecated names.
-
- Jul 08, 2015
-
-
Katsunori FUJIWARA authored
To detect change of a file without redundant comparison of file content, dirstate recognizes a file as certainly clean, if: (1) it is already known as "normal", (2) dirstate entry for it has valid (= not "-1") timestamp, and (3) mode, size and timestamp of it on the filesystem are as same as ones expected in dirstate This works as expected in many cases, but doesn't in the corner case that changing a file keeps mode, size and timestamp of it on the filesystem. The timetable below shows steps in one of typical such situations: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- N -1 *** - make file "f" clean N - execute 'hg foobar' - instantiate 'dirstate' -1 -1 - 'dirstate.normal("f")' N -1 (e.g. via dirty check) - change "f", but keep size N N+1 - release wlock - 'dirstate.write()' N N - 'hg status' shows "f" as "clean" N N N ---- ----------------------------------- ---- ----- ----- The most important point is that 'dirstate.write()' is executed at N+1 or later. This causes writing dirstate timestamp N of "f" out successfully. If it is executed at N, 'parsers.pack_dirstate()' replaces timestamp N with "-1" before actual writing dirstate out. Occasional test failure for unexpected file status is typical example of this corner case. Batch execution with small working directory is finished in no time, and rarely satisfies condition (2) above. This issue can occur in cases below; - 'hg revert --rev REV' for revisions other than the parent - failure of 'merge.update()' before 'merge.recordupdates()' The root cause of this issue is that files are changed without flushing in-memory dirstate changes via 'repo.commit()' (even though omitting 'dirstate.normallookup()' on changed files also causes this issue). To detect changes of files correctly, this patch writes in-memory dirstate changes out explicitly after marking files as clean in 'workingctx._checklookup()', which is invoked via 'repo.status()'. After this change, timetable is changed as below: ---- ----------------------------------- ---------------- timestamp of "f" ---------------- dirstate file- time action mem file system ---- ----------------------------------- ---- ----- ----- N -1 *** - make file "f" clean N - execute 'hg foobar' - instantiate 'dirstate' -1 -1 - 'dirstate.normal("f")' N -1 (e.g. via dirty check) ----------------------------------- ---- ----- ----- - 'dirsttate.write()' -1 -1 ----------------------------------- ---- ----- ----- - change "f", but keep size N N+1 - release wlock - 'dirstate.write()' -1 -1 - 'hg status' -1 -1 N ---- ----------------------------------- ---- ----- ----- To reproduce this issue in tests certainly, this patch emulates some timing critical actions as below: - timestamp of "f" in '.hg/dirstate' is -1 at the beginning 'hg debugrebuildstate' before command invocation ensures it. - make file "f" clean at N - change "f" at N 'touch -t 200001010000' before and after command invocation changes mtime of "f" to "2000-01-01 00:00" (= N). - invoke 'dirstate.write()' via 'repo.status()' at N 'fakedirstatewritetime.py' forces 'pack_dirstate()' to use "2000-01-01 00:00" as "now", only if 'pack_dirstate()' is invoked via 'workingctx._checklookup()'. - invoke 'dirstate.write()' via releasing wlock at N+1 (or "not at N") 'pack_dirstate()' via releasing wlock uses actual timestamp at runtime as "now", and it should be different from the "2000-01-01 00:00" of "f". BTW, this patch also changes 'test-largefiles-misc.t', because adding 'dirstate.write()' makes recent dirstate changes visible to external process.
-
- Jun 03, 2015
-
-
Matt Harbison authored
Previously, if a subrepo was added in ctx2 and then compared to another without it (ctx1), the subrepo for ctx2 was returned amongst all of the ctx1 based subrepos, since no subrepo exists in ctx1 to replace it in the 'subpaths' dict. The two callers of this, basectx.status() and cmdutil.diffordiffstat(), both compare the yielded subrepo against ctx2, and thus saw no changes when ctx2's subrepo was returned. The tests here previously didn't mention 's/a' for the 'p1()' case. This appears to have been a known issue, because some diffordiffstat() comments mention that the subpath disappeared, and "the best we can do is ignore it". I originally ran into the issue with some custom convert code to flatten a tree of subrepos causing hg.putcommit() to abort, but this new behavior seems like the correct status and diff behavior regardless. (The abort in convert isn't something users will see, because convert doesn't currently support subrepos in the official repo.)
-