ignore: resolve ignore files relative to repo root (issue4473) (BC) Previously these would be considered to be relative to the current working directory. That behavior is both undocumented and doesn't really make sense. There are two reasonable options for how to resolve relative paths: - relative to the repo root - relative to the config file Resolving these files relative to the repo root matches existing behavior with hooks. An earlier discussion about this is available at http://mercurial.markmail.org/thread/tvu7yhzsiywgkjzl. Thanks to Isaac Jurado <diptongo@gmail.com> for the initial patchset that spurred the discussion.

test-hgignore: add testing for ui.ignore I couldn't find any tests for this, and we're going to make changes here in upcoming patches.

tests: add missing globs for Windows I couldn't figure out how to glob the first chunk for Windows, so it's been conditionalized.

share: use the 'sharedpath' attr on repo instead of reloading from the file Seems like a useful optimization, and now the exact file content is not a concern.

share: fix source repo lookup on Windows The stored path contains platform specific separators, so splitting on '/.hg' returned the string unmodified on Windows. The source was then looked for in $source/.hg/.hg, which obviously fails. This caused cascading errors in test-share.t relating to the recent bookmark support.

help: suggest '-v -e' to get built-in aliases for extensions (issue4461) If extension name matches one of command names, suggest user to type 'hg help -v -e <extension>' to get full list of built-in aliases

test-check-commit-hg: clarify misleading "commit message rules" error The test case doesn't only check the commit message, but also the patch, which can result in confusing output like + Revision df6f06d17100 does not comply to commit message rules + ------------------------------------------------------ + 32: adds double empty line + + even when there are no double blank lines in the commit message. Drop the "commit message" part to make it less confusing.

keyword: handle resolve to either parent Merged files are considered modified at commit time even if only 1 parent differs. In this case we must use the change context of this parent for expansion. The issue went unnoticed for long because it is only apparent until the next update to the merge revision - except in test-keyword where it was always staring us in the face.

keyword: update test file syntax

branches: deprecate -a

largefiles: fix a spurious missing file warning with forget (issue4053) If an uncommitted and deleted file was forgotten, a warning would be emitted, even though the operation was successful. See the previous patch for 'remove -A' for the exact circumstances, and details about the cause.

largefiles: fix a spurious missing file warning with 'remove -A' (issue4053) The bug report doesn't mention largefiles, but the given recipe doesn't fail unless the largefiles extension is loaded. The problem only affected normal files, whether or not any largefiles are committed, and only files that have not been committed yet. (Files with an 'a' state are dropped from dirstate, not marked removed.) Further, if the named normal file never existed, the warning would be printed out twice. The problem is that the core implementation of remove() calls repo.status(), which eventually triggers a dirstate.walk(). When the file isn't seen in the filesystem during the walk, the exception handling finds the file in dirstate, so it doesn't complain. However, the largefiles implementation called status() again with all of the original files (including the normal ones, just dropped). This time, the exception handler doesn't find the file in dirstate and does complain. This simply excludes the normal files from the second repo.status() call, which the largefiles extension has no interest is processing anyway.

largefiles: introduce the 'composelargefilematcher()' method This is a copy/paste (with the necessary tweaks) of the composenormalfilematcher method currently on default, which does the inverse- this trims the normal files out of the matcher. It will be used in the next patch.

context: return dirstate parents in workingctx.ancestors() workingctx.ancestors() was not returning the dirstate parents as part of the result set. The only place this function is used is for copy detection when committing a file, and that code already checks the parents manually, so this change has no affect at the moment. I found it while playing around with changing how copy detection works.

backout: add --commit option Mercurial backout command makes a commmit by default only when the backed out revision is the parent of working directory and doesn't commit in any other case. The --commit option changes behaviour of backout to make a commit whenever possible (i.e. there is no unresolved conflicts). This behaviour seems more intuitive to many use (especially git users migrating to hg).

share: add option to share bookmarks This patch adds the -B/--bookmarks option to the share command added by the share extension. All it does for now is create a marker, 'bookmarks.shared', that will be used by future code to implement the sharing functionality.

