- Apr 02, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Feb 15, 2013
-
-
Takumi IINO authored
If exception is error.LookupError and running in i18n environment, below condition is always true. Because msg is translated and dosen't contain 'manifest'. if util.safehasattr(err, 'name') and 'manifest' not in msg: This patch creates a new exception class and uses it instead of string match.
-
- Apr 01, 2013
-
-
Wagner Bruna authored
-
- Mar 30, 2013
-
-
Nikolaj Sjujskij authored
This was giving the following error: % hg up 2.5-r<Tab> (eval):1: bad substitution % hg up 2.5-r
-
- Mar 29, 2013
-
-
Matt Mackall authored
-
- Mar 01, 2013
-
-
Wagner Bruna authored
-
- Feb 28, 2013
-
-
Katsunori FUJIWARA authored
-
- Mar 23, 2013
-
-
Idan Kamara authored
When the strip command is run, it calls repo.destroyed, which in turn checks if we read _phasecache, and if we did calls filterunknown on it and flushes the changes immediately. But in some cases, nothing causes _phasecache to be read, so we miss out on this and the file remains the same on-disk. Then a call to invalidate comes, which should refresh _phasecache if it changed, but it didn't, so it keeps using the old one with the stripped revision which causes an IndexError. Test written by Yuya Nishihara.
-
- Mar 19, 2013
-
-
Bryan O'Sullivan authored
-
- Mar 11, 2013
-
-
Durham Goode authored
When a rebase has conflicts and the user uses rebase --continue, the previously active bookmark was not being made active once again. With this change that bookmark is made active again, just as if the rebase had never been interrupted. This changes the rebasestate file format, but should handle old formats correctly. Since the file is transient, this is even less of a problem. Adds a test to verify the new behavior. I manually tested continuing rebases with and without an active bookmark, and with and without being on the bookmark being rebased.
-
- Mar 04, 2013
-
-
Benoit Boissinot authored
Fix version detection with recent hg versions.
-
Benoit Boissinot authored
This allows updating PyPI with just 'setup.py register' (assuming the user is an owner or maintainer of the PyPI package).
-
- Mar 01, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Feb 28, 2013
-
-
Mads Kiilerich authored
-
Mads Kiilerich authored
This makes a difference when working directory is dirty, especially when merging with a revision for which we don't have largefiles.
-
Mads Kiilerich authored
cachelfiles jumped through loops to handle merges and modified files ... but it did apparently no longer have a valid reason to do so. It should just always make sure that the largefiles referenced from the standins are present - no matter which actual largefile is stored in the working directory. If there is no standin then there is nothing to fetch. The old code usually verified the hash of all largefiles every time this function was invoked - for examply by 'update'. This change makes a trivial noop update 5-10 seconds faster on our repo (with the other 50% spent doing another unnecessary hashing of all largefiles).
-
Mads Kiilerich authored
Situations where a largefile for some reason wasn't available sometimes caused wrong largefile content and state. It has mostly been seen when interrupting download of largefiles ... and when introducing programming errors. Instead we now make sure to delete the old and wrong largefile. A missing file is a well-known error condition and much more reasonable way to handle the situation.
-
Mads Kiilerich authored
Largefiles can easily become missing - for example if it simply isn't available or the download fail. It might even be convenient to be able to work that way in some cases. But commiting missing largefiles as if they had been 'hg remove'd is plain wrong.
-
Mads Kiilerich authored
It might not have been created and it might have been removed.
-
Mads Kiilerich authored
Looking for a (potentially empty) directory was not reliable - both because it is a reasonable assumption that empty directories can be removed and because it wasn't created in all cases ... such as when pulling to an existing repository.
-
Mads Kiilerich authored
The test relied on the bug that 'pull largefiles from branchheads' didn't pull any largefiles from tip revision when it seemed like no largefiles had been checked out before.
-
Mads Kiilerich authored
The empty list was interpreted as all revisions - just like None is. The empty list is now handled explicitly.
-
Mads Kiilerich authored
Test output is changed in a case where one revision was pulled, but because of the off-by-one error it thought that 0 revisions were pulled ... and because of another bug it thus (tried to) fetch largefiles for all revisions. After this change it no longer reports failure when it failed while trying to fetch largefiles it shouldn't fetch. Largefiles that it shouldn't fetch but managed to fetch anyway will now correctly be missing later on. This change thus resolves some of unexplained test output introduced in 1e4eb1faba6e.
-
- Feb 17, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, "hg bundle --branch foo other" fails to create bundle file, if specified "foo" branch is created newly on the local repository. "hg bundle" uses "hg.addbranchrevs(repo, other, ...)" to look branch names up, even though other outgoing-like implementation uses "hg.addbranchrevs(repo, repo, ...)". In the former invocation, "other" repository recognizes such branches as unknown, so execution is aborted. This patch uses "hg.addbranchrevs(repo, repo, ..)" in "hg bundle" to bundle revisions on such branches correctly.
-
- Feb 15, 2013
-
-
Kevin Bullock authored
We explicitly redraw before echoing the message so that it simply displays at the bottom of the window. Also simplifies the message printing by using 'echomsg' (which uses 'echohl' internally) and adds the names of the software involved for improved Googleability.
-
Pierre-Yves David authored
Adds a message displayed at each vimdiff invocation: merge conflict detected, type ":cq" to abort Vimdiff is very confusing for non-vim user (not to speak about vim user confused anyway. However it is very likely that vimdiff is picked as the mergetool of choice when using the default config: - vim is available on all UNIX system. - Its one of the rare non graphical merge tools.
-
- Feb 13, 2013
-
-
Simon Heimberg authored
This lines were introduced in cd403d6d96ef and made the test fail on windows.
-
- Feb 09, 2013
-
-
Pierre-Yves David authored
The behavior without argument was not documented.
-
Pierre-Yves David authored
If there is no outgoiing changesets but we have filtered revision in outgoing.excluded We run into a filtering related crash. The excluded revision should not be there in the first place but discovery need cleanup in default, not stable.
-
- Feb 08, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Feb 05, 2013
-
-
Arne Babenhauserheide authored
Use e for edit instead.
-
- Feb 06, 2013
-
-
Pierre-Yves David authored
In its current state discovery may return (remotely) filtered elements in "common". This has usually no impact as "missing" is kept clear of filtered elements. However when the "remote" repo is a local repo (disk accessible, and directly created in memory) the incoming code takes a shortcut and directly uses the "remote" repo to generate the incoming output. When some common elements are filtered this led to a crash. We now ensure we use an unfiltered repository to generate the incoming output. This does not change the behavior as missing is clear of filtered revision. Now that we have proper low level filtering, incoming code needs a deeper cleanup but it is already planned.
-
- Feb 05, 2013
-
-
Kevin Bullock authored
Since the 'summary' view used by e.g. gitweb and monoblue shows both a changelog and a bookmarks list, the same changes are needed here as were made to the 'changelog' and 'bookmarks' web commands (56ca4443a343 and 886936ecc21b, respectively).
-
Andrej Shadura authored
It seems like the API has changed somewhere around 8.5.7, so the preferred way of getting the current theme is now [ttk::style theme use], while the deprecated (but still working) is $::ttk::currentTheme.
-
- Feb 04, 2013
-
-
Mads Kiilerich authored
-