The active bookmark were moved to the temporary commit. When the transaction
were rollbacked, the bookmark were lost.
We now temporarly disable the bookmark to prevent this effect.
The temporary commit created by amend update the dirstate. If the final commit
fails, we need to invalidate the change made to the dirstate, otherwise the
release of the wlock will write the dirstate created after the rollbacked
temporary commit.
This dirstate writing logic should probably be handled in the same object than
the transaction one. However such change are too big for stable.
cmdutil.getgraphlogrevs does a ton of work trying to build a graphlog lazily,
and then cmdutil.graphlog comes along and destroys all of that.
graphmod.dagwalker requires that it be given the full list of revs upfront so
that it can perform filtering and tests against known revs.
For a repository with over 400,000 changesets, this speeds up graphlog by
around 0.02 seconds (~20% with a small limit).
Color extension achieves colorization by overriding the class of
"ui" object just before command execution.
Before this patch, "diff()" of abstractsubrepo and classes
derived from it has no "ui" argument, so "diff()" of hgsubrepo
uses "self._repo.ui" to invoke "cmdutil.diffordiffstat()".
For separation of configuration between repositories, revision
1498948ee815 changed the initialization source of "self._repo.ui"
from "ui"(overridden) to "baseui"(plain) of parent repository.
And this caused break of colorization.
This patch adds "ui" argument to "diff()" of abstractsubrepo and
classes derived from it to pass "ui" object of caller side.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
Before this changeset the temporary changeset created by amend was made a
precursors on the amend result. This add unnecessary complexity to the
obsolescence graph. This temporary commit will probably disappear in the future.
It is an unwanted byproduct of amend that nobody cares about.
Obsolescence cycle are bad and should be avoided as much as possible. The
current amend implemented touch changeset meta data as few as possible. This
make is easy for amend to result in the same node than a precursors. We add some
deterministic noise in extra to avoid this. In practice, the hex of the amended
changeset is stored in 'amend_source' extra key.
The preceding patch causes that "makememctx()" with "editor" argument
saves (manually edited) commit message into ".hg/last-message.txt":
saving itself is executed indirectly in "memctx.__init__()".
This makes it redundant to invoke "savecommitmessage()" on caller side
of "makememctx()".
This patch omits such redundant "savecommitmessage()" invocation in
"tryimportone()".
"tryimportone()" uses one of "commiteditor" or "commitforceeditor" as
"editor" argument, and this causes saving commit message always.
This patch uses "editor" argument of "memctx.__init__" to save commit
message, instead of explicit editor invocation and saving commit
message by "localrepository.savecommitmessage()".
By passing one of "commiteditor" or "commitforceeditor" as "editor",
"memctx.__init__" saves commit message, even when editor invocation is
not needed.
This allows the user to set different colors for each phase, e.g.
[color]
changeset.public = blue
changeset.draft = green
changeset.secret = red
In addition, this doesn't affect current configuration for custom log.changeset
colors, but rather adds the option for users that want to visually see which
changesets are amendable.
'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory.
This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store.
To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store.
Before this changeset, the extra commit created during amend had
the same description as the final commit. This was a bit confusing
when trying to understand what that extra commit was about.
This changeset changes the description of such commit to:
temporary amend commit for <ammend-commit-hash>
The old behaviour was not a big deal, but would become more confusing
once we use obsolescence marker instead of stripping the precursors.
This also helps if the user restores a strip backup.
This allows proper recovery of an interrupted amend process.
No changes are made to the logic besides:
- indent operations into a single try-except clause,
- some comment and code wrapping to 80 chars,
- strip logic should not be contained in the transaction and is extracted from
the main code.
New commit from the amend process were created without any phase contraint. If
the amended changeset had a different phase from it's parent, the phases data
were lost.
The changeset ensure the new commit are created in the same phase than the
original changeset.
The export command didn't output the diffs in color, even when color support
was enabled. This patch fixes that by making the export command use the default
ui.write method, instead of directly manipulating the ui.fout file object.
Also added a test case to verify color output to test-export.t.
This set is always accessed through the repo for now. Having this set
carried by the changelog make it complicated to:
- initialize it, computing hidden set may involve revset call
- lazy compute it, (1) only the changelog can detect someone access it,
(2) only the repo have enought knowledge to compute it.
In later version I expect he changelog to apply filtering itself and the set to
be carried by changelog again.
Messing with the dirstate before the intermediate commit seems error prone.
Instead, commit and recompute the copies with copies.pathcopies(), then use
that with commitctx().
Since copies.pathcopies() does not support file replacement very well, the
whole .renamed() condition in samefile() is removed and the "file replacement
caused by differing copy source" effect is discarded.
Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
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.
Even with --removed, it does not make sense to examine changesets outside
of the revision range that was specified by the user: the last phase only
yields a subset of (revs), preparation phase hence only has to examine
(revs) to fill correctly fncache.
The revrange function was used further up, and when a local variable
is defined with the same name, the earlier call to revrange becomes a
'local variable used before assignment' error.
The clash was introduced in 3544b3baebb0.
When in the slowpath, we are examining _all_ changesets in revs.
We need to order reads so they happen increasingly for I/O performance.
Increasing windows were used to read changelog backwards in a windowed manner,
reading the changelog forward inside each window. But since no revision range
was specified, it was equivalent to reading the full changelog, even if a
single revision was passed to the commandline.
When --removed is used, we _need_ to scan all changesets, but if we're only
looking for file patterns, this is not necessary and we can stick to
the revspec that was given to us.
The purpose of increasing windows is to allow backwards iteration on the
filelog at a reasonable cost.
But is it needed?
- if follow is False, we have no reason to iterate backwards.
We basically just want to walk the complete filelog and yield all revisions
within the revision range. We can do this forward or
backwards, as it only reads the index.
- when follow is True, we need to examine the contents of the filelog, and to
do this efficiently we need to read the filelog forward.
And on the other hand, to track ancestors and copies, we need to process
revisions backwards. But is it necessary to use increasing windows
for this?
We can iterate over the complete filelog forward, stack the revisions, and
read the reversed(pile), it does the same thing with a more readable code.
In commands.log a displayer was initialized from
cmdutil.show_changeset() with the initial matchfn (which designates
the specified files which only is correct in the highest revision in
the range). prep() is handed the correct list of files, but
displayer.show() didn't use that list but keept using the original
matchfn.
The matchfn argument to cmdutil.show_changeset() wasn't specified in
other places and is only used in .show(), so now we give the matchfn
as an optional parameter to .show().
We do however still have to detect --patch and --stat from opts in
show_changeset() and let it imply a matchall, but that can now be
overruled with the new .show() matchfn parameter.
I routinely want to use `hg addrem` and then fix up missed renames
manually using `hg mv -A`. This patch allows me to record such
renames from a source in state R to a target in state A.
bisect: clarify None return
bundle: return 1 on no changes
clone: return result code
copy: limit errors to 0/1
commit: return 1 on no changes
forget: return 1 on errors
grep: return 1 if no match found
remove: return 1 on errors
resolve: return 1 if something fails to resolve
rollback: return 1 if no rollback data
Currently running 'hg rename --after foo.txt bar.typo' is a silent no-op. This patch adds a warning. It also updates the copy and rename tests.
No actual functionality is changed.
fixes issue 1822
The next few patches will increase the size of the "findrenames"
functionality. This patch simply moves the function into its own
file to avoid clutter building up in 'cmdutil.py'.
The file-based synchronization introduced by 670de588e29e hangs when the child
process fails before terminating the handshake, which the previous pipe-based
version handled correctly. To fix this, the parent polling loop was fixed to
detect premature terminations of the child process.
Hiding the child process window is not strictly necessary but it avoids opening
an empty shell window when running hg serve as well as a task in the task bar.
The window is hidden after the process is already started causing a single
flicker.
On Windows, Mercurial can be run from the python script of from a frozen
executable. In the first case, we have to call the python interpreter since the
script is not executable. Frozen executable can be called directly.
Fix 3/3 for issue421
The fact that a parent process spawns a daemon does not necessarily means that
it is the only think it has to do. This was forcing since e8efd88001e7 inotify
processes launched implicitely to exit prematurely:
when no inotify server was running, "hg st" for example would only launch a
inotify server, _exit(0) and thus would not return file statuses.
This changeset adds a test for implicitely launched inotify processes.
Change to output of test-inotify-1208 is correct: it reflects the normal
error message of "hg st" when not dying during "hg inserve" daemon creation.
