Tue, 13 Oct 2015 22:53:08 -0700 exchange: use pushop.repo instead of repo
Sean Farley <sean@farley.io> [Tue, 13 Oct 2015 22:53:08 -0700] rev 26672
exchange: use pushop.repo instead of repo
Tue, 13 Oct 2015 03:20:05 -0700 rebase: factor out nothing to rebase return code
Ryan McElroy <rmcelroy@fb.com> [Tue, 13 Oct 2015 03:20:05 -0700] rev 26671
rebase: factor out nothing to rebase return code A rebase call that results in nothing to rebase might be considered successful in some contexts. This factors out the return code from places where hg determines that there is nothing to rebase, so an extenion might change this return code to be something that would allow scripts to run without seeing this as an error.
Thu, 15 Oct 2015 00:04:58 +0800 gitweb: visually highlight source lines when hovering over line numbers
Anton Shestakov <av6@dwimlabs.net> [Thu, 15 Oct 2015 00:04:58 +0800] rev 26670
gitweb: visually highlight source lines when hovering over line numbers Due to how the line links now reside outside of the source lines, hovering over line numbers doesn't count as hovering over the appropriate source line. It can be worked around by using a "+" css selector. However, it's necessary to reorder the elements and put <a> before <span> (which is actually quite logical). It works without further css tweaks because <a> is already absolute-positioned and so the order doesn't matter visually.
Tue, 13 Oct 2015 14:17:15 -0700 rebase: added comments
Christian Delahousse <cdelahousse@fb.com> [Tue, 13 Oct 2015 14:17:15 -0700] rev 26669
rebase: added comments Added comments describing the state variable and constants used throughout the rebase extension
Wed, 14 Oct 2015 22:45:51 +0800 monoblue: visually highlight source lines when hovering over line numbers
Anton Shestakov <av6@dwimlabs.net> [Wed, 14 Oct 2015 22:45:51 +0800] rev 26668
monoblue: visually highlight source lines when hovering over line numbers Due to how the line links now reside outside of the source lines, hovering over line numbers doesn't count as hovering over the appropriate source line. It can be worked around by using a "+" css selector. However, it's necessary to reorder the elements and put <a> before <span> (which is actually quite logical). It works without further css tweaks because <a> is already absolute-positioned and so the order doesn't matter visually.
Wed, 14 Oct 2015 22:24:50 +0800 monoblue: make the size of line links bigger to cover line numbers better
Anton Shestakov <av6@dwimlabs.net> [Wed, 14 Oct 2015 22:24:50 +0800] rev 26667
monoblue: make the size of line links bigger to cover line numbers better Due to how the line numbers in monoblue are formed (via css counters), the size of the area with the numbers and the size of the actually clickable links are not tied together well enough. Before this patch, there were noticeable "gaps" between line links - clicking on the bottom part of a visible line number did nothing as opposed to selecting this line. Let's set font-size for everything in pre.sourcelines so that it also affects the links and then add a bit of padding to them so compensate for layout differences. This way the sizes are still not 100% the same, but should be very close.
Sat, 26 Sep 2015 18:16:49 +0800 gitweb: don't drop current revision context on graph page
Anton Shestakov <av6@dwimlabs.net> [Sat, 26 Sep 2015 18:16:49 +0800] rev 26666
gitweb: don't drop current revision context on graph page In hgweb, some pages have a context of current revision; e.g. changelog and shortlog show changesets starting from this current revision. However, some gitweb templates were dropping current revision from some urls _to_ /graph page and _on_ that page. This patch fixes it.
Tue, 13 Oct 2015 16:05:30 -0700 util: also catch IndexError
Sean Farley <sean@farley.io> [Tue, 13 Oct 2015 16:05:30 -0700] rev 26665
util: also catch IndexError This makes life so, so much easier for hgwatchman, which provides a named tuple but throws an IndexError instead of a TypeError.
Wed, 14 Oct 2015 12:23:49 +0200 exewrapper: add comments about PYTHONHOME
Adrian Buehlmann <adrian@cadifra.com> [Wed, 14 Oct 2015 12:23:49 +0200] rev 26664
exewrapper: add comments about PYTHONHOME This has been a repeating source of confusion for users of HackableMercurial. Note that users of HackableMercurial should *not* and are *not* expected to set PYTHONHOME.
Wed, 14 Oct 2015 12:23:04 +0200 exewrapper: report name of failed private DLL in error message
Adrian Buehlmann <adrian@cadifra.com> [Wed, 14 Oct 2015 12:23:04 +0200] rev 26663
exewrapper: report name of failed private DLL in error message Same as in preceding change, but this time it's for the private Python of HackableMercurial (in hg-python directory next to the hg.exe).
Wed, 14 Oct 2015 12:22:09 +0200 exewrapper: report name of failed DLL in error message
Adrian Buehlmann <adrian@cadifra.com> [Wed, 14 Oct 2015 12:22:09 +0200] rev 26662
exewrapper: report name of failed DLL in error message This uses C string literal concatenation. Example output: $ hg version abort: failed to load Python DLL python27.dll Note that HGPYTHONLIB does not contain the trailing .dll, which works here because the documentation of LoadLibrary [1] says, that if no file name extension is specified in the filename parameter, the default library extension .dll is appended. See [2] for a motivation of this change. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx [2] https://selenic.com/pipermail/mercurial/2015-August/048627.html
Tue, 13 Oct 2015 00:16:25 +0200 merge: abort on file/directory case folding collisions (issue4892)
Mads Kiilerich <madski@unity3d.com> [Tue, 13 Oct 2015 00:16:25 +0200] rev 26661
merge: abort on file/directory case folding collisions (issue4892) File/directory case folding collisions cannot be represented on case folding systems and have to fail. To detect this and abort early, utilize that for file/directory collisions, a sorted list of case folded manifest names will have the colliding directory right after the file. (This could perhaps be optimized, but this way of doing it also has directory/directory case folding in mind ... which however not is handled yet.)
Tue, 13 Oct 2015 00:16:25 +0200 tests: test of case-folding merge collisions
Mads Kiilerich <madski@unity3d.com> [Tue, 13 Oct 2015 00:16:25 +0200] rev 26660
tests: test of case-folding merge collisions
Wed, 19 Aug 2015 15:40:13 -0500 copies: group bothnew with other sets
Matt Mackall <mpm@selenic.com> [Wed, 19 Aug 2015 15:40:13 -0500] rev 26659
copies: group bothnew with other sets
Wed, 19 Aug 2015 15:32:27 -0500 copies: rename renamedelete to renamedeleteset for clarity
Matt Mackall <mpm@selenic.com> [Wed, 19 Aug 2015 15:32:27 -0500] rev 26658
copies: rename renamedelete to renamedeleteset for clarity
Wed, 19 Aug 2015 15:26:08 -0500 copies: move _makegetfctx calls into checkcopies
Matt Mackall <mpm@selenic.com> [Wed, 19 Aug 2015 15:26:08 -0500] rev 26657
copies: move _makegetfctx calls into checkcopies
Wed, 19 Aug 2015 15:17:33 -0500 copies: factor out setupctx into _makegetfctx
Matt Mackall <mpm@selenic.com> [Wed, 19 Aug 2015 15:17:33 -0500] rev 26656
copies: factor out setupctx into _makegetfctx This reduces the scope of mergecopies a bit
Fri, 21 Aug 2015 15:12:58 -0500 copies: avoid reference to c1/c2 in makectx
Matt Mackall <mpm@selenic.com> [Fri, 21 Aug 2015 15:12:58 -0500] rev 26655
copies: avoid reference to c1/c2 in makectx
Mon, 12 Oct 2015 03:37:09 -0500 mq: use cmdutil.revert instead of hg.revert
Matt Mackall <mpm@selenic.com> [Mon, 12 Oct 2015 03:37:09 -0500] rev 26654
mq: use cmdutil.revert instead of hg.revert It's the last user.
Wed, 30 Sep 2015 21:48:53 -0700 debugmergestate: add support for printing out driver-resolved files
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:48:53 -0700] rev 26653
debugmergestate: add support for printing out driver-resolved files
Wed, 30 Sep 2015 21:47:27 -0700 debugmergestate: add support for printing out merge driver
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:47:27 -0700] rev 26652
debugmergestate: add support for printing out merge driver
Wed, 30 Sep 2015 19:43:51 -0700 merge.mergedriver: don't try resolving files marked driver-resolved
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 19:43:51 -0700] rev 26651
merge.mergedriver: don't try resolving files marked driver-resolved The driver is expected to take care of these.
Mon, 28 Sep 2015 18:34:06 -0700 merge.mergestate: add support for persisting driver-resolved files
Siddharth Agarwal <sid0@fb.com> [Mon, 28 Sep 2015 18:34:06 -0700] rev 26650
merge.mergestate: add support for persisting driver-resolved files A driver-resolved file is a file that's handled specially by the driver. A common use case for this state would be autogenerated files, the generation of which should happen only after all source conflicts are resolved. This is done with an uppercase letter because older versions of Mercurial will not know how to treat such files at all.
Wed, 30 Sep 2015 21:42:52 -0700 merge.mergestate: add support for persisting a custom merge driver
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:42:52 -0700] rev 26649
merge.mergestate: add support for persisting a custom merge driver A 'merge driver' is a coordinator for the overall merge process. It will be able to control: - tools for individual files, much like the merge-patterns configuration does today - tools that can work across groups of files - the ordering of file resolution - resolution of automatically generated files - adding and removing additional files to and from the dirstate Since it is a critical part of the merge process, it really is part of the merge state. This is a lowercase character (i.e. optional) because ignoring this is fine for older versions of Mercurial -- however, if there are any files that are specially treated by the driver, we should abort. That will happen in upcoming patches. There is a potential security issue with storing the merge driver in the merge state. See the inline comments for more details.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip