- Sep 30, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, "rebase --abort"/"--continue" may fail, when rebase state is inconsistent: for example, the root of rebase destination revisions recorded in rebase state file is already stripped manually. Mercurial earlier than 2.7 allows users to do anything other than starting new rebase, even though current rebase is not finished or aborted yet. So, such inconsistent rebase states may be left and forgotten in repositories. This patch catches RepoLookupError at restoring rebase state for abort/continue, and treat such state as "broken".
-
Katsunori FUJIWARA authored
Mercurial earlier than 2.7 allows users to do anything other than starting new histedit, even though current histedit is not finished or aborted yet. So, unfinished (and maybe inconsistent now) histedit states may be left and forgotten in repositories. Before this patch, histedit extension shows the message below, when it detects such inconsistent state: abort: REV is not an ancestor of working directory (update to REV or descendant and run "hg histedit --continue" again) But this message is incorrect, unless old Mercurial is re-installed, because Mercurial 2.7 or later disallows users to update the working directory to another revision. This patch changes the hint message to suggest "hg histedit --abort".
-
Pierre-Yves David authored
A `unfilteredpropertycache` is a kind of `propertycache` used on `localrepo` to unsure it will always be run against unfiltered repo and stored only once. As the cached value is never stored in the repoview instance, the descriptor will always be called. Before this patch such calls always result in a call to the `__get__` method of the `propertycache` on the unfiltered repo. That was recomputing a new value on every access through a repoview. We can't prevent the repoview's `unfilteredpropertycache` to get called on every access. In that case the new code makes a standard attribute access to the property. If a value is cached it will be used. The `propertycache` test file have been augmented with test about this issue.
-
Pierre-Yves David authored
Propertycache used standard attribute assignment. In the repoview case, this assignment was forwarded to the unfiltered repo. This result in: (1) unfiltered repo got a potentially wrong cache value, (2) repoview never reused the cached value. This patch replaces the standard attribute assignment by an assignment to `objc.__dict__` which will bypass the `repoview.__setattr__`. This will not affects other `propertycache` users and it is actually closer to the semantic we need. The interaction of `propertycache` and `repoview` are now tested in a python test file.
-
- Oct 01, 2013
-
-
Wagner Bruna authored
-
- Sep 30, 2013
-
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
Before this patch, if there are multiple roots in "--outgoing" revisions, result of "histedit --outgoing" depends on the parent of the working directory. It succeeds only when the parent of the working directory is a descendant of the oldest root in "--outgoing" revisions, and fails otherwise. It seems to be ambiguous and difficult for users. This patch makes "histedit --outgoing" abort if there are multiple roots in "--outgoing" revisions always.
-
Martin Schröder authored
-
Martin Schröder authored
-
- Sep 24, 2013
-
-
Wagner Bruna authored
-
- Sep 23, 2013
-
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
Before this patch, "hg help -k KEYWORD" fails, if there is the extension of which name includes ".", because "extensions.load()" invoked from "help.topicmatch()" fails to look such extension up, even though it is already loaded in. "help.topicmatch()" invokes "extensions.load()" with the name gotten from "extensions.enabled()". The former expects full name of extension (= key in '[extensions]' section), but the latter returns names shortened by "split('.')[-1]". This difference causes failure of looking extension up. This patch adds "shortname" argument to "extensions.enabled()" to make it return shortened names only if it is True. "help.topicmatch()" turns it off to get full name of extensions. Then, this patch shortens full name of extensions by "split('.')[-1]" for showing them in the list of extensions. Shortening is also applied on names gotten from "extensions.disabled()" but harmless, because it returns only extensions directly under "hgext" and their names should not include ".".
-
- Sep 20, 2013
-
-
Wojciech Lopata authored
Previously basecache was incorrectly initialized before adding the first revision from a changegroup. Basecache value influences when full revisions are stored in revlog (when using generaldelta). As a result it was possible to generate a generaldelta-revlog that could be bigger by arbitrary factor than its non-generaldelta equivalent.
-
- Sep 07, 2013
-
-
Sean Farley authored
-
- Sep 18, 2013
- Sep 07, 2013
-
-
Antoine Pitrou authored
Somewhere before 2.7, a change [ec896f9e8894] was committed that entailed a large performance regression when bundling (and therefore remote cloning) repositories. For each file in the repository, it would recompute the set of needed changesets even though it is the same for all files. This computation would dominate bundle runtimes according to profiler output (by 10x or more).
-
- Aug 05, 2013
-
-
Alexander Plavin authored
Some changesets can be wrongly reported as matched by this predicate due to searching in a string joined with spaces and not individually. A test case added, which fails without this fix.
-
- Sep 03, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Aug 28, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, tag overwriting history is not written into tag cache file ".hg/cache/tags". This may give higher priority to local tag than global one, even if the former is overwritten by the latter, because tag overwriting history is used to compare priorities of them (as "rank"). In such cases, "hg tags" invocations using tag cache file shows incorrect tag information. This patch writes tag overwriting history also into tag cache file.
-
- Aug 26, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, there is no explicit description that argument is treated as the URL of the destination repository when "--outgoing" is specified. This patch adds description about "histedit --outgoing" to command help of it.
-
Katsunori FUJIWARA authored
Before this patch, there is no explicit description that histedit edits changesets between specified ancestor and the parent of the working directory: users may notice it by error message "REV is not an ancestor of working directory". This patch adds description about basic histedit function to command help of it. This patch uses term "ancestor" instead of "parent", because it seems to be more suitable, and almost all (error) messages already use it.
-
- Sep 03, 2013
-
-
Bryan O'Sullivan authored
We handled these correctly with all rev-specifying options except, somehow, -r/--rev.
-
- Aug 02, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Kevin Bullock authored
This makes `hg pull --update` behave the same wrt the active bookmark as `hg pull && hg update` does as of 2096e025a728. A helper function, bookmarks.calculateupdate, is added to prevent code duplication between postincoming and update.
-
Matt Mackall authored
-
- Aug 01, 2013
-
-
Wagner Bruna authored
-
- Jul 31, 2013
-
-
Katsunori FUJIWARA authored
-
- Aug 02, 2013
-
-
Matt Mackall authored
Similar to issue4009, 2.7 will force people to abort histedits before doing interesting things. Without this fix, people with histedit sessions they wandered away from before upgrading to 2.7 could clobber their working copy for no reason.
-
- Aug 01, 2013
-
-
Matt Mackall authored
With this, all aborts will succeed in removing the state, rather than leaving the user in 'what do I do now?' limbo.
-
Matt Mackall authored
This causes us to simply discard the rebase state.
-
Matt Mackall authored
-
- Jul 26, 2013
-
-
Wojciech Lopata authored
Make push -r/-B update only these bookmarks that point to pushed revisions or their ancestors, so we can be sure that commit pointed by bookmark is present in the remote reposiory. Previously push tried to update all shared bookmarks.
-
- Jul 28, 2013
-
-
Matt Mackall authored
With the follow_symlinks option, sshfs will successfully create links while claiming it encountered an I/O error. In addition, depending on the type of link, it may subsequently be impossible to delete the link via sshfs. Our existing link to '.' will cause sshfs to think the link is a directory, and thus cause unlink to give EISDIR. Links to non-existent names or circular links will cause the created link to not even be visible. Thus, we need to create a new temporary file and link to that. We'll still get a failure, but we'll be able to remove the link.
-
Matt Mackall authored
We used to do this based on X-mailer: mentioning git, but git doesn't put X-mailer in its git-format-patch output.
-
- Jul 27, 2013
-
-
Pascal Quantin authored
-
Matt Mackall authored
-
- Jul 26, 2013
-
-
Matt Mackall authored
This skips the backup if it would be a duplicate.
-