- 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
-
Mads Kiilerich authored
b32e55e6c3c7 introduced a crash when cloning a url without path - where util.url().path would be None. This None will now be handled as ''. clone will thus abort with 'repository / not found' as before.
-
Mads Kiilerich authored
The internal WSGI emulation in wsgicgi.py was not fully WSGI compliant and assumed that all responses sent a body. With 3fbdbeab38cc that caused a real bug when using hgweb.cgi. wsgicgi.py will now make sure headers always are sent, using the pattern from PEP 333 and similar to how it is done in c007e5c54b16.
-
- Feb 03, 2013
-
-
Siddharth Agarwal authored
dest.rev() is the same as target when a new rebase is run, but dest isn't set when rebase --continue is run. Bug introduced in 2a1fac3650a5, which fixed issue3685.
-
- Feb 01, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Jan 31, 2013
-
-
Katsunori FUJIWARA authored
-
Wagner Bruna authored
-
- Feb 01, 2013
-
-
Thomas Arendsen Hein authored
Without this, repository paths or names containing e.g. & characters or html tags yielded strange results, possibly allowing cross-site scripting attacks.
-
Matt Mackall authored
-