- May 15, 2015
-
-
Yuya Nishihara authored
Instead of keeping 'onlypost' as a method, this patch rewrites it to 'only' function. This way, 'x%' always has the same weight as 'only(x)'.
-
- May 10, 2015
-
-
Jordi Gutiérrez Hermoso authored
The check of the inrebase function was not correct, and it failed to consider the situation in which nothing has been rebased yet, *and* the working dir had been updated away from the initial revision. But this is easy to fix. Given the rebase state, we know exactly where we should be standing: on the first unrebased commit. We check that instead. I also took the liberty to rename the function, as "inrebase" doesn't really describe the situation: we could still be in a rebase state yet the user somehow forcibly updated to a different revision. We also check that we're in a merge state, since an interrupted merge is the only "safe" way to interrupt a rebase. If the rebase got interrupted by power loss or whatever (so there's no merge state), it's still safer to not blow away the working directory.
-
Jordi Gutiérrez Hermoso authored
The fix for issue4009, namely fe78eb7bcca0, introduced issue4661. Let's make sure that the fix for issue4661 will not reintroduce issue4009.
-
- May 08, 2015
-
-
Pierre-Yves David authored
Otherwise variable set for the real test run interfere with the test runner tests.
-
- May 01, 2015
-
-
Durham Goode authored
If histedit failed after all the rules were complete (for instance, if there was an exception in the cleanup phase), you couldn't --continue because it was unable to pop a rule. Let's just skip the rule execution phase of --continue if there are no more rules.
-
Durham Goode authored
If the histedit backupfile was None (like if evolve is enabled) it would get serialized as 'None' into the state file. Later if the histedit was aborted and the top most commit was unreachable (ex: if it was obsolete or stripped), histedit would try to unbundle the backupfile and try to read .hg/None. This fixes it to not serialize None. Since it only happens with evolve, I'm not sure how to add test coverage here.
-
- May 06, 2015
-
-
Yuya Nishihara authored
Since fdf7794be41d, column headers are wrapped by <thead> element, so the first and only <tbody> contains changelog data. I got the following error without this patch: Uncaught TypeError: Cannot read property 'lastElementChild' of null scrollHandler @ mercurial.js:375
-
Gregory Szorc authored
It was reported that enabling pager without color could cause a hang. Inserting print statements revealed that the callbacks in extensions._aftercallbacks were being invoked twice. extensions.loadall can be called multiple times. If entries in extensions._aftercallbacks linger between calls, this could result in double execution of the callbacks. This can lead to unwanted behavior. The reproduce steps in the bug seem to only occur when the output of a command is less than the size of the current screen. This is not something that can easily be tested. I verified the test case works with this patch and that pager and color interaction continues to work. Since we have no existing automated tests for pager, this sadly appears to be the best testing I can do.
-
- May 04, 2015
-
-
Yuya Nishihara authored
Because double backslashes are processed as a string escape sequence, '\\{' should start the template syntax. On the other hand, r'' disables any sort of \-escapes, so r'\{' can go either way, never start the template syntax or always start it. I simply chose the latter, which means r'\{' is the same as '\\{'.
-
Yuya Nishihara authored
This patch brings back pre-2.8.1 behavior. The result of parsestring() is stored in templater's cache, t.cache, and then it is parsed as a template string by compiletemplate(). So t.cache should keep an unparsed string no matter if it is sourced from config value. Otherwise backslashes would be processed twice. The test vector is borrowed from 64b4f0cd7336.
-
- May 05, 2015
-
-
Durham Goode authored
test-histedit-edit was broken because it relied on the HGEDITOR script being executable. Instead, lets just execute 'sh' and pass it the script to run. This seems to be the pattern followed in other tests.
-
Matt Harbison authored
The previous behavior when archiving a subrepo 's' on Windows was to internally name the file under it 's\file', due to the use of vfs.reljoin(). When printing the file list from the archive on Windows or Linux, the file was named 's\\file'. The archive extracted OK on Windows, but if the archive was brought to a Linux system, it created a file named 's\file' instead of a directory 's' containing 'file'. *.zip format achives seemed not to have the problem, but this was definitely an issue with *.tgz archives. Largefiles actually got this right, but a test is added to keep this from regressing. The subrepo-deep-nested-change.t test was repurposed to archive to a file, since there are several subsequent tests that archive to a directory. The output change is losing the filesystem prefix '../archive_lf' and not listing the directories 'sub1' and 'sub1/sub2'.
-
- Apr 22, 2015
-
-
Durham Goode authored
--edit-plan was completely broken from the command line because it used an old api that was not updated (it would crash with a stack trace). Let's update it and add tests to catch this.
-
- Apr 30, 2015
-
-
Yuya Nishihara authored
117b9a101f71 introduced the EXPERIMENTAL marker, so we should use it consistently.
-
- Apr 20, 2015
-
-
Alexander Drozdov authored
The patch solves two issues: 1. id(unknown_full_hash) aborts, but id(unknown_short_hash) doesn't 2. id(40byte_tag_or_bookmark) returns tagged/bookmarked revision, but id(non-40byte_tag_or_bookmark) doesn't After the patch: 1. id(unknown_full_hash) doesn't abort 2. id(40byte_tag_or_bookmark) returns empty set
-
- May 03, 2015
-
-
Yuya Nishihara authored
"date information" is somewhat obscure, but we call it that way in templatekw.showdate().
-
Siddharth Agarwal authored
One case where that would happen is while trying to resolve a subrepo, if the path to the subrepo was actually a broken symlink. This bug was exposed by an hg-git test.
-
- May 01, 2015
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
With "dash" (as "/bin/sh" on Debian GNU/Linux), command execution in "ENV=val foo bar" style doesn't work as expect in test script files, if "foo" is user-defined function: it works fine, if "foo" is existing commands like "hg". 09049042ab99 introduced tests for HGPLAIN and HGPLAINEXCEPT into test-revset.t, and all of them are in such style. This patch doesn't: - add explicit unsetting for HGPLAIN and HGPLAINEXCEPT they are already introduced by 09049042ab99 - write assignment and exporting in one line "ENV=val; export ENV" for two or more environment variables in one line causes failure of test-check-code-hg.t: it is recognized as "don't export and assign at once" unfortunately.
-
Matt Harbison authored
The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
-
Katsunori FUJIWARA authored
According to recent "filectx.data()" implementation, "censor.policy" should be configured as "ignore" to ignore error at censored file: "censor.allow" seems outdated name.
-
- Apr 30, 2015
-
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
-
- Apr 29, 2015
-
-
Wagner Bruna authored
-
- Apr 30, 2015
-
-
Ryan McElroy authored
-
Matt Harbison authored
The '~' in the bug report is being expanded to a path with Windows style slashes before being passed to shellquote() via util.shellquote(). But shlex.split() strips '\' out of the string, leaving an invalid path in dispatch.aliasargs(). This regressed in 1642eb429536. For now, the tests need to be conditionalized for Windows (because those paths are quoted). In the future, a more complex regex could probably skip the quotes if all component separators are double '\'. I opted to glob away the quotes in test-rename-merge2.t and test-up-local-change.t (which only exist on Windows), because they are in very large blocks of output and there are way too many diffs to conditionalize with #if directives. Maybe the entire path should be globbed away like the following paths in each changed line. Or, letting #if directives sit in the middle of the output as was mentioned a few months back would work too. Unfortunately, I couldn't figure out how to test the specific bug. All of the 'hg serve' tests have a #require serve declaration, causing them to be skipped on Windows. Adding an alias for 'expandtest = outgoing ~/bogusrepo' prints the repo as '$TESTTMP/bogusrepo', so the test runner must be changing the environment somehow.
-
Matt Harbison authored
The ability to set the exec bit on Windows would be real handy for this test..
-
Siddharth Agarwal authored
ui.plain() is supposed to disable config options that change the UI to the detriment of scripts. As the test demonstrates, revset aliases can actually override builtin ones, just like command aliases. Therefore I believe this is a bugfix and appropriate for stable.
-
- Apr 29, 2015
-
-
Yuya Nishihara authored
This avoids the following error that happened if base revision of bundle file was hidden. bundlerevlog needs it to construct revision texts from bundle content as revlog.revision() does. File "mercurial/context.py", line 485, in _changeset return self._repo.changelog.read(self.rev()) File "mercurial/changelog.py", line 319, in read text = self.revision(node) File "mercurial/bundlerepo.py", line 124, in revision text = self.baserevision(iterrev) File "mercurial/bundlerepo.py", line 160, in baserevision return changelog.changelog.revision(self, nodeorrev) File "mercurial/revlog.py", line 1041, in revision node = self.node(rev) File "mercurial/changelog.py", line 211, in node raise error.FilteredIndexError(rev) mercurial.error.FilteredIndexError: 1
-
Matt Harbison authored
There were 2 test failures in 3.4-rc when running test-hook.t with the largefiles extension enabled. For context, the first is a commit hook: @@ -618,9 +621,9 @@ $ echo 'update = hg id' >> .hg/hgrc $ echo bb > a $ hg ci -ma - 223eafe2750c tip + d3354c4310ed+ $ hg up 0 - cb9a9f314b8b + 223eafe2750c+ tip 1 files updated, 0 files merged, 0 files removed, 0 files unresolved make sure --verbose (and --quiet/--debug etc.) are propagated to the local ui In both cases, largefiles acquires the wlock before calling into core, which also acquires the wlock. The first case was fixed in 57f1dbc99631 by ensuring the hook only runs after the lock has been fully released. The full release is important, because that is what writes dirstate to the disk, allowing external hooks to see the result of the update. This simply changes how the update hook is called, so that it too is deferred until the lock is finally released. There are many uses of mergemod.update(), but in terms of commands, it looks like the following commands take wlock while calling mergemod.update(), and therefore will now have their hook fired at a later time: backout, fetch, histedit, qpush, rebase, shelve, transplant Unlike the others, fetch immediately unlocks after calling update(), so for all intents and purposes, its hook invocation is not deferred (but the external hook still sees the proper state).
-
Katsunori FUJIWARA authored
There is no code path handling ".hgcensored" in Mercurial source tree. This meaningless explanation may make users misunderstand about censor.
-
Yuya Nishihara authored
If v = -INT_MAX - 1, -v would exceed INT_MAX. I don't think this would cause problems such as issue4627, but we can't blame it as a compiler bug because signed integer overflow is undefined in C.
-
Pierre-Yves David authored
The current bundle2 processing was capturing all output. This is nice as it provide better meta data about what output what, but this was changing two things: 1) adding a prefix "remote: " to "other" output during local push (issue4613) 2) local and ssh push does not provide real time output anymore (issue4615) As we are unsure about what form should be used in (1) and how to solve (2) we disable output capture in this two cases. Output capture can be forced using an experimental option.
-
- Feb 03, 2015
-
-
Matt Harbison authored
With many commands accepting a '-S' or an explicit path to trigger recursing into subrepos, it seems that --hidden needs to be propagated too. Unfortunately, many of the subrepo layer methods discard the options map, so passing the option along explicitly isn't currently an option. It also isn't clear if other filtered views need to be propagated, so changing all of those commands may be insufficient anyway. The specific jam I got into was amending an ancestor of qbase in a subrepo, and then evolving. The patch ended up being hidden, and outgoing said it would only push one unrelated commit. But push aborted with an 'unknown revision' that I traced back to the patch. (Odd it didn't say 'filtered revision'.) A push with --hidden worked from the subrepo, but that wasn't possible from the parent repo before this. Since the underlying problem doesn't actually require a subrepo, there's probably more to investigate here in the discovery area. Yes, evolve + mq is not exactly sane, but I don't know what is seeing the hidden revision. In lieu of creating a test for the above situation (evolving mq should probably be blocked), the test here is a marginally useful case where --hidden is needed in a subrepo: cat'ing a file in a hidden revision. Without this change, cat aborts with: $ hg --hidden cat subrepo/a skipping missing subrepository: subrepo [1]
-
- Apr 28, 2015
-
-
Matt Harbison authored
When passing a --rev, 'hg incoming -S' previously suffered from the same output truncation or abort that was fixed for 'hg outgoing -S' in the previous patch, for the same reasons. Unlike push, subrepos are currently only pulled when the outer repo is updated, not when the outer repo is pulled. That makes matching 'hg pull' behavior impossible. Listing all incoming csets in the subrepo seems like the most useful behavior, and is consistent with 'hg outgoing -S'.
-
Matt Harbison authored
The previous behavior didn't reflect what would actually be pushed- push will ignore --rev and --branch in the subrepo and push everything. Therefore, 'push -r {rev}' would not list everything, unless {rev} was also the revision of the subrepo's tip. Worse, if a hash was passed in, the command would abort because that hash would either not be in the outer repo or not in the subrepo.
-
Matt Harbison authored
The functionality was added in a48b65ab428d.
-
- Apr 27, 2015
-
-
Laurent Charignon authored
While fixing issue4304: "record: allow editing new files" we introduced changes in record/crecord. These changes need to be matched with changes in any command using record. Revert is one of these commands and the changes have not been made for this release. Therefore, revert -i should be an experimental feature for this release.
-
Laurent Charignon authored
While fixing issue4304: "record: allow editing new files" we introduced changes in record/crecord. These changes need to be matched with changes in any command using record. Shelve is one of these commands and the changes have not been made for this release. Therefore, shelve -i should be an experimental feature for this release.
-