Tue, 20 Sep 2016 23:46:15 +0000 bundle: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:46:15 +0000] rev 29971
bundle: use single quotes in use warning
Tue, 20 Sep 2016 23:45:25 +0000 histedit: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:45:25 +0000] rev 29970
histedit: use single quotes in use warning
Tue, 20 Sep 2016 23:45:15 +0000 keyword: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:45:15 +0000] rev 29969
keyword: use single quotes in use warning
Tue, 20 Sep 2016 23:44:59 +0000 mq: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:59 +0000] rev 29968
mq: use single quotes in use warning
Tue, 20 Sep 2016 23:44:49 +0000 pager: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:49 +0000] rev 29967
pager: use single quotes in use warning
Tue, 20 Sep 2016 23:44:28 +0000 rebase: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:28 +0000] rev 29966
rebase: use single quotes in use warning
Tue, 20 Sep 2016 20:12:38 +0000 push: update help hint to point to config.paths section
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 20:12:38 +0000] rev 29965
push: update help hint to point to config.paths section
Fri, 02 Sep 2016 21:49:33 +0000 update: use single quotes in use warning
timeless <timeless@mozdev.org> [Fri, 02 Sep 2016 21:49:33 +0000] rev 29964
update: use single quotes in use warning
Fri, 02 Sep 2016 21:46:00 +0000 remove: specify hg in added warning
timeless <timeless@mozdev.org> [Fri, 02 Sep 2016 21:46:00 +0000] rev 29963
remove: specify hg in added warning
Tue, 20 Sep 2016 12:24:01 -0700 manifest: add manifestlog.add
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29962
manifest: add manifestlog.add This adds a simple add() function to manifestlog. This lets us convert more uses of repo.manifest to use repo.manifestlog, so we can further break our dependency on the manifest class.
Tue, 20 Sep 2016 12:24:01 -0700 manifest: move manifest.add onto manifestrevlog
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29961
manifest: move manifest.add onto manifestrevlog This moves add and _addtree onto manifestrevlog. manifestrevlog is responsible for all serialization decisions, so therefore the add function should live on it. This will allow us to call add() from manifestlog, which lets us further break our dependency on manifest.
Tue, 20 Sep 2016 12:24:01 -0700 manifest: remove dependency on treeinmem from manifest.add
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29960
manifest: remove dependency on treeinmem from manifest.add Currently manifest.add uses the treeinmem option to know if it can call fastdelta on the given manifest instance. In a future patch we will be moving add() to be on the manifestrevlog, so it won't have access to the treeinmem option anymore. Instead, let's have it actually check if the given manifest instance supports the fastdelta operation. This also means that if treemanifest or any implementation eventually implements fastdelta(), it will automatically benefit from this code path.
Tue, 20 Sep 2016 12:24:01 -0700 manifest: move treeinmem onto manifestlog
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29959
manifest: move treeinmem onto manifestlog A previous patched moved all the serialization related options onto manifestrevlog (since it is responsible for serialization). Let's move the treeinmem option on manifestlog, since it is responsible for materialization decisions. This reduces the number of dependencies manifestlog has on the old manifest type as well, so we can eventually make them completely independent of each other.
Mon, 19 Sep 2016 17:14:43 -0400 copy: document current behavior of 'hg cp --after'
Augie Fackler <augie@google.com> [Mon, 19 Sep 2016 17:14:43 -0400] rev 29958
copy: document current behavior of 'hg cp --after' I'm about to propose an output change here, but the existing behavior was untested!
Tue, 20 Sep 2016 10:03:50 -0500 crecord: add an event that scrolls the selected line to the top of the screen
Nathan Goldbaum <ngoldbau@illinois.edu> [Tue, 20 Sep 2016 10:03:50 -0500] rev 29957
crecord: add an event that scrolls the selected line to the top of the screen Using ctrl-l for this purpose seems to be a fairly widely used practice, presumably following emacs. This doesn't scroll the selected line all the way to the top of the window, instead it leaves a 3 line buffer for context. Use curses.unctrl() to resolve keypressed to '^L' to avoid hard-coding hexadecimal key codes.
Tue, 03 May 2016 14:24:00 +0900 log: drop hack to fix order of revset (issue5100)
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 14:24:00 +0900] rev 29956
log: drop hack to fix order of revset (issue5100) Specify ordered=revset.followorder instead. This patch effectively backs out c407583cf5f6. revs.sort(reverse=True) is replaced by revs.reverse() because the matcher should no longer reorder revisions.
Tue, 03 May 2016 14:18:28 +0900 revset: add option to make matcher takes the ordering of the input set
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 14:18:28 +0900] rev 29955
revset: add option to make matcher takes the ordering of the input set This allows us to evaluate match(subset) as if 'subset & expr', which will be the complete fix for the issue5100.
Mon, 19 Sep 2016 09:14:35 -0700 strip: don't use "full" and "partial" to describe bundles
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Sep 2016 09:14:35 -0700] rev 29954
strip: don't use "full" and "partial" to describe bundles The partial bundle is not a subset of the full bundle, and the full bundle is not full in any way that i see. The most obvious interpretation of "full" I can think of is that it has all commits back to the null revision, but that is not what the "full" bundle is. The "full" bundle is simply a backup of what the user asked us to strip (unless --no-backup). The "partial" bundle contains the revisions we temporarily stripped because they had higher revision numbers that some commit that the user asked us to strip. The "full" bundle is already called "backup" in the code, so let's use that in user-facing messages too. Let's call the "partial" bundle "temporary" in the code.
Mon, 19 Sep 2016 09:14:32 -0700 strip: clarify that user action is required to recover temp bundle
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Sep 2016 09:14:32 -0700] rev 29953
strip: clarify that user action is required to recover temp bundle If strip fails when applying the temporary bundle, the commits in the temporary bundle have not yet been applied, so the user will almost definitely want to apply the bundle. We should be more clear to the user about that than our current "partial bundle stored in...". Note that we will probably not be able to recover it automatically, since whatever made it fail (e.g. a hook) will most likely make it fail again. We need to give control back to the user to fix the problem before trying again.
Thu, 15 Sep 2016 09:45:29 -0700 strip: report both bundle files in case of exception (issue5368)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Sep 2016 09:45:29 -0700] rev 29952
strip: report both bundle files in case of exception (issue5368) If strip fails while recovering the temporary bundle (e.g. because a hook fails), we tell the user only about the backup bundle, not about the temporary bundle. Since the user did not ask to strip the commits in the temporary bundle, that's the more important bundle to mention, so let's do that (and also mention the backup bundle as usual).
Thu, 15 Sep 2016 10:18:56 -0700 strip: simplify some repeated conditions
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Sep 2016 10:18:56 -0700] rev 29951
strip: simplify some repeated conditions We check "if saveheads or savebases" in several places to see if we should or have created a bundle of the changesets to apply after truncating the revlogs. One of the conditions is actually just "if saveheads", but since there can't be savebases without saveheads, that is effectively the same condition. It seems simpler to check only once and from then on see if we created the file.
Mon, 29 Aug 2016 07:07:15 +0200 config: add template support
Mathias De Maré <mathias.demare@gmail.com> [Mon, 29 Aug 2016 07:07:15 +0200] rev 29950
config: add template support V2: - Limit escaping to plain formatting only - Use the formatter consistently (no more ui.debug) - Always include 'name' and 'value' V3: - Always convert 'value' to string (this also makes sure we handle functions) - Keep real debug message as ui.debug for now - Add additional tests. Note: I'm not quite sure about the best approach to handling the 'print the full config' case. For me, it printed the 'ui.promptecho' key at the end. I went with globs there as that at least tests the json display reliably. Example output: [ { "name": "ui.username", "source": "/home/mathias/.hgrc:2", "value": "Mathias De Maré <mathias.demare@gmail.com>" } ]
Mon, 29 Aug 2016 17:19:09 +0200 formatter: introduce isplain() to replace (the inverse of) __nonzero__() (API)
Mathias De Maré <mathias.demare@gmail.com> [Mon, 29 Aug 2016 17:19:09 +0200] rev 29949
formatter: introduce isplain() to replace (the inverse of) __nonzero__() (API) V2: also remove and replace __nonzero__
Tue, 30 Aug 2016 15:55:07 -0400 diffopts: notice a negated boolean flag in diffopts
Augie Fackler <augie@google.com> [Tue, 30 Aug 2016 15:55:07 -0400] rev 29948
diffopts: notice a negated boolean flag in diffopts This means that if you have git-diffs enabled by default (pretty common) and you hit the rare (but real) case where a git-diff breaks patch(1) or some other tool, you can easily disable it by just specifying --no-git on the command line. I feel a little bad about the isinstance() check, but some values in diffopts are not booleans and so we need to preserve false iff the flag is a boolean flag: failing to do this means we end up with empty string defaults for flags clobbering meaningful values from the [diff] section in hgrc.
Tue, 13 Sep 2016 22:57:57 -0400 flags: allow specifying --no-boolean-flag on the command line (BC)
Augie Fackler <augie@google.com> [Tue, 13 Sep 2016 22:57:57 -0400] rev 29947
flags: allow specifying --no-boolean-flag on the command line (BC) This makes it much easier to enable some anti-foot-shooting features (like update --check) by default, because now all boolean flags can be explicitly disabled on the command line without having to use HGPLAIN or similar. Flags which don't deserve this treatment can be removed from consideration by adding them to the nevernegate set in fancyopts. This doesn't make it any easier to identify when a flag is set: opts still always gets filled in, either with the user-specified flag value or with the default from the flags list in the command table. Improving that would probably clean things up a bit, but for now if you want a boolean flag and care if it was explicitly false or default false (or true, but nobody uses that functionality because before now it was nonsense) you need to use None as your default rather than True or False. This doesn't (yet) update help output, because I'm not quite sure how to do that cleanly.
Tue, 03 May 2016 13:36:12 +0900 revset: make sort() noop depending on ordering requirement (BC)
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 13:36:12 +0900] rev 29946
revset: make sort() noop depending on ordering requirement (BC) See the previous patch for why.
Tue, 03 May 2016 13:36:12 +0900 revset: make reverse() noop depending on ordering requirement (BC)
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 13:36:12 +0900] rev 29945
revset: make reverse() noop depending on ordering requirement (BC) Because smartset.reverse() may modify the underlying subset, it should be called only if the set can define the ordering. In the following example, 'a' and 'c' is the same object, so 'b.reverse()' would reverse 'a' unexpectedly. # '0:2 & reverse(all())' <filteredset <spanset- 0:2>, # a <filteredset # b <spanset- 0:2>, # c <spanset+ 0:9>>>
Tue, 03 May 2016 12:52:50 +0900 revset: fix order of nested 'range' expression (BC)
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 12:52:50 +0900] rev 29944
revset: fix order of nested 'range' expression (BC) Enforce range order only if necessary as the comment says "carrying the sorting over would be more efficient."
Wed, 01 Jun 2016 20:54:04 +0900 revset: forward ordering requirement to argument of present()
Yuya Nishihara <yuya@tcha.org> [Wed, 01 Jun 2016 20:54:04 +0900] rev 29943
revset: forward ordering requirement to argument of present() present() is special in that it returns the argument set with no modification, so the ordering requirement should be forwarded. We could make present() fix the order like orset(), but that would be silly because we know the extra filtering cost is unnecessary.
Wed, 14 Sep 2016 11:39:47 -0500 crecord: delete commented line
Nathan Goldbaum <ngoldbau@illinois.edu> [Wed, 14 Sep 2016 11:39:47 -0500] rev 29942
crecord: delete commented line
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip