timeless <timeless@mozdev.org> [Wed, 21 Sep 2016 02:46:59 +0000] rev 29984
demandimport: add trailing comma
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:49:20 +0000] rev 29983
tests: favor single quotes for wrapping hg help ...
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:49:00 +0000] rev 29982
samplehgrcs: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:48:30 +0000] rev 29981
util: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:48:19 +0000] rev 29980
obsolete: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:48:08 +0000] rev 29979
localrepo: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:47:46 +0000] rev 29978
help: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:47:30 +0000] rev 29977
discovery: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:47:02 +0000] rev 29976
serve: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:46:15 +0000] rev 29975
bundle: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:45:25 +0000] rev 29974
histedit: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:45:15 +0000] rev 29973
keyword: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:59 +0000] rev 29972
mq: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:49 +0000] rev 29971
pager: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 23:44:28 +0000] rev 29970
rebase: use single quotes in use warning
timeless <timeless@mozdev.org> [Tue, 20 Sep 2016 20:12:38 +0000] rev 29969
push: update help hint to point to config.paths section
timeless <timeless@mozdev.org> [Fri, 02 Sep 2016 21:49:33 +0000] rev 29968
update: use single quotes in use warning
timeless <timeless@mozdev.org> [Fri, 02 Sep 2016 21:46:00 +0000] rev 29967
remove: specify hg in added warning
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29966
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.
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29965
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.
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29964
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.
Durham Goode <durham@fb.com> [Tue, 20 Sep 2016 12:24:01 -0700] rev 29963
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.
Augie Fackler <augie@google.com> [Mon, 19 Sep 2016 17:14:43 -0400] rev 29962
copy: document current behavior of 'hg cp --after'
I'm about to propose an output change here, but the existing behavior
was untested!
Nathan Goldbaum <ngoldbau@illinois.edu> [Tue, 20 Sep 2016 10:03:50 -0500] rev 29961
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.
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 14:24:00 +0900] rev 29960
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.
Yuya Nishihara <yuya@tcha.org> [Tue, 03 May 2016 14:18:28 +0900] rev 29959
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.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Sep 2016 09:14:35 -0700] rev 29958
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.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Sep 2016 09:14:32 -0700] rev 29957
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.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Sep 2016 09:45:29 -0700] rev 29956
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).
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Sep 2016 10:18:56 -0700] rev 29955
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.