- Nov 17, 2013
-
-
Mads Kiilerich authored
Before, it just said 'nothing to rebase' in this case. Now, it aborts mentioning the reason: 'empty "source" revision set'. Specifying revisions that cannot be rebased is a 'soft' error, but specifying an empty set deserves an abort that explains exactly what the problem is.
-
- Nov 16, 2013
-
-
Mads Kiilerich authored
Before, it just said 'nothing to rebase' in this case. Now, it aborts mentioning the reason: 'empty "rev" revision set'. Specifying revisions that cannot be rebased is a 'soft' error, but specifying an empty set deserves an abort that explains exactly what the problem is.
-
- Nov 17, 2013
-
-
Mads Kiilerich authored
-
- Nov 21, 2013
-
-
Mads Kiilerich authored
Was the behavior correct and the description wrong so it should be updated as in this patch? Or should the code work as the documentation says? Both ways could make some sense ... but none of them are obvious in all cases. One place where it currently cause problems is when the current revision has another branch head that is closer to tip but closed. 'hg rebase' refuses to rebase to that as it only see the tip-most unclosed branch head which is the current revision. /me kind of likes named branches, but no so much how branch closing works ...
-
- Jan 12, 2014
-
-
Mads Kiilerich authored
This is often very handy when hacking/debugging. Calling util.debugstacktrace('hey') from a place in hg will give something like: hey at: ./hg:38 in <module> /home/user/hgsrc/mercurial/dispatch.py:28 in run /home/user/hgsrc/mercurial/dispatch.py:65 in dispatch /home/user/hgsrc/mercurial/dispatch.py:88 in _runcatch /home/user/hgsrc/mercurial/dispatch.py:740 in _dispatch /home/user/hgsrc/mercurial/dispatch.py:514 in runcommand /home/user/hgsrc/mercurial/dispatch.py:830 in _runcommand /home/user/hgsrc/mercurial/dispatch.py:801 in checkargs /home/user/hgsrc/mercurial/dispatch.py:737 in <lambda> /home/user/hgsrc/mercurial/util.py:472 in check ...
-
- Jan 07, 2014
-
-
Simon Heimberg authored
-
Simon Heimberg authored
Using check-code-ignore to skip the failures on a line has several disadvantages: * It skips all check-code failures on a line, not only the one it was created for. * It does not give any hint for which rule it was added, making it difficult to see when it is not needed anymore. So drop this pragma in favor of better alternatives promoted before.
-
Simon Heimberg authored
In the past several approaches were used when a check-code rule triggered without a good reason. Not all of them looked nice, some were even wrong. Suggest some good practices which should be used instead.
-
Simon Heimberg authored
Use the work-around suggested by the rule instead
-
Simon Heimberg authored
Skipping an entire file generally from checking is an important event, so report it always. Do not tell the check name because skipping does not depend on it. Directly skip the entire file instead of checking more patterns and skip again. The pragma no-check-code was introduced by accident in the past. (Fixed in e033a7d444ac and ee07f9d142c9.) This now is prevented because the files to skip have to be listed in the test output of test-check-code-hg.t.
-
Simon Heimberg authored
Skipping of the entire file has been introduced in bc3b48b0f5c8.
-
- Nov 16, 2013
-
-
Mads Kiilerich authored
14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it also changed how the 'current' revision is used in combination with --command. The new behaviour might be ok for --noupdate where the working directory and its revision shouldn't be used, but it also did that when --command is used to run a command on the currently checked out revision then it could register the test result on the wrong revision. An example: Before, bisect with --command could use the wrong revision when recording the test result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 31:58c80a7c8a40: bad abort: inconsistent state, 31:58c80a7c8a40 is good and bad Now it works as before and as expected and uses the working directory revision for the --command result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 0:b99c7b9c8e11: bad ...
-
Mads Kiilerich authored
The 'copies' method has no test coverage and calls copies.pathcopies with an incorrect number of parameters and is thus (fortunately) not used. Kill it.
-
- Nov 19, 2013
-
-
Siddharth Agarwal authored
This isn't used outside this block, nor is it expected to be.
-
Siddharth Agarwal authored
This is more correct because we now fetch '.' while nothing else can interfere with it.
-
- Nov 22, 2013
-
-
Siddharth Agarwal authored
cur will be moved inside the wlock in a future patch, so we need to pass it into checkconflict explicitly.
-
- Nov 19, 2013
-
-
Siddharth Agarwal authored
Any invocations of bookmarks other than a plain 'hg bookmarks' will likely cause a write to the bookmark store. These should be guarded by the wlock. The repo._bookmarks read should be similarly guarded by the wlock if we're going to be subsequently writing to it.
-
Siddharth Agarwal authored
Upcoming patches will acquire the wlock for write operations, such as make inactive, but not read-only ones, such as list bookmarks. Separate out the status messages so that the code paths can be separated.
-
- Nov 17, 2013
-
-
Mads Kiilerich authored
9589227657bc introduced hghave cvs112 10 months ago. Let's assume it has stabilized so much that we can start using it now.
-
- Jan 13, 2014
-
-
Matt Mackall authored
-
- Jan 08, 2014
-
-
David Soria Parra authored
The German translation for "remote" as "entfernt" can be misleading in situations where remote is used as a noun. "entfernt" is not a noun and can also mean "removed". To clarify this we rename "remote" to "Gegenseite" when used as a noun.
-
- Jan 10, 2014
-
-
Kevin Bullock authored
-
Matt Mackall authored
-
- Nov 16, 2013
-
-
Pierre-Yves David authored
Nodemap is not aware of filtering so we need to ask the changelog itself if a node is known. This is probably a bit slower but such check does not dominated discovery time. This is necessary if we want to run discovery on filtered repo.
-
Pierre-Yves David authored
One more step toward discovery running on filtered repo.
-
Pierre-Yves David authored
The revlogdag class is a core part of discovery. We need its initialisation to exclude revision filtered out.
-
Pierre-Yves David authored
The discovery is not yet ready for filtered repo. Pull was using filtered for its discovery which is wrong. It worked by dumb luck because discovery mainly use funtion that does not respect the filtering. Trying to makes discovery work on filtered repo revealed this bug.
-
- Nov 05, 2013
-
-
Pierre-Yves David authored
When all changesets in the local repo are either being pushed or remotly known, we can take a fast path when bundling changeset because we are certain all local deltas are computed againts base known remotely. So we have a check to detect this situation, when we did a bare push and nothing was excluded. In a coming refactoring, the discovery will run on filtered view and the content of `outgoing.excluded` will just include unserved (secret) changeset not filtered by the repoview used to call push (usually "visible"). So we need to check if there is both no excluded changeset and nothing filtered by the current repoview.
-
- Nov 16, 2013
-
-
Pierre-Yves David authored
Before that changes, pulled revision that happend to be already known locally (so, not actually added) was not taken into account when computing the new common set between local and remote. It appears that we already know the heads of the pulled set. It is in the `rheads` variable, so we are just using it and everything is works fine. We are dropping the, now useless, computation of `added` set in the process.
-
- Nov 25, 2013
-
-
Simon Heimberg authored
Compare version by using pythons tuple comparison. So we do not match on python 3.0 or newer.
-
- Dec 23, 2013
-
-
Andrej Shadura authored
hg-git uses tagtype 'git', for example, so it's better to check for tagtype != 'local', not strictly for 'global'
-
- Nov 26, 2013
-
-
Durham Goode authored
Moves the code that actually writes to a file to a separate function in revlog.py. This allows extensions to intercept and use the data being written to disk. For example, an extension might want to replicate these writes elsewhere. When cloning the Mercurial repo on /dev/shm with --pull, I see about a 0.3% perf change. It goes from 28.2 to 28.3 seconds.
-
- Nov 24, 2013
-
-
Kevin Bullock authored
The double-for form of list comprehensions gets particularly unreadable when you throw in an 'if' condition. This expands the only remaining instance of the double-for syntax in our codebase into a loop.
-
- Jan 02, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Dec 30, 2013
-
-
Katsunori FUJIWARA authored
-
- Jan 01, 2014
-
-
durin42 authored
-