##// END OF EJS Templates
mergetools: add new conflict marker format with diffs in...
mergetools: add new conflict marker format with diffs in I use 3-way conflict markers. Often when I resolve them, I manually compare one the base with one side and apply the differences to the other side. That can be hard when the conflict marker is large. This patch introduces a new type of conflict marker, which I'm hoping will make it easier to resolve conflicts. The new format uses `<<<<<<<` and `>>>>>>>` to open and close the markers, just like our existing 2-way and 3-way conflict markers. Instead of having 2 or 3 snapshots (left+right or left+base+right), it has a sequence of diffs. A diff looks like this: ``` ------- base +++++++ left a -b +c d ``` A diff that adds one side ("diff from nothing") has a `=======` header instead and does not have have `+` prefixed on its lines. A regular 3-way merge can be viewed as adding one side plus a diff between the base and the other side. It thus has two ways of being represented, depending on which side is being diffed: ``` <<<<<<< ======= left contents on left ------- base +++++++ right contents on -left +right >>>>>>> ``` or ``` <<<<<<< ------- base +++++++ left contents on -right +left ======= right contents on right >>>>>>> ``` I've made it so the new merge tool tries to pick a version that has the most common lines (no difference in the example above). I've called the new tool "mergediff" to stick to the convention of starting with "merge" if the tool tries a regular 3-way merge. The idea came from my pet VCS (placeholder name `jj`), which has support for octopus merges and other ways of ending up with merges of more than 3 versions. I wanted to be able to represent such conflicts in the working copy and therefore thought of this format (although I have not yet implemented it in my VCS). I then attended a meeting with Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for showing a similar format, which reminded me to actually attempt this in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D9551

File last commit:

r44031:2e017696 default
r46724:bdc2bf68 default
Show More
censor.txt
22 lines | 1.2 KiB | text/plain | TextLexer
The censor system allows retroactively removing content from
files. Actually censoring a node requires using the censor extension,
but the functionality for handling censored nodes is partially in core.
Censored nodes in a filelog have the flag ``REVIDX_ISCENSORED`` set,
and the contents of the censored node are replaced with a censor
tombstone. For historical reasons, the tombstone is packed in the
filelog metadata field ``censored``. This allows censored nodes to be
(mostly) safely transmitted through old formats like changegroup
versions 1 and 2. When using changegroup formats older than 3, the
receiver is required to re-add the ``REVIDX_ISCENSORED`` flag when
storing the revision. This depends on the ``censored`` metadata key
never being used for anything other than censoring revisions, which is
true as of January 2017. Note that the revlog flag is the
authoritative marker of a censored node: the tombstone should only be
consulted when looking for a reason a node was censored or when revlog
flags are unavailable as mentioned above.
The tombstone data is a free-form string. It's expected that users of
censor will want to record the reason for censoring a node in the
tombstone. Censored nodes must be able to fit in the size of the
content being censored.