Augie Fackler <augie@google.com> [Sat, 11 Apr 2015 18:20:44 -0400] rev 25031
python3: update killdaemons and run-tests print and exception syntax
test-run-tests.t still passes fine on Python 2.6. run-tests.py --local
no longer fails with syntax errors, and now fails looking for xrange.
Most changes done with
2to3 -w -f numliterals -f except -f print tests/run-tests.py tests/killdaemons.py
after which one import was fixed in run-tests and a __future__ import
was added.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 13 May 2015 11:49:38 -0700] rev 25030
check-code: allow with statements
We dropped python 2.4 compatibility.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 13 May 2015 11:41:17 -0700] rev 25029
check-code: allow 'Except EClass as variable:'
Python 2.4 compatibility has been dropped.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 13 May 2015 11:39:48 -0700] rev 25028
check-code: allow print and exec as a function
This is required to move forward on python3 compatibility.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2015 15:58:14 -0700] rev 25027
pathencode: for long paths, strip first 5 chars, not first dir
When encoding long paths, the pure Python code strips the first
directory from the path, while the native code currently strips the
first 5 characters. This discrepancy has not been a problem so far,
since we have not stored anything in directories other than
data/. However, we will soon be storing submanifest revlogs in
metadata/, so the discrepancy will have to go [1]. Since file
collisions are avoided by the hashing alone (which is done on the full
unencoded path), it doesn't really matter whether we drop the first
dir, the first 5 characters, or special-case non-data/. To avoid
touching the C code, let's always strip the first 5 characters.
[1] Or maybe elsewhere, but the discrepancy is ugly either way.
Adrian Buehlmann <adrian@cadifra.com> [Wed, 13 May 2015 18:57:38 +0200] rev 25026
util.h: kill no longer needed definitions for Python < 2.5
see
e1fb276d4619
Nat Mote <nmote@fb.com> [Tue, 12 May 2015 15:04:19 -0700] rev 25025
rebase: add short -k option for --keep
histedit and strip already have a short option for keep, so this makes the
interface more consistent
Yuya Nishihara <yuya@tcha.org> [Mon, 30 Mar 2015 19:51:40 +0900] rev 25024
revset: test current behavior of addset class
The addset class isn't simple and it has a hidden bug that will be fixed by
future patches. So let's test the current behavior.
Yuya Nishihara <yuya@tcha.org> [Mon, 27 Apr 2015 23:03:20 +0900] rev 25023
revset: remove duplicated definition of choice() from addset._iterordered()
choice() is already defined before val1 = None. Perhaps there was merge or
rebase error.
Matt Mackall <mpm@selenic.com> [Tue, 12 May 2015 19:40:45 -0500] rev 25022
canonpath: fix infinite recursion
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.