Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 12 May 2015 11:44:14 -0700] rev 25021
commit: no longer allow empty commit with the 'force' argument (API)
The new way to allow empty commit is to temporarily set the
'ui.allowemptycommit' config option.
allowemptyback = repo.ui.backupconfig('ui', 'allowemptycommit')
try:
repo.ui.setconfig('ui', 'allowemptycommit', True)
repo.commit(...)
finally:
repo.ui.restoreconfig(allowemptyback)
All known uses of force for allowing empty commits have been removed, so let's
remove it from the allowemptycommits condition.
Durham Goode <durham@fb.com> [Mon, 11 May 2015 20:15:41 -0700] rev 25020
import: use ui.allowemptycommit to allow empty commits
Previously import used force=partial to allow empty commits to be made. Let's
switch it to using the new ui.allowemptycommit option. Tests says we can drop
the 'force' argument in the processs.
Durham Goode <durham@fb.com> [Mon, 11 May 2015 17:51:22 -0700] rev 25019
mq: use ui.allowemptycommit to allow empty commits
Previously, mq used the force flag to allow empty commits. Now that we have
ui.allowemptycommit let's switch to that instead. We can't completely remove the
force flag since it is used for a bunch of other behavior in localrepo.commit.
Durham Goode <durham@fb.com> [Mon, 11 May 2015 16:18:28 -0700] rev 25018
commit: add ui.allowemptycommit config option
This adds a config flag that enables a user to make empty commits.
This is useful in a number of cases.
For instance, automation that creates release branches via
bookmarks may want to make empty commits to that release bookmark so that it
can't be fast-forwarded and so it can record information about the release
bookmark's creation. This is already possible with named branches, so making it
possible for bookmarks makes sense.
Another case we've wanted it is for mirroring repositories into Mercurial. We
have automation that syncs commits into hg by running things from the command
line. The ability to produce empty commits is useful for syncing unusual commits
from other VCS's.
In general, allowing the user to create the DAG as they see fit seems useful,
and when I mentioned this in IRC more than one person piped up and said they
were already hacking around this limitation by using mq, import, and
commit-dummy-change-then-amend-the-content-away style solutions.
Durham Goode <durham@fb.com> [Mon, 11 May 2015 16:16:22 -0700] rev 25017
commit: move empty commit condition to a new line
The empty commit condition was a messy if condition. Let's move it to a new line
and change it to 'or' statements so it's cleaner and more readable. A future
commit will add additional logic to this line.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 May 2015 15:04:14 -0700] rev 25016
dirs: speed up by storing number of direct children per dir
The Python version of the dirs type stores only the number of direct
children associated with each directory. That means that while adding
a directory, it only has to walk backwards until it runs into a
directory that is already in its map. The C version walks all the way
to the top-most directory. By copying the Python version's clever
trick to the C code, we can speed it up quite a bit.
On the Firefox repo, perfdirs now runs in 0.031390, from 0.056518
before the undoing Sid's optimization in the previous change, and
0.061835 before previous his optimization. More practically, it speeds
up 'hg status nonexistent' on the Firefox repo from 0.176s to 0.155s.
It's unclear why the C version did not have the same cleverness
implemented from the start, especially given that they were both
written by the same person (Bryan O'Sullivan) very close in time:
856960173630 (scmutil: add a dirs class, 2013-04-10)
02ee846b246a (scmutil: rewrite dirs in C, use if available, 2013-04-10)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 May 2015 15:09:28 -0700] rev 25015
dirs: back out forward-searching in finddirs()
This backs out the changes below. The next patch will implement a
faster algorithm based on backward-walking in finddirs().
67241ee427cf (dirs._addpath: reinstate use of Py_CLEAR, 2015-04-07)
6f0e6fa9fdd7 (dirs._addpath: don't mutate Python strings after exposing them (
issue4589), 2015-04-06)
1a9efc312700 (dirs.addpath: rework algorithm to search forward, 2015-03-27)
Ryan McElroy <rmcelroy@fb.com> [Wed, 15 Apr 2015 08:19:36 -0700] rev 25014
templatekw: replace currentbookmark with activebookmark keyword
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Ryan McElroy <rmcelroy@fb.com> [Wed, 15 Apr 2015 08:12:04 -0700] rev 25013
templatekw: introduce activebookmark keyword
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Ryan McElroy <rmcelroy@fb.com> [Wed, 15 Apr 2015 08:26:01 -0700] rev 25012
templatekw: rename variable current to active
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.