There are three high-level cases that are of interest in
manifestmerge(): 1) The file exists on both sides, 2) The file exists
only on the local side, and 3) The file exists only on the remote
side. Let's make this clearer in the code.
The 'if f in copied' case will be broken up into the two applicable
branches in the next patch.
The "nothing to merge" case is covered by test-merge-default.t.
The "uncommitted changes" case is covered by test-merge1.t (and
others).
The "merge -f" case is covered by test-merge-force.t.
In overridecalculateupdates(), 'g' (get) actions may be converted into
other actions. In most of these cases, it does not make sense to keep
the action's message. For example, 'remote created' does not make
sense for an 'r' (remove) action.
The message in the action is used for debugging and should not be the
same as the question presented to the user. Use a different variable
for the user message, so the 'msg' variable already in scope does not
get overwritten.
Currently, the revlog index C implementation assumes its node tree will be
initialized before a new element is inserted by revnum. For example, revlog.py
executes 'self.index.insert(-1, e)' in _addrevision(). This is only safe
because the node tree has been initialized by a "node in self.nodemap"
check made in addrevision().
(For context, this was discovered while developing an experimental revlog
mixin which stores "elided nodes" via a separate code path from
_addrevision(); that new code path segfaults without this patch.)
Changset 281e85651e92 (merge: demonstrate that directory renames can
lose local file content, 2014-12-02) should clearly have added the
reverse version of the test: where the remote side renamed a
directory, added a new file in that directory, and the local directory
added a conflicting file in the source directory. Add such a test now,
and also touch up the ones already added slightly (e.g. 'local' was a
stupid value for content that can be on either side of a merge).
One of the graft tests grafts a changeset that changes a file's
content from 'a' to 'b' onto a branch that has changed the file's
content from 'a', via 'b', and then back to 'a' again. To prepare for
not considering this a file in need of merging, let's use 'c' as the
file's new content to make sure it has to be considered
conflicting.
There's a second similar case further down where an ancestor is
grafted. Make sure that is also considered a conflict.
The state mapping also contains some magic negative values (detached
parent, ignored revision). Blindly reading the state thus lead to
unfortunate usage of the negative value as an update destination. We
now filter them out.
We do a minor alteration of the test to catch this.
Before, merging would in some cases ask "wrong" questions about
"changed/deleted" conflicts ... and even do it before the resolve phase where
they can be postponed, re"resolved" or answered in bulk operations.
Instead, check that the content of the changed file really did change.
Reading and comparing file content is expensive and should be avoided before
the resolve phase. Prompting the user is however even more expensive. Checking
the content here is thus better.
The 'f in ancestors[0]' should not be necessary but is included to be extra
safe.
Use suffix -same for cases where file changed but content is the same - that is
the case where manifestmerge doesn't detect that a file is unchanged.
(The suffix -id is already used for cases where the file didn't change - that
is the trivial case where manifestmerge detects that the file is unchanged.)
These new tests are good but the results are bad. There shouldn't be any merge
conflicts or prompts when one side didn't change.
This allow to gracefully report the failure of the bookmark push and carry on.
Before this change set. Local push would plain quit and wireprotocol would
failed in various ungraceful way.
We need to gracefully handle some aborts for pushkey, especially
because it leads to a user-facing crash over the wireprotocols. So we
need a more specialized exception to catch.
Mq tried to insert headers in the right order. Sometimes it would stop
searching before checking all headers and it could thus duplicate a header
instead of replacing it.
This patch fixes a bug where hgweb would send an incomplete HTTP
response.
If an uncaught exception is raised when hgweb is processing a request,
hgweb attempts to send a generic error response and log that exception.
The server defaults to chunked transfer coding. If an uncaught exception
occurred, it was sending the error response string / chunk properly.
However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to
indicate end of the entity body. hgweb was failing to send this last
chunk. As a result, properly written HTTP clients would assume more data
was coming and they would likely time out waiting for another chunk to
arrive.
Mercurial's own test harness was paving over the improper HTTP behavior
by not attempting to read the response body if the status code was 500.
This incorrect workaround was added in faced8f5c2af and has been removed
with this patch.
The result of 'hg rm' + 'hg rename' disagreed with the one from
'hg rename --force'. We align them on 'hg move --force' because it agrees with
what 'hg status' says after the commit.
Stopping reporting a modified file as added puts an end to the hg revert confusion in this
situation (issue4458).
However, reporting the file as modified also prevents revert from restoring the copy
source. We fix this in a later changeset.
Git diff also stop reporting the add in the middle of the chain as add. Not
sure how important (and even wrong) it is.
Because the same dictionary was used to (1) get node from parent and (2) store
annotated version, we could end up with buggy values. For example with a chain
of renames:
$ hg mv b c
$ hg mv a b
The value from 'b' would be updated as "<old-a>a", then the value of c would be
updated as "<old-b>a'. With the current dictionary sharing this ends up with:
'<new-c>' == '<old-a>aa'
This value is double-wrong as we should use '<old-b>' and a single 'a'.
We now use a read-only value for lookup. The 'test-rename.t' test is impacted
because such a chained added file is suddenly detected as such.
Changeset 5b64e22ecd8e introduced the examination of exec bit of
largefiles in "hg status --rev REV" case, but it doesn't avoid it on
the platform being unaware of exec-bit (e.g. on NTFS of Windows).
Previously, if reorder was true during the creation of a changegroup bundle,
it was possible that the manifest and filelogs would be reordered such that the
resulting bundle filelog had a linkrev that pointed to a commit that was not
the earliest instance of the filelog revision. For example:
With commits:
0<-1<---3<-4
\ /
--2<---
if 2 and 3 added the same version of a file, if the manifests of 2 and 3 have
their order reversed, but the changelog did not, it could produce a filelog with
linkrevs 0<-3 instead of 0<-2, which meant if commit 3 was stripped, it would
delete that file data from the repository and commit 2 would be corrupt (as
would any future pulls that tried to build upon that version of the file).
The fix is to make the linkrev fixup smarter. Previously it considered the first
manifest that added a file to be the first commit that added that file, which is
not true. Now, for every file revision we add to the bundle we make sure we
attach it to the earliest applicable linkrev.
"/search", which is an invalid command in hgweb, was mistakenly used for
"[show] more [revsets]" and "[show] less [revsets]" links on search page in
templates "paper" (and those which inherit paper, such as coal) before and
worked fine until 73c8d0c02c22, which made hgweb more strict about invalid
commands.
The notify output doesn't seem to be parseable anyway, what with the maxdiff
config option. Plus it is designed mainly for servers where hopefully the
admins are doing sensible things.
The whitespace diffopts break lossless transmission, and the format-changing
ones make import harder. We expect parsers to be able to read git-style diffs,
though.
With generate-working-copy-states.py generalized to support
arbitrarily many changesets, we can use it for generating test cases
for merge: use one changeset each for base, remote and local. With the
various working copy states, this is a total of 104 cases.
The first candidate for additional testing is 'hg merge --force'. Even
though the force option is deprecated, it is convenient for testing
because it can be tested without first needing to revert any
changes. Except for the lack of checking for uncommitted changes, it
differs in only a few cases from unforced merge.
The new tests cover all the cases in the existing test-merge-force.t,
except for the unforced merge case, which is covered in several other
files anyway, so nothing remains of the file after this patch.
The order is determined by manifest.diff(), which currently is not
sorted. There are currently no tests for this, but we will soon add
some that would be flaky without this patch.
The phase-syncing code was using bundle2 if the remote supported it. It was
doing so without regard to bundle2 activation on the client. Moreover, the
phase push is now properly included in the unified bundle2 push, so having extra
code in syncphase should be useless. If the remote is bundle2-enabled, the
phases should already be synced.
The buggy verification code was leading to a crash when a 3.2 client was pushing
to a 3.1 server. The real bundle2 path detected that their versions were
incompatible, but the syncphase code failed to, sending an incompatible bundle2
to the server.
We drop the useless and buggy code as a result. The "else" clause is
de-indented in the process.
When looking for untracked files that would conflict with a tracked
file in the target revision (or the remote side of a merge), we
explcitly exclude ignored files. The code was added in f1db75422e70
(merge: refactor unknown file conflict checking, 2012-02-09), but it
seems like only unknown, not ignored, files were considered since the
beginning of time.
Although ignored files are mostly build outputs and backup files, we
should still not overwrite them. Fix by simply removing the explicit
check.
