The original issue was something like:
$ hg init repo
$ cd repo
$ mkdir D
$ echo a > D/a
$ hg ci -Am adda
adding D/a
$ mv D temp
$ mv temp d
$ echo b > d/b
$ hg add d/b
adding D/b
$ hg ci -m addb
$ hg mv d/b d/c
moving D/b to d/c
$ hg st
A d/c
R D/b
Here we expected:
A D/c
R D/b
the logic being we try to preserve case of path components already known in the
dirstate. This is fixed by the current patch.
Note the following stories are not still not supported:
Changing directory case
$ hg mv D d
moving D/a to D/D/a
moving D/b to D/D/b
$ hg st
A D/D/a
A D/D/b
R D/a
R D/b
or:
$ hg mv D/* d
D/a: not overwriting - file exists
D/b: not overwriting - file exists
And if they were, there are probably similar issues with diffing/patching.
The --amend flag can be used to amend the parent of the working directory
with a new commit that contains the changes in the parent in addition to
those currently reported by "hg status", if there are any. The old commit
is stored in a backup bundle in ".hg/strip-backup"(see "hg help bundle"
and "hg help unbundle" on how to restore it).
Message, user and date are taken from the amended commit unless specified.
When a message isn't specified on the command line, the editor will open
with the message of the amended commit.
It is not possible to amend public changesets (see "hg help phases") or
changesets that have children.
Behind the scenes, first commit the update (if there is one) as a regular
child of the current parent. Then create a new commit on the parent's
parent with the updated contents. Then change the working copy parent
to this new combined changeset. Finally, strip the amended commit and
update commit created in the beginning.
An alternative (cleaner?) approach of doing this is suggested here:
http://selenic.com/pipermail/mercurial-devel/2012-March/038540.html
It is currently not possible to amend merge commits or recursively,
this can be added at a later time.
When a subrepo is reverted but --no-backup is not set, call revert on the
subrepo that is being reverted prior to updating it to the revision specified
in the parent repo's .hgsubstate file.
The --all flag is passed down to the subrepo when it is being reverted. If the
--all flag is not set, all files that are modified on the subrepo will be
reverted.
Reverting a subrepo is done by updating it to the revision that is selected on
the parent repo .hgsubstate file.
* ISSUES/TODO:
- reverting added and removed subrepos is not supported yet.
- reverting subrepos is only supported if the --no-backup flag is used (this
limitation will be removed on another patch).
- The behavior of the --all flag has been changed. It now reverts subrepos as
well. Note that this may lead to data loss if the user has a dirty subrepo.
This revision has no functionality change. The code on the original
commands.revert() function has been split. The first part of the
original code, which checks that the command inputs are correct
remains in commands.revert(). The rest of the function, which performs
the actual revert operation has been moved into cmdutil.revert().
The purpose of this change is to make it easier to perform a revert
operation, from other parts of the code. This may be used to implement
reverting of subrepos.
Currently, --follow FILE looks for a FILE filelog, scans it and collects
linkrevs and renames, then filters them. The problem is the filelog scan does
not start at FILE filenode in parent revision but at the last filelog revision.
So:
- Files not in the parent revision can be followed, the starting node is
unexpected
- Files in the parent revision can be followed from an incorrect starting
node.
This patch makes log --follow FILE fail if FILE is not in parent revision, and
computes ancestors of the parent revision FILE filenode.
in 'cmdutil.forget()':
for f in match.files():
if match.exact(f) or not explicitonly:
....
is equal to:
for f in match.files():
if True:
....
because 'f' from 'match.files()' should 'match.exact(f)':
- 'match.files()' returns 'self._files'
- 'match.exact(f)' examines 'f in self._fmap',
- 'self._fmap' of match is 'set(self._files)'
then, 'explicitonly' wants to suppress warning messges, if it is true
(= 'cmdutil.forget()' is invoked from 'subrepo.forget()').
so, current code should be fixed as:
if not explicitonly:
for f in match.files():
....
Before, Mercurial would crash with a traceback ending with
SyntaxError: unmatched quotes
if you configured
[ui]
logtemplate = {rev}\n
The SyntaxError is now catched and the string is re-parsed without
requiring quotes.
When support for handling explicit paths in subrepos was added to the forget
command (155b89136ae7), subrepo recursion wasn't taken into account. This
change fixes that by pulling the majority of the logic of commands.forget into
cmdutil.forget, which can then be called from both there and subrepo.forget.
When support for handling explicit paths in subrepos was added to the add
command (825c4cefde4b), subrepo recursion wasn't taken into account. This
change adds an explicitonly argument to cmdutil.add to allow controlling which
levels of recursion should include only explicit paths versus all matched
paths.
When a user requested a diff between a revision (r1) that contained a subrepo
and another (r2) that did not, mercurial would crash if r1 was specified before
r2 but would execute the diff otherwise. This fixes this behavior by skipping
the missing subrepo in the diff.
An alias for 'log' was stored in the same command table as
'^log|history'. If the hash function happens to give the latter first,
the alias is effectively ignored when matching 'log'.
Change the behavior of the add command such that explicit paths in
subrepos are always added. This eliminates the previous behavior
where if you called "hg add" for an explicit path in a subrepo
without specifying the -S option, it would be silently ignored.
If you specify patterns, or no arguments at all, the -S option
will still be needed to activate recursion into subrepos.
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
If the ui I/O descriptors aren't real descriptors, they cannot be duped.
Instead, we return a wrapper object that behaves the same, and
can be closed (by overriding close and doing nothing).
Inlining it into it's last remaining call place in cmdutil.copy.
Note that cmdutil.copy is called with the wlock already held, so no additional
locking is needed to call util.unlinkpath.
We do not need to wrap the util.unlinkpath call into a try block, because
at that point we already know whether abssrc exists or not -- thanks to the
preceding util.copyfile call. Adding a new local 'srcexists' in cmdutil.copy
for that purpose.
These open the changelog and manifest, respectively, directly so you don't
need to specify the path.
The options have been added to debugindex, debugdata and debugrevlog.
The patch also fixes some minor usage-related bugs.
This will be necessary once util.readfile() operates in binary mode. While
changelog.add() already normalizes the message, doing so in logmessage() is
required as ui.edit() or others expect messages with LF only.
The Mercurial 1.9 release is moving a lot of stuff around anyway and we are
already moving path_auditor from util.py to scmutil.py for that release.
So this seems like a good opportunity to do such a rename. It also strengthens
the current project policy to avoid underbars in names.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
On a case-sensitive file system, files can be added with names that differ
only in case (a "case collision"). This would cause an error on case-insensitive
filesystems. A warning or error is now given for such collisions, depending on
the value of ui.portablefilenames ('warn', 'abort', or 'ignore'):
$ touch file File
$ hg add --config ui.portablefilenames=abort File
abort: possible case-folding collision for File
$ hg add File
warning: possible case-folding collision for File
On POSIX platforms, the 'add', 'addremove', 'copy' and 'rename' commands now
warn if a file has a name that can't be checked out on Windows.
Example:
$ hg add con.xml
warning: filename contains 'con', which is reserved on Windows: 'con.xml'
$ hg status
A con.xml
The file is added despite the warning.
The warning is ON by default. It can be suppressed by setting the config option
'portablefilenames' in section 'ui' to 'ignore' or 'false':
$ hg --config ui.portablefilenames=ignore add con.xml
$ hg sta
A con.xml
If ui.portablefilenames is set to 'abort', then the command is aborted:
$ hg --config ui.portablefilenames=abort add con.xml
abort: filename contains 'con', which is reserved on Windows: 'con.xml'
On Windows, the ui.portablefilenames config setting is irrelevant and the
command is always aborted if a problematic filename is found.
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
Currently, cmdutil.make_file() will return a freshly made file handle,
except when given a pattern of '-'. If callers would want to close the
handle, they would have to make sure that it's neither sys.stdin or
sys.stdout. Instead, returning a duplicate of either of the two
ensures that make_file() lives up to its name and creates a new
file handle regardless of the input.
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
This gives the repository control over which nested repository paths
that should be allowed via the custom path auditor.
Since paths into subrepositories are now allowed, dirstate.walk must
now filter away more paths than before.
== What ==
issue732 is only one example of a buggy behaviour, but there are in fact many
intricated cases. For example:
( "o" contains an alive version of the tracked file, "x" does not)
tip - o - o - x - o - o - x ...
\
o - o - o - o - x ...
\ /
o - o
This repository contains at least two instances of the tracked file, but
when calling "hg log -f file" only the latest one (the one alive in tip)
matters to us.
== How ==
We must extract from the filelog the history of the file instance we're
interested in and discard changes related to other instances of that file.
We see that we're only interested in ancestors(node), and that all
other nodes in the filelog should not be considered.
The same variable is defined a few blocks earlier. The first phases in
walkchangerevs should in fact fill that cache, and allow faster lookups
in the last phase. Redefining and overriding this cached function, (knowing
that it will be called with the same arguments) defeats the caching purpose.