highlight: ignore Unicode's extra linebreaks (issue4291) Unicode and Python's unicode.splitlines() treat several extra legacy ASCII codepoints as linebreaks, even though the vast bulk of computing and Python's own str.splitlines() do not. Rather than introduce line numbering confusion, we filter them out when highlighting.

test: fix typo in test-help.t

templatekw: remove unneeded showtags Now that we have the machinery of namespaces in-place, we use that instead of hand-rolling our own template function. Note, this can only be used for tags because both branches and bookmarks have special case logic for 'default' and the current bookmark (which is something outside the namespace api for now).

namespaces: generate template keyword when registering a namespace For any namespace, we generate a template keyword. For example, given a namespace 'babar', we automatically have the ability to use it in a template: hg log -r . -T '{babars % "King: {babar}\n"}' Furthermore, we only generate this keyword for a namespace if one doesn't already exist. This is necessary for 'branches' and 'bookmarks' since both of those have concepts of 'current' (something outside the namespace api) and also allows extensions to override default behavior if desired.

templatekw: add helper method to generate a template keyword for a namespace This marks our second feature of the namespace api: automatic template keyword. This patch adds a method that takes in a namespace and uses the node-to-name map to output the list of names.

namespaces: add names method to return list of names for a given node In the previous patch, we added a node-to-name map property. This patch just exposes that interface to the api.

namespaces: add nodemap property This patch adds a node-to-name map property to the namespace. This is necessary because we cannot simply invert the name-to-node map because we do not assume the name-to-node map to be unique (for example, consider named branches: many nodes have one branch name). The node-to-name is helpful in log commands where we are already iterating over a set of nodes and want to display some kind of naming information to the user.

namespaces: add method to get template name of namespace This patch adds the public api for getting the template name of a namespace so that the next patch can use it to generate a template keyword automatically.

namespaces: add template name of a namespace The template name property will be used in upcoming patches to automatically generate a template keyword. For example, given a namespace called 'babars', we will automatically generate a template keyword 'babar' such that we can use it in the following way, $ hg log -r . -T '{babars % "King: {babar}\n"}'

memctx: remove redundant test for issue4470 from test-commit.t Because: - the test to avoid regression for issue4470 was already added to test-commit-amend.t by previous patch It is also a part of test series about manifest calculation issues of memctx in test-commit-amend.t. - this is the only test using "commit --amend" in test-commit.t

memctx: calculate manifest more efficiently Before this patch, "memctx._manifest" updates all entries in the (parent) manifest. But this is inefficiency, because almost all files may be clean in that context. On the other hand, just updating entries for changed "files" specified at construction causes unexpected abortion, when there is at least one newly removed file (see issue4470 for detail). To calculate manifest more efficiently, this patch replaces "pman.iteritems()" for the loop by "self._status.modified" to avoid updating entries for clean or removed files Examination of removal is also omitted, because removed files aren't treated in this loop (= "self[f]" returns not None always).

merge with stable

Added signature for changeset 6dad422ecc5a

Added tag 3.2.3 for changeset 6dad422ecc5a

pathauditor: check for Windows shortname aliases

pathauditor: check for codepoints ignored on OS X

darwin: omit ignorable codepoints when normcase()ing a file path This lets us avoid some nasty case collision problems in OS X with invisible codepoints.

encoding: add hfsignoreclean to clean out HFS-ignored characters According to Apple Technote 1150 (unavailable from Apple as far as I can tell, but archived in several places online), HFS+ ignores sixteen specific unicode runes when doing path normalization. We need to handle those cases, so this function lets us efficiently strip the offending characters from a UTF-8 encoded string (which is the only way it seems to matter on OS X.)

test-casefolding.t: demonstrate a bug with HFS+ ignoring some codepoints

manifest: disallow setting the node id of an entry to None manifest.diff() uses None as a special value to denote the absence of a file, so setting a file node to None means you then can't trust manifest.diff(). This should also make future manifest work slightly easier.

context: stop setting None for modified or added nodes Instead use a magic value, so that we can identify modified or added nodes correctly when using manifest.diff(). Thanks to Martin von Zweigbergk for catching that we have to update _buildstatus as well. That part eluded my debugging for some time.

largefiles: don't actually remove largefiles in an addremove dry run The addlargefiles() method already properly handled dry runs.

bundle2: lowercase part types Since the capitalization no longer carries any meaning (previous diff), this patch normalizes all of the bundle2 part type strings to lower case.

bundle2.bundlepart: make mandatory part flag explicit in API This makes all bundle2 parts mandatory unless they are expressly made advisory via the keyword parameter or the bundlepart.mandatory property.

memctx: calculate manifest correctly with newly-removed files (issue4470) Before this patch, "memctx._manifest" tries to get (and use normally) filectx also for newly-removed files, even though "memctx.filectx()" returns None for such files. To calculate manifest correctly even with newly-removed files, this patch does: - replace "man.iteritems()" for the loop by "self._status.modified" to avoid accessing itself to newly removed files this also reduces loop cost for large manifest. - remove files in "self._status.removed" from the manifest In this patch, amending is confirmed twice to examine both (1) newly removed files and (2) ones already removed in amended revision.

memctx: calculate manifest including newly added files correctly Before this patch, "memctx._manifest" calculates the manifest according to the 1st parent. This causes the disappearance of newly added files from the manifest. For example, if newly added files aren't listed up in manifest of memctx, they aren't listed up in "added" field of "status" returned by "ctx.status()", and "{diff()}" (= "patch.diff") in "committemplate" shows nothing for them. To calculate manifest including newly added files correctly, this patch puts newly added files (= ones in "self._status.added") into the manifest. Some details of changes for "test-commit-amend.t" in this patch: - "touch foo" is replaced by "echo foo > foo", because newly added empty file can't be shown in "diff()" output without "diff.git" configuration - amending is confirmed twice to examine both (1) newly added files and (2) ones already added in amended revision

memctx: calculate exact status being committed from specified files Before this patch, "memctx._status" is initialized by "(files, [], [], [], [], [], [])" and this causes "memctx.modified" to include not only modified files but also added and removed ones incorrectly. This patch adds "_status" method to calculate exact status being committed according to "files" specified at construction time. Exact "_status" is useful to share/reuse logic of committablectx. This patch is also preparation for issues fixed by subsequent patches. Some details of changes for tests in this patch: - some filename lines are omitted in "test-convert-svn-encoding.t", because they are correctly listed up as "removed" files those lines are written out in "localrepository.commitctx" for "modified" and "added" files by "ui.note". - "| fixbundle" filterring in "test-histedit-fold.t" is omitted to check lines including "added" correctly "fixbundle" discards all lines including "added".

bundle2._processpart: forcing lower-case compare is no longer necessary Encoding whether or not a part is mandatory in the capitalization of the parttype is unintuitive and error-prone. This sequence of patches separates these concerns in the API to reduce programmer error and pave the way for a potential change in how this information is transmitted over the wire. Since the parttype and mandatory bit are separated in bundle2.unbundlepart (see previous patch), there is no longer a need to remove the mandatory bit before working with the parttype.

bundle2.unbundlepart: decouple mandatory from parttype Encoding whether or not a part is mandatory in the capitalization of the parttype is unintuitive and error-prone. This sequence of patches separates these concerns in the API to reduce programmer error and pave the way for a potential change in how this information is transmitted over the wire. This patch separates the two pieces of information when reading the part header so that it's unnecessary to know how they were combined during transmission.

memctx: fix manifest for removed files (issue4470) filectxfn returns None for removed files, so we have to check for None before computing the new file content hash for the manifest. Includes a test that proves this works, by demonstrating that we can show the diff of an amended commit in the committemplate.

convert: on svn failure, note libsvn version (issue4043) We have our own fast-path logic to see if something passes a sniff test for being a Subversion repository, but it's possible for a user to svnsync a repo using svn 1.8 and then use svn 1.7 bindings (as in the bug) to try and convert the repo. If we at least tell the user the version of libsvn that we used, they might get enough of a hint to check on their own for format incompatibilities between their svn{admin,sync} and the libsvn used by hg.

vfs: add a 'split' method This method has the same behavior as the 'os.path.split' function, but having it in vfs will allow handling of tricky encoding situations in the future. In the same patch, we replace the use of 'os.path.split' in the transaction code.

vfs: add a 'reljoin' function for joining relative paths The vfs.join method only works for absolute paths. We need something that works for relative paths too when transforming filenames. Since os.path.join may misbehave in tricky encoding situations, encapsulate the new join method in our vfs abstraction. The default implementation remains os.path.join, but this opens the door to other VFSes doing something more intelligent based on their needs. In the same go, we replace the usage of 'os.path.join' in transaction code.

subrepo: fix git subrepo ui argument

subrepo: drop the 'ui' parameter to revert() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in revert is to emit status and warning messages, and to check the verbose flag prior to printing the action to be performed on a file. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call. Unlike other methods where the matcher is passed along and narrowed, a new matcher is created in each repo, and therefore the bad() method already used the local repo's ui.

subrepo: drop the 'ui' parameter to removefiles() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in remove is to emit status and warning messages, and to check the verbose flag prior to printing files to be removed. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call.

subrepo: drop the 'ui' parameter to forget() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in forget is to emit status and warning messages, and to check the verbose flag prior to printing files to be forgotten. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call.

subrepo: drop the 'ui' parameter to cat() This no longer needs to be explicitly passed because the subrepo object tracks a 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in cat is to emit a status message when a subrepo is missing. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object.

subrepo: drop the 'ui' parameter to archive() The current state of subrepo methods is to pass a 'ui' object to some methods, which has the effect of overriding the subrepo configuration since it is the root repo's 'ui' that is passed along as deep as there are subrepos. Other subrepo method are *not* passed the root 'ui', and instead delegate to their repo object's 'ui'. Even in the former case where the root 'ui' is available, some methods are inconsistent in their use of both the root 'ui' and the local repo's 'ui'. (Consider hg._incoming() uses the root 'ui' for path expansion and some status messages, but also calls bundlerepo.getremotechanges(), which eventually calls discovery.findcommonincoming(), which calls setdiscovery.findcommonheads(), which calls status() on the local repo 'ui'.) This inconsistency with respect to the configured output level is probably always hidden, because --verbose, --debug and --quiet, along with their 'ui.xxx' equivalents in the global and user level hgrc files are propagated from the parent repo to the subrepo via 'baseui'. The 'ui.xxx' settings in the parent repo hgrc file are not propagated, but that seems like an unusual thing to set on a per repo config file. Any 'ui.xxx' options changed by --config are also not propagated, because they are set on repo.ui by dispatch.py, not repo.baseui. The goal here is to cleanup the subrepo methods by dropping the 'ui' parameter, which in turn prevents mixing subtly different 'ui' instances on a given subrepo level. Some methods use more than just the output level settings in 'ui' (add for example ends up calling scmutil.checkportabilityalert() with both the root and local repo's 'ui' at different points). This series just goes for the low hanging fruit and switches methods that only use the output level. If we really care about not letting a subrepo config override the root repo's output level, we can propagate the verbose, debug and quiet settings to the subrepo in the same way 'ui.commitsubrepos' is in hgsubrepo.__init__. Archive only uses the 'ui' object to call its progress() method, and gitsubrepo calls status().

subrepo: use 'self.ui' instead of 'self._repo.ui' They are now equivalent, but the former is slightly more readable.

subrepo: reset 'self.ui' to the subrepo copy of 'ui' in the hgsubrepo class Creation of the subrepo's '_repo' object creates a new 'ui' by combining the parent repo's 'baseui' and reading in the subrepo's hgrc file. This simply avoids 'self.ui' and 'self._repo.ui' pointing to different objects, which seems like a potential source of bugs. Git and Svn subrepos are unchanged, because they don't have their own ui, and have always used their parent's for their configuration.

subrepo: rename the '_ui' member to 'ui' The localrepository class has a 'ui' member, so keeping the names the same will allow for duck typing with subrepo instances when accessing 'ui'. Changing this is easier than finding all of the localrepository instance uses and renaming that to '_ui'.

subrepo: drop the '_ui' member in the subrepo subclasses This member has existed in the base class since fcbc66b5da6a.

graphmod: attempt to clarify documentation of groupbranchiter() Thanks to Pierre-Yves for checking my cleanups here and helping me understand the algorithm well enough to help document it.

graphmod: rename graph-topological config to graph-group-branches The latter suggests what the change is slightly better.

groupbranchiter: allow callers to select the first branch Instead of just bootstrapping the algorithm with the first revision we see, allow callers to pass revs that should be displayed first. All branches are retained until we can display such revision. Expected usage is to display the current working copy parent first.

groupbranchiter: support for non-contiguous revsets The algorithm now works when some revisions are skipped. We now use "first included ancestors" instead of just "parent" to link changesets with each other.

groubranchhiter: indent most of the inner code We are going to add an additional layer of indentation to support non-contiguous revset. We do it in a pure code movement changeset to help the readability of the next changeset.

graphlog: add a way to test the 'groupbranchiter' function We add an experimental config option to use the topological sorting. I first tried to hook the 'groupbranchiter' function in the 'sort' revset but this was useless because graphlog enforces revision number sorting :( As the goal is to advance on the topological iteration logic, I see this experimental option as a good way to move forward. We have to use turn the iterator into a list because the graphlog is apparently not ready for pure iterator input yet.

graphmod: add a function for topological iteration This changeset introduces a function to perform topological (one branch after the other) iteration over a set of changesets. This first version has a lot of limitations, but the approach should be flexible enough to allow many improvements in the future. This changeset aims to set the first stone more than providing a complete solution. The algorithm does not need to know the whole set of nodes involved before emitting revision. This makes it a good candidate for usage in place like `hg log` or graphical tools that need a fast first result time.

namespaces: add branches Note that the exception-catching from the previous branchtip check is moved up to catch exceptions from the try block surrounding the namespace lookup.

namespaces: add tags

namespaces: remove weakref; always pass in repo It turns out that maintaining a reference of any sort (even weak!) to the repo when constructed doesn't work because we may at some point pass in a repoview filtered by something other than what the initial repo was.

changectx: use names api to simplify and extend node lookup Previously, changectx had to know about each type of name (bookmark, tag, etc.) to look up. Now, we use repo.namenodes to simplify (and extend) this.

namespaces: add a method to the first matching node for a given name

namespaces: add bookmarks to the names data structure This marks the first use of abstracting our different types of named objects (bookmarks, tags, branches, etc.) and upcoming patches will use this to simplify logic.

namespaces: add a convenience property for the weakref _repo

namespaces: pass repo to __init__ We store repo as a weakref so that we can prevent a cycle between namespaces and localrepo.

namespaces: add a function to turn single results into lists

namespaces: add a method to register new namespaces

namespaces: introduce a generic way to map between names and nodes This patch begins the work to provide a way to register a namespace to handle 'names'. Benefits of this would be, - improved templating: This would provide {name} which could output any branch, bookmark, tag, or any extension registered namespace all without having the extension doing any extra work - improved tab completion: Since this provides a single source of all 'names', tab completion would not need to know of each namespace - changeset lookup: Similar to before, a unified place to get all 'names' will allow finding changesets without any extension code having to reimplement this Also, d226fe36e362 has shown us that for internal code which expects a certain type of method or behavior, we should provide an easy way for extensions to check this behavior.

statichttprepo: update profile of __call__ in mock vfs object New code paths could fail because the old statichttprepo profile couldn't handle the usual parameters. Instead, reuse a more generic profile also used in readonlyvfs.

tests: avoid git diffstat singular/plural output difference 'git diff --stat' output changed with regard to the amount of changes/insertions/deletions shown. In older git versions (1.7.7.6), output was shown as: 2 files changed, 2 insertions(+), 1 deletions(-) In newer versions, output is shown as: 2 files changed, 2 insertions(+), 1 deletion(-) This patch uses a regex to handle both cases.

subrepo: add revert support without backup for git subrepos Previously, git subrepos did not support reverting. This change adds basic support for reverting when '--no-backup' is specified. A warning is given (and the current state is kept) when a revert is done without the '--no-backup' flag.

match: make 'always' and 'exact' functions, not classes There is no reason for classes 'always' and 'exact' not to be just functions that return instances the plain 'match' class.

share: implement shared bookmark functionality This does not cause any behavioral change unless a 'bookmarks.shared' marker file exists. A future change will add UI to create this file when a repository is shared.

debugindex: respect --debug flag to show full nodeids

localrepo.clone: add a way to override server preferuncompressed Without this patch, if the server sets preferuncompressed, there's no way for clients to override that and force a non-streaming clone. With this patch, we extend the meaning of --pull to also override preferuncompressed and force a non-streaming clone.

hg.clone: set 'stream' depending on whether --pull was requested or not In an upcoming patch we'll differentiate between the two in localrepo.

merge: perform case-collision checking on final set of actions When there are multiple common ancestors, we should check for case collisions only on the resulting actions after bid merge has run. To do this, move the code until after bid merge. Move it past _resolvetrivial() too, since that might update actions. If the remote changed a file and then reverted the change, while the local side deleted the file and created a new file with a name that case-folds like the old file, we should fail before this patch but not after. Although the changes to the actions caused by _forgetremoved() should have no effect on case collisions, move it after that, too, so the next person reading the code won't have to think about it. Moving it past these blocks of code takes it to the end of calculateupdates(), so let's even move it outside of the method, so we also check collisions in actions produced by extensions overriding the method.

spelling: fixes from proofreading of spell checker issues

tests: allow more flexibility in git diffstat output The output of 'git diff --stat' changed in git 1.7.10 and 1.7.11. To ensure the tests work with earlier versions of git as well, the output is now wrapped with a whitespace regex.

merge: move cd/dc prompts after largefiles prompts By moving the cd/dc prompts out of calculateupdates(), we let largefiles' overridecalculateupdates() so the unresolved values (i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows overridecalculateupdates() to ask the user whether to keep the normal file or the largefile before the user gets the cd/dc prompt. Whichever answer the user gives, we make overridecalculateupdates() replace 'cd' or 'dc' action, saving the user one annoying (and less clear) question.

addremove: automatically process a subrepository's subrepos Since addremove on the top of a directory tree will recursively handle sub directories, it should be the same with deep subrepos, once the user has explicitly asked to process a subrepo. This really only has an effect when a path that is a subrepo (or is in a subrepo) is given, since -S causes all subrepos to be processed already. An addremove without a path that crosses into a subrepo, will still not enter any subrepos, per backward compatibility rules.

addremove: support addremove with explicit paths in subrepos Git and svn subrepos are currently not supported.

addremove: add support for the -S flag Git and svn subrepos are currently not supported. It doesn't look like git or svn have these commands natively, so that's an area for a git or svn expert.

commit: propagate --addremove to subrepos if -S is specified (issue3759) The recursive addremove operation occurs completely before the first subrepo is committed. Only hg subrepos support the addremove operation at the moment- svn and git subrepos will warn and abort the commit.

subrepo: store the ui object in the base class This will be used in the next patch to print a warning from the base class. It seems better than having to explicitly pass it to a new method, since a lot of existing methods also require it.

commit: abort if --addremove is specified, but fails This will be required when subrepo support is added, in order to ensure consistent commits when a subrepo flavor doesn't support addremove.

addremove: warn when addremove fails to operate on a named path It looks like a bad path is the only mode of failure for addremove. This warning is probably useful for the standalone command, but more important for 'commit -A'. That command doesn't currently abort if the addremove fails, but it will be made to do so prior to adding subrepo support, since not all subrepos will support addremove. We could just abort here, but it looks like addremove has always silently ignored bad paths, except for the exit code.