- Sep 02, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 01, 2014
-
- Aug 30, 2014
-
-
Gregory Szorc authored
`hg help -k` on my machine was aborting because the hg-prompt extension was inserting a string and not a function into help.helptable and help was blindly calling it. This patch changes keyword searching to be more robust against unexpected types.
-
- Sep 01, 2014
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Aug 31, 2014
-
-
Katsunori FUJIWARA authored
-
- Aug 30, 2014
-
-
Wagner Bruna authored
-
- Aug 31, 2014
-
-
Mike Hommey authored
Incidentally, this avoids the changelog cache being invalidated each time it's accessed on a repoview. On a filtering experiment on a repository the size of mozilla-central, this makes a significant difference: Before, running hg log -l 10 --time with about 8k changesets filtered out: time: real 1.490 secs (user 1.450+0.000 sys 0.040+0.000) After: time: real 0.540 secs (user 0.530+0.000 sys 0.010+0.000)
-
- Aug 19, 2014
-
-
Aaron Kushner authored
When running 'hg config no_such_option', hg exited with a zero exit code. This change now exits with a 1 if the config option does not exist.
-
- Aug 30, 2014
-
-
Kevin Bullock authored
This is a follow-on to 0c6cdbb697d9 that just makes a slight clarification.
-
- Aug 27, 2014
-
-
Katsunori FUJIWARA authored
Before this patch, no message is shown for failure of merging at "hg import". In such case, merging patch is imported as a normal revision silently, and it may confuse users. For simplicity, this patch recommends just using "--exact", even though importing the merging patch itself is possible without it if: - the hash of the 1st parent in the patch is equal to one of the patch imported just before (or the parent of the working directory, for the 1st patch of the series), and - the hash of the 2nd parent in the patch is known in the local repository
-
Mads Kiilerich authored
When grafting something with a matching origin, it would normally be skipped: skipping already grafted revision 123 (23 also has origin 12) But after stripping a graft origin, graft could fail with a reference to the origin that no longer exists: abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'! Instead, detect that the origin is unknown and skip it anyway, like: skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
-
- Aug 23, 2014
-
-
Sean Farley authored
Previously, there was a copy / paste error with using the current changeset's phase information. We now look up the parent context explicitly. The line was too long so it is stored into a variable first.
-
- Aug 25, 2014
-
-
Thomas De Schampheleire authored
Commit aa51392da507 introduced a pad function for use in templates, but did not add the corresponding documentation to 'hg help templating'.
-
- Aug 15, 2014
-
-
Mads Kiilerich authored
Pull would send a getbundle command where common heads were sent both as common and head, even though there is no reason to request a common head. The request was thus twice as big as necessary and more likely to hit HTTP header size limits. Instead, don't request heads that already are common. This is fixed in bundlerepo.getremotechanges . It could perhaps also have been fixed in discovery.findcommonincoming but that would have a bigger impact.
-
Mads Kiilerich authored
-
Mads Kiilerich authored
The value '*' currently designates that bid merge should be used. The best way to test bid merge is to set preferancestor=* in the configuration file ... but then it would abort with unknown revision '*' when other code paths ended up in changectx.ancestor . Instead, just skip and ignore the value '*' when looking for a preferred ancestor.
-
Mads Kiilerich authored
Updates with uncommited changes will always only have one ancestor - the parent revision. Updates between existing revision should (and will) always give the same result no matter which ancestor is used. The warning is thus only relevant when doing a "real" merge.
-
- Aug 14, 2014
-
-
Pierre-Yves David authored
When a remote is not capable of the `branchmap` wireproto command, we denote incoming heads with None. This leads to a crash in the code in charge of displaying the list of unknown remote heads. We now properly detect this case and display a shorter message in this case. The reason for this `set([None])` value is now documented.
-
Pierre-Yves David authored
We detect when there is a cycle in the marker itself (precursors being listed as successors).
-
Pierre-Yves David authored
There are already a couple of errors that obsstore.create can raise and we are going to introduce a cycle check too.
-
Matt Mackall authored
-
- Aug 13, 2014
-
-
Siddharth Agarwal authored
This was the one case for test-largefiles that was not broken.
-
Siddharth Agarwal authored
This makes hg log --follow --patch work, since in cmdutil._makelogrevset we use the non-follow matcher for hg log --follow --patch with no file arguments.
-
Siddharth Agarwal authored
This has actually been broken since at least Mercurial 2.8 -- hg log --patch with largefiles only used to work when no largefiles existed. Rev 5809d62e7106 exposed this bug for all cases.
-
Siddharth Agarwal authored
lfstatus should only be True for operations where we want standins to be printed out. We explicitly do not want that for historical operations like log. Other historical operations like hg diff -r A -r B don't print out standins either. This is required to fix issue4334, but doesn't fix anything by itself. That's why there aren't any tests accompanying this patch.
-
Siddharth Agarwal authored
This will be used by largefiles (and basically only by largefiles) in an upcoming patch.
-
Siddharth Agarwal authored
We're going to add a _makenofollowlogfilematcher in an upcoming patch.
-
Martin von Zweigbergk authored
When the authorship of the changeset folded in does not match that of the base changeset, we currently use the configured ui.username instead. This is especially surprising when the user is not the author of either of the changesets. In such cases, the resulting authorship (the user's) is clearly incorrect. Even when the user is folding in a patch they authored themselves, it's not clear whether they should take over the authorship. Let's instead keep it simple and always preserve the base changeset's authorship. This is also how "git rebase -i" handles folding/squashing.
-
Matt Mackall authored
backported from default
-
Matt Mackall authored
-
- Aug 12, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Michael O'Connor authored
-
- Aug 11, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
This behavior didn't make much sense and interacts badly with things that use unbundle internally like shelve. Presumably, the original rationale was that since bundles didn't contain bookmarks, this gave a sense of keeping bookmarks up-to-date like would happen with a corresponding pull. However, since it only updated the current active bookmark, and bare update already did that anyway, this is pretty slim. Notably, the corresponding test actually works better without this feature.
-
- Aug 10, 2014
-
-
Matt Mackall authored
-