Wed, 12 Feb 2014 01:00:51 +0100 color: add debugcolor command (issue4094)
Olle Lundberg <geek@nerd.sh> [Wed, 12 Feb 2014 01:00:51 +0100] rev 20455
color: add debugcolor command (issue4094) This patch adds a debugcolor command that prints all colors that the extension knows about.
Thu, 30 Jan 2014 16:47:29 -0800 revset: added lazyset implementation to merge revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 30 Jan 2014 16:47:29 -0800] rev 20454
revset: added lazyset implementation to merge revset Performance benchmarking: $ time hg log -qr "first(merge())" 102:58039eddbdda real 0m0.276s user 0m0.208s sys 0m0.047s $ time ./hg log -qr "first(merge())" 102:58039eddbdda real 0m0.192s user 0m0.154s sys 0m0.027s
Thu, 30 Jan 2014 16:03:18 -0800 revset: added lazyset implementation to grep revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 30 Jan 2014 16:03:18 -0800] rev 20453
revset: added lazyset implementation to grep revset Performance benchmarking: $ time hg log -qr "first(grep(hg))" 0:9117c6561b0b real 0m2.214s user 0m2.163s sys 0m0.045s $ time ./hg log -qr "first(grep(hg))" 0:9117c6561b0b real 0m0.211s user 0m0.146s sys 0m0.035s
Thu, 30 Jan 2014 15:39:56 -0800 revset: added lazyset implementation to desc revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 30 Jan 2014 15:39:56 -0800] rev 20452
revset: added lazyset implementation to desc revset Performance benchmarking: $ time hg log -qr "first(desc(hg))" changeset: 0:9117c6561b0b real 0m2.210s user 0m2.158s sys 0m0.049s $ time ./hg log -qr "first(desc(hg))" changeset: 0:9117c6561b0b real 0m0.171s user 0m0.131s sys 0m0.035s
Mon, 03 Feb 2014 16:15:25 -0800 revset: added lazyset implementation to draft revset
Lucas Moscovicz <lmoscovicz@fb.com> [Mon, 03 Feb 2014 16:15:25 -0800] rev 20451
revset: added lazyset implementation to draft revset
Wed, 29 Jan 2014 15:23:16 -0800 revset: added lazyset implementation bookmark revset
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 29 Jan 2014 15:23:16 -0800] rev 20450
revset: added lazyset implementation bookmark revset
Mon, 03 Feb 2014 16:02:48 -0800 revset: added lazyset implementation to date revset
Lucas Moscovicz <lmoscovicz@fb.com> [Mon, 03 Feb 2014 16:02:48 -0800] rev 20449
revset: added lazyset implementation to date revset Performance Benchmarking: $ time hg log -qr "first(date(05/03/2005))" 0:9117c6561b0b real 0m3.157s user 0m2.994s sys 0m0.087s $ time ./hg log -qr "first(date(05/03/2005))" 0:9117c6561b0b real 0m0.509s user 0m0.289s sys 0m0.070s
Wed, 29 Jan 2014 09:22:31 -0800 revset: added lazyset implementation to author revset
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 29 Jan 2014 09:22:31 -0800] rev 20448
revset: added lazyset implementation to author revset Performance benchmarking: $ time hg log -qr "first(author(mpm))" 0:9117c6561b0b real 0m3.486s user 0m3.317s sys 0m0.077s $ time ./hg log -qr "first(author(mpm))" 0:9117c6561b0b real 0m0.551s user 0m0.295s sys 0m0.072s
Wed, 29 Jan 2014 09:04:03 -0800 revset: added lazyset implementation to keyword revset
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 29 Jan 2014 09:04:03 -0800] rev 20447
revset: added lazyset implementation to keyword revset Performance benchmarking: $ time hg log -qr "first(keyword(changeset))" 0:9117c6561b0b real 0m3.466s user 0m3.345s sys 0m0.072s $ time ./hg log -qr "first(keyword(changeset))" 0:9117c6561b0b real 0m0.365s user 0m0.199s sys 0m0.083s
Tue, 28 Jan 2014 16:19:30 -0800 revset: changed limit revset implementation to work with lazy revsets
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 28 Jan 2014 16:19:30 -0800] rev 20446
revset: changed limit revset implementation to work with lazy revsets Performance benchmarking: $ time hg log -qr "first(branch(default))" 0:9117c6561b0b real 0m3.130s user 0m3.025s sys 0m0.074s $ time ./hg log -qr "first(branch(default))" 0:9117c6561b0b real 0m0.300s user 0m0.198s sys 0m0.069s
Wed, 05 Feb 2014 16:12:03 -0800 revset: added lazyset implementation to branch revset
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 05 Feb 2014 16:12:03 -0800] rev 20445
revset: added lazyset implementation to branch revset Performance Benchmarking: $ time hg log -l1 -qr "branch(default)" 0:9117c6561b0b real 0m3.366s user 0m3.217s sys 0m0.095s $ time ./hg log -l1 -qr "branch(default)" 0:9117c6561b0b real 0m0.389s user 0m0.199s sys 0m0.061s
Tue, 11 Feb 2014 01:15:07 +0100 run-tests: fix typo and print out failing line
Simon Heimberg <simohe@besonet.ch> [Tue, 11 Feb 2014 01:15:07 +0100] rev 20444
run-tests: fix typo and print out failing line Instead of stripping the newline and printing the line, only the newline was printed. The output on buildbot will make more sense now.
Tue, 28 Jan 2014 15:19:14 -0800 revset: changed getset so that it can return a lazyset
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 28 Jan 2014 15:19:14 -0800] rev 20443
revset: changed getset so that it can return a lazyset Not converting it manually to a baseset anymore. At this point every revset method should return a baseset typed structure.
Tue, 11 Feb 2014 09:00:38 -0800 hgext: updated extensions to return a baseset when adding symbols
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 11 Feb 2014 09:00:38 -0800] rev 20442
hgext: updated extensions to return a baseset when adding symbols
Thu, 30 Jan 2014 20:22:43 -0800 push: move phases synchronisation function in its own function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 20:22:43 -0800] rev 20441
push: move phases synchronisation function in its own function Now that every necessary information is held in the `pushoperation` object, we can finally extract the phase synchronisation phase to it's own function. This is the first concrete block of code we extract from the huge push function. Hooray! This changeset is pure code movement only.
Thu, 30 Jan 2014 20:18:26 -0800 push: move outgoing object in the push object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 20:18:26 -0800] rev 20440
push: move outgoing object in the push object The set of outgoing and common changeset are used by phases to compute the new common set between local and remote. So we need to move it into the object to extract the phase sync from the god function. Note that this information will be used by obsolescence markers too.
Thu, 30 Jan 2014 19:43:28 -0800 push: move push return value in the push object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 19:43:28 -0800] rev 20439
push: move push return value in the push object The return code convey information about the success of changeset push. This is used by phases to compute the new common set between local and remote. So we need to move it into the object to extract the phase sync from the god function. Note that this information will be used by obsolescence markers too.
Thu, 30 Jan 2014 20:10:59 -0800 push: move local phase move in a normal function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 20:10:59 -0800] rev 20438
push: move local phase move in a normal function We now have the modularity for simpler approach `localphasemove`.
Thu, 30 Jan 2014 20:09:21 -0800 push: explicitly feed pushop to localphasemove
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 20:09:21 -0800] rev 20437
push: explicitly feed pushop to localphasemove Now that pushop is holding all the push related data, we do not really need a closure anymore. So we start feeding the object to `localphasemove` and will make it a normal function in the next commit.
Thu, 30 Jan 2014 20:00:34 -0800 push: move local lock logic in pushoperation
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 20:00:34 -0800] rev 20436
push: move local lock logic in pushoperation During push, we try to lock the local repo to move local phase according to what we saw/pushed on the remote repo. Locking the repo may fail, in that case we let the push proceed without local phase movement (printing warning). This mean we have code in phase synchronisation that will check if the local repo is locked or not. we need to move this information in the push object to be able to extract the phase synchronisation in its own function. This is done as a boolean because putting reference to the actual lock outside of the main function sounded a bad idea.
Thu, 30 Jan 2014 19:55:09 -0800 push: move obsolescence related message into _pushobsolescence function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 19:55:09 -0800] rev 20435
push: move obsolescence related message into _pushobsolescence function No good reason to have them in the main fonction.
Thu, 30 Jan 2014 19:51:21 -0800 push: drop now outdated comment
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 19:51:21 -0800] rev 20434
push: drop now outdated comment This `_pushobsolete` now exist for modularity purpose.
Thu, 30 Jan 2014 17:56:09 -0800 push: feed pushoperation object to _pushobsolete function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:56:09 -0800] rev 20433
push: feed pushoperation object to _pushobsolete function This will allow the obsolete marker synchronisation to have full information on the ongoing push and pass information to other operation.
Thu, 30 Jan 2014 17:54:47 -0800 push: move obsolescence marker exchange in the exchange module
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:54:47 -0800] rev 20432
push: move obsolescence marker exchange in the exchange module The obsolescence marker exchange code was already extracted during a previous cycle. We are moving the extracted functio in this module. This function will read and write data in the `pushoperation` object and I prefer to have all core function collaborating through this object in the same place. This changeset is pure code movement only. Code change for direct consumption of the `pushoperation` object will come later.
Thu, 30 Jan 2014 17:51:41 -0800 push: feed pushoperation object to _pushbookmark function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:51:41 -0800] rev 20431
push: feed pushoperation object to _pushbookmark function This will able the bookmark synchronisation to have full information on the ongoing push and pass information to other operation.
Mon, 10 Feb 2014 17:31:26 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 10 Feb 2014 17:31:26 -0600] rev 20430
merge with stable
Thu, 06 Feb 2014 14:29:37 -0800 revset: added operations to duck type baseset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:29:37 -0800] rev 20429
revset: added operations to duck type baseset Added more operations which are not lazy but only used so far to duck type baseset. Their implementations will be changed in future patches.
Thu, 06 Feb 2014 14:25:37 -0800 revset: added basic operations to lazyset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:25:37 -0800] rev 20428
revset: added basic operations to lazyset Added methods __add__, __sub__ and __and__ to duck type more methods in baseset
Thu, 06 Feb 2014 14:19:40 -0800 revset: added lazyset class with basic operations
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:19:40 -0800] rev 20427
revset: added lazyset class with basic operations This class allows us to return values from large revsets as soon as they are computed instead of having to wait for the entire revset to be calculated.
Sun, 09 Feb 2014 00:26:01 +0100 tests: test that the pid returned by `hg serve` looks reasonable
Simon Heimberg <simohe@besonet.ch> [Sun, 09 Feb 2014 00:26:01 +0100] rev 20426
tests: test that the pid returned by `hg serve` looks reasonable This failed on windows before win32.spawndetached has been fixed. The process name was "cmd.exe" and not "hg.exe" or "python.exe".
Sat, 08 Feb 2014 14:35:07 +0100 win32: spawndetached returns pid of detached process and not of cmd.exe
Simon Heimberg <simohe@besonet.ch> [Sat, 08 Feb 2014 14:35:07 +0100] rev 20425
win32: spawndetached returns pid of detached process and not of cmd.exe win32.spawndetached starts the detached process by `cmd.exe` (or COMSPEC). The pid it returned was the one of cmd.exe and not the one of the detached process. When this pid is used to kill the process, the detached process is not killed, but only cmd.exe. With this patch the pid of the detached process is written to the pid file. Killing the process works as expected. The pid is only evaluated on writing the pid file. It is unnecessary to search the pid when it is not needed. And more important, it probably does not yet exist right after the cmd.exe process was started. When the pid is written to the file, waiting for the start of the detached process has already happened. Use this functionality instead of writing a 2nd wait function. Many tests on windows will not fail anymore, all those with the first failing line "abort: child process failed to start". (The processes still hanging around from previous test runs have to be killed first. They still block a tcp port.) A good test for the functionality of this patch is test-treediscovery.t, because it starts and kills `hg serve -d` several times.
Thu, 06 Feb 2014 14:57:25 -0800 revset: minor changes adding baseset to revsets
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:57:25 -0800] rev 20424
revset: minor changes adding baseset to revsets Changed bits of code to work with baseset implementations.
Mon, 10 Feb 2014 22:56:10 +0100 tests: rewrite path in test-shelve.t for not being mangled on msys
Simon Heimberg <simohe@besonet.ch> [Mon, 10 Feb 2014 22:56:10 +0100] rev 20423
tests: rewrite path in test-shelve.t for not being mangled on msys msys (on windows) converets '-R bundle:.XX/XX' to '-R bundle:;.XX/XX'. Avoid this by writing '-R bundle://.XX/XX'. This is used more often than the alternative work arounds like '-Rbundle://.XX/XX' or '-R bundle:Y/../.XX/XX'.
Mon, 10 Feb 2014 14:51:06 -0800 hooks: only disable/re-enable demandimport when it's already enabled stable
Brodie Rao <brodie@sf.io> [Mon, 10 Feb 2014 14:51:06 -0800] rev 20422
hooks: only disable/re-enable demandimport when it's already enabled This fixes an issue introduced in d7c28954d901 where, when disabling demandimport while running hooks, it's inadvertently re-enabled even when it was never enabled in the first place. This doesn't affect normal command line usage of Mercurial; it only matters when Mercurial is run with demandimport intentionally disabled.
Sun, 09 Feb 2014 18:36:37 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 09 Feb 2014 18:36:37 -0600] rev 20421
merge with stable
Fri, 07 Feb 2014 17:29:37 +0100 convert: secret config option for disabling debugsvnlog
Mads Kiilerich <madski@unity3d.com> [Fri, 07 Feb 2014 17:29:37 +0100] rev 20420
convert: secret config option for disabling debugsvnlog Subversion issues involving svn log such as d54467c1a198 can be tricky to debug when it is run in an 'hg debugsvnlog' sub process. Debugging is simpler when convert only uses one process. With this change convert will invoke the svn log directly when setting [convert] svn.debugsvnlog = False This is intentionally not documented.
Fri, 07 Feb 2014 17:28:37 +0100 convert: make subversion revsplit more stable when meeting revisions without @
Mads Kiilerich <madski@unity3d.com> [Fri, 07 Feb 2014 17:28:37 +0100] rev 20419
convert: make subversion revsplit more stable when meeting revisions without @ revsplit would crash for instance if given a subversion string without @ ... and that could somehow happen when playing around with convert.
Thu, 06 Feb 2014 14:57:25 -0800 revset: minor changes adding baseset to revsets
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 14:57:25 -0800] rev 20418
revset: minor changes adding baseset to revsets Changed bits of code to work with baseset implementations.
Thu, 06 Feb 2014 11:37:16 -0800 revset: added __add__ method to baseset class
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 11:37:16 -0800] rev 20417
revset: added __add__ method to baseset class
Thu, 06 Feb 2014 11:33:36 -0800 revset: added docstring to baseset class
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 11:33:36 -0800] rev 20416
revset: added docstring to baseset class
Mon, 10 Feb 2014 00:43:54 +0100 merge: don't overwrite file untracked after remove, abort with 'untracked files' stable
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:43:54 +0100] rev 20415
merge: don't overwrite file untracked after remove, abort with 'untracked files' Merge could overwrite untracked files and cause data loss. Instead we now handle the 'local side removed file and has untracked file instead' case as the 'other side added file that local has untracked' case: FILE: untracked file exists abort: untracked files in working directory differ from files in requested revision It could perhaps make sense to create .orig files when overwriting, either instead of aborting or when overwriting anyway because of force ... but for now we stay consistent with similar cases.
Mon, 10 Feb 2014 00:54:40 +0100 shelve: better (and slightly redundant) test coverage for unshelve conflicts
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:40 +0100] rev 20414
shelve: better (and slightly redundant) test coverage for unshelve conflicts
Mon, 10 Feb 2014 00:54:27 +0100 shelve: status messages from unshelve
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:27 +0100] rev 20413
shelve: status messages from unshelve It was hard for the user to know what was going on when unshelving - especially if the user had to resolve conflicts and thus got to see the intermediate states. Seeing that pending changes was gone could scare the user, make him panic, and do stuff that really made him lose data. Merging (both when rebasing and with pending changes) also requires some understanding of where in the process you are and what you are merging. To help the user we now show a couple of status messages (when relevant): temporarily committing pending changes (restore with 'hg unshelve --abort') rebasing shelved changes
Mon, 10 Feb 2014 00:54:12 +0100 shelve: be quiet when unshelve pulls from the shelve bundle
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:54:12 +0100] rev 20412
shelve: be quiet when unshelve pulls from the shelve bundle unshelve was quite verbose and it was hard for a user to follow what really was going on. It ended up saying 'added 1 changesets' ... but the user just expected and got pending changes and never saw any changeset. The use of bundles is an implementation detail that we don't have to leak here. Pulling is quite verbose, optimized for pulling many changesets from remote repos - that is not the case here. Instead, set the quiet flag when pulling the bundle - not only when temporarily committing pending changes. The 'finally' restore of ui.quiet is moved to the outer try/finally used for locking.
Mon, 10 Feb 2014 00:53:27 +0100 shelve: add 'changes to' prefix to default shelve message
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:53:27 +0100] rev 20411
shelve: add 'changes to' prefix to default shelve message The shelved changes _could_ perhaps be amended to the parent changeset but it _is_ not the parent changeset. Using the description from the parent changeset is thus wrong and confusing. Instead, add a 'changes to' prefix.
Mon, 10 Feb 2014 00:53:27 +0100 shelve: mention FILE options in help
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:53:27 +0100] rev 20410
shelve: mention FILE options in help Shelve do normally take a list of files or patterns to shelve and the command summary should thus show [FILE]... Note: --delete is a bit special and interpret the parameters as a list of shelve names. This change makes that even less obvious from the help. Too bad - we can't please everyone.
Mon, 10 Feb 2014 00:53:25 +0100 shelve: mention walk options in help
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:53:25 +0100] rev 20409
shelve: mention walk options in help
Mon, 10 Feb 2014 00:52:56 +0100 shelve: really pass publicancestors to changegroupsubset - not the parents
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:52:56 +0100] rev 20408
shelve: really pass publicancestors to changegroupsubset - not the parents publicancestors returned the parents of the public ancestors ... and changegroupsubset used the parents of these as base for the bundle. That gave bundles with one layer of changesets more than necessary.
Mon, 10 Feb 2014 00:52:46 +0100 shelve: publicancestors do not have to visit nullrev
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:52:46 +0100] rev 20407
shelve: publicancestors do not have to visit nullrev Not visiting nullrev seems more correct and might be a minor optimization.
Mon, 10 Feb 2014 00:52:16 +0100 localrepo: make it clear that changegroupsubset doesn't take bases but roots
Mads Kiilerich <madski@unity3d.com> [Mon, 10 Feb 2014 00:52:16 +0100] rev 20406
localrepo: make it clear that changegroupsubset doesn't take bases but roots changegroupsubset will take the parents of the roots to find the bases. Other parts of Mercurial do not expect that, and a result of that is that some bundles contain more changesets than necessary. No real changes here - just renaming a parameter to document what it is.
Tue, 04 Feb 2014 17:13:45 -0500 repoview: use repo.revs() instead of a private revset method
Augie Fackler <raf@durin42.com> [Tue, 04 Feb 2014 17:13:45 -0500] rev 20405
repoview: use repo.revs() instead of a private revset method Breaks an import cycle.
Tue, 04 Feb 2014 14:55:04 -0500 commands: use ctx.getfileset instead of fileset.getfileset
Augie Fackler <raf@durin42.com> [Tue, 04 Feb 2014 14:55:04 -0500] rev 20404
commands: use ctx.getfileset instead of fileset.getfileset
Sun, 09 Feb 2014 17:31:26 -0600 push: backout 2bc520bd0ce0 due to test failures
Matt Mackall <mpm@selenic.com> [Sun, 09 Feb 2014 17:31:26 -0600] rev 20403
push: backout 2bc520bd0ce0 due to test failures
Sun, 09 Feb 2014 17:30:49 -0600 mq: fix qimport url check
Matt Mackall <mpm@selenic.com> [Sun, 09 Feb 2014 17:30:49 -0600] rev 20402
mq: fix qimport url check
Tue, 04 Feb 2014 14:54:42 -0500 match: use ctx.getfileset() instead of fileset.getfileset()
Augie Fackler <raf@durin42.com> [Tue, 04 Feb 2014 14:54:42 -0500] rev 20401
match: use ctx.getfileset() instead of fileset.getfileset() Resolves an import cycle involving match and merge.
Tue, 04 Feb 2014 15:27:49 -0500 context: add a getfileset() method so fewer things need fileset directly
Augie Fackler <raf@durin42.com> [Tue, 04 Feb 2014 15:27:49 -0500] rev 20400
context: add a getfileset() method so fewer things need fileset directly Allows me to break an import cycle in a subsequent change.
Tue, 04 Feb 2014 18:09:20 -0500 fix_bytesmod: fix defects in fix_bytesmod so it produces working code
Augie Fackler <raf@durin42.com> [Tue, 04 Feb 2014 18:09:20 -0500] rev 20399
fix_bytesmod: fix defects in fix_bytesmod so it produces working code Prior to this change, the fixer did not always add the py3kcompat import to files, and did not manage to blacklist itself.
Thu, 06 Feb 2014 02:19:38 +0100 discovery: improve "note: unsynced remote changes!" warning
Mads Kiilerich <madski@unity3d.com> [Thu, 06 Feb 2014 02:19:38 +0100] rev 20398
discovery: improve "note: unsynced remote changes!" warning This note (which actually is a warning) frequently caused confusion. "unsynced" is not a well established user-facing concept in Mercurial and the message was not very specific or helpful. Instead, show a messages like: remote has heads on branch 'default' that are not known locally: 6c0482d977a3 and show it before aborting on "push creates new remote head". This will also give more of a hint in the case where the branch has been closed remotely and 'hg heads' thus not would show any new heads after pulling. A similar (but actually very different) message was addressed in 6b618aa08b6e.
Fri, 07 Feb 2014 17:26:28 +0100 convert: drop unused getheads from sinks
Mads Kiilerich <madski@unity3d.com> [Fri, 07 Feb 2014 17:26:28 +0100] rev 20397
convert: drop unused getheads from sinks
Sat, 08 Feb 2014 10:41:17 +0100 tests: on windows, run command explicitly in sh for working command substitution
Simon Heimberg <simohe@besonet.ch> [Sat, 08 Feb 2014 10:41:17 +0100] rev 20396
tests: on windows, run command explicitly in sh for working command substitution On windows, os.system runs the command in cmd.exe, which does not know command substitution. To let this work, run the command explicitly in sh. This fixes the failure of this test on windows.
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 +30000 tip