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).
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip