##// END OF EJS Templates
split: new extension to split changesets...
split: new extension to split changesets This diff introduces an experimental split extension to split changesets. The implementation is largely inspired by Laurent Charignon's implementation for mutable-history (changeset 9603aa1ecdfd54b0d86e262318a72e0a2ffeb6cc [1]) This version contains various improvements: - Rebase by default. This is more friendly for new users. Split won't lead to merge conflicts so a rebase won't give the user more trouble. This has been on by default at Facebook for months now and seems to be a good UX improvement. The rebase skips obsoleted or orphaned changesets, which can avoid issues like allowdivergence, merge conflicts, etc. This is more flexible because the user can decide what to do next (see the last test case in test-split.t) - Remove "Done split? [y/n]" prompt. That could be detected by checking `repo.status()` instead. - Works with obsstore disabled. Without obsstore, split uses strip to clean up old nodes, and it can even handle split a non-head changeset with "allowunstable" disabled, since it runs a rebase to solve the "unstable" issue in a same transaction. - More friendly editor text. Put what has been already split into the editor text so users won't lost track about where they are. [1]: https://bitbucket.org/marmoute/mutable-history/commits/9603aa1ecdfd54b Differential Revision: https://phab.mercurial-scm.org/D1082

File last commit:

r34950:ff178743 stable
r35494:02ea370c @7 default
Show More
merge-tools.txt
85 lines | 3.6 KiB | text/plain | TextLexer
To merge files Mercurial uses merge tools.
A merge tool combines two different versions of a file into a merged
file. Merge tools are given the two files and the greatest common
ancestor of the two file versions, so they can determine the changes
made on both branches.
Merge tools are used both for :hg:`resolve`, :hg:`merge`, :hg:`update`,
:hg:`backout` and in several extensions.
Usually, the merge tool tries to automatically reconcile the files by
combining all non-overlapping changes that occurred separately in
the two different evolutions of the same initial base file. Furthermore, some
interactive merge programs make it easier to manually resolve
conflicting merges, either in a graphical way, or by inserting some
conflict markers. Mercurial does not include any interactive merge
programs but relies on external tools for that.
Available merge tools
=====================
External merge tools and their properties are configured in the
merge-tools configuration section - see hgrc(5) - but they can often just
be named by their executable.
A merge tool is generally usable if its executable can be found on the
system and if it can handle the merge. The executable is found if it
is an absolute or relative executable path or the name of an
application in the executable search path. The tool is assumed to be
able to handle the merge if it can handle symlinks if the file is a
symlink, if it can handle binary files if the file is binary, and if a
GUI is available if the tool requires a GUI.
There are some internal merge tools which can be used. The internal
merge tools are:
.. internaltoolsmarker
Internal tools are always available and do not require a GUI but will by default
not handle symlinks or binary files.
Choosing a merge tool
=====================
Mercurial uses these rules when deciding which merge tool to use:
1. If a tool has been specified with the --tool option to merge or resolve, it
is used. If it is the name of a tool in the merge-tools configuration, its
configuration is used. Otherwise the specified tool must be executable by
the shell.
2. If the ``HGMERGE`` environment variable is present, its value is used and
must be executable by the shell.
3. If the filename of the file to be merged matches any of the patterns in the
merge-patterns configuration section, the first usable merge tool
corresponding to a matching pattern is used. Here, binary capabilities of the
merge tool are not considered.
4. If ui.merge is set it will be considered next. If the value is not the name
of a configured tool, the specified value is used and must be executable by
the shell. Otherwise the named tool is used if it is usable.
5. If any usable merge tools are present in the merge-tools configuration
section, the one with the highest priority is used.
6. If a program named ``hgmerge`` can be found on the system, it is used - but
it will by default not be used for symlinks and binary files.
7. If the file to be merged is not binary and is not a symlink, then
internal ``:merge`` is used.
8. Otherwise, ``:prompt`` is used.
.. note::
After selecting a merge program, Mercurial will by default attempt
to merge the files using a simple merge algorithm first. Only if it doesn't
succeed because of conflicting changes will Mercurial actually execute the
merge program. Whether to use the simple merge algorithm first can be
controlled by the premerge setting of the merge tool. Premerge is enabled by
default unless the file is binary or a symlink.
See the merge-tools and ui sections of hgrc(5) for details on the
configuration of merge tools.