For divergent renames the following message is printed during merge:
note: possible conflict - file was renamed multiple times to:
newfile
file2
When a file is renamed in one branch and deleted in the other, the file still
exists after a merge. With this change a similar message is printed for mv+rm:
note: possible conflict - file was deleted and renamed to:
newfile
This is achieved by acting as if the user had given -r<rev> for each head rev
of outgoing changesets on the command line, as well as appropriate
--base <rev>.
The discovery information is computed as normal, and then adjusted as above.
Previously, we were finding the most recent version of a file in a
changeset and comparing it against its first file parent. This was
wrong on three counts:
- it would show a diff in revisions where there was no change to a file
- it would show a diff when only the exec bit changed
- it would potentially compare against a much older changeset, which
could be very expensive if git-style rename detection was enabled
This compares the file in the current context with that context's
parent, which may result in an empty diff when looking at a file not
touched by the current changeset.
Previously, graph data has been encoded for processing done by
JavaScript code run in the browser, employing simple structures
with implicit member positions. This patch modifies the graph
command to also produce data employing a dictionary-based
structure suitable for use with the templating mechanism, thus
permitting other ways of presenting repository graphs using that
mechanism.
In order to test these changes, the raw theme has been modified
to include templates for graph nodes and edges. In a similar
fashion, themes could employ technologies such as SVG that lend
themselves to templating to produce the graph display. This patch
makes use of a much simpler output representation than SVG in
order to maintain clarity.
Extension authors should explicitly declare their supported hg
versions and include a buglink attribute in their extension. In the
event that a traceback occurs, we'll identify the
least-recently-tested extensionas the most likely source of the defect
and suggest the user disable that extension.
Packagers should make every effort to ship hg versions from exact
tags, or with as few modifications as possible so that the versioning
can work appropriately.
I named it --check because it felt like qpush & co were checking *more*
things to ensure local changes could not be lost. But it has been
pointed on the mailing list that --check is already used by update
command with a meaning almost opposite to this one. An alternative
was --keep but qfold and qdelete already have such an option to preserve
patch files and qfold may be a candidate for --check.
- qpush/qpop/qgoto --check becomes --keep-changes.
- mq.check becomes mq.keepchanges.
- The short option -c is dropped as -k may conflict with existing
--keep. The availabilitity of mq.keepchanges should not make this too
painful.
- Fix minor reST mistake in option description.
Add a -B option to remove a bookmark. All revisions are unreachable
from a different head or a different bookmark will be removed too.
This helps with topic branch workflow. You can create a topic branch
and remove it if not needed anymore with hg strip -B topic/xyz.
Destroying history via strip used to invalidate the branchheads cache,
causing it to be regenerated the next time it is read. This is
expensive in large repos. This change converts strip to pass info to
localrepo.destroyed() to enable to it to incrementally update the
cache, improving the performance of strip and other operations that
depend on it (e.g., rebase).
This change also strengthens a bit the integrity checking of the
branchheads cache when it is read, by rejecting the cache if it has
nodes in it that no longer exist.
Bookmarks will behave more like named branches when merge tries to pick
a revision to merge.
Bookmarks now to respect the current bookmarks. Bookmarks will not
accidentally merged with unnamed heads or other bookmarks. However merge
can pick heads with diverging bookmarks and pick those automatically.
We end up with two cases for picking a revision to merge:
(1) In case of an current bookmark, merge can pick a branch head that has a
diverged bookmark
(2) In case of no current bookmark, merge can pick a branch head that does not
have a bookmark.
We allow rebase plus collapse, but not collapse only? I imagine people would
rebase first then collapse once they are sure the rebase is correct and it is
the right time to finish it.
I was reluctant to submit this patch for reasons detailed below, but it
improves rebase --collapse usefulness so much it is worth the ugliness.
The fix is ugly because we should be fixing the collapse code path rather than
the merge. Collapsing by merging changesets repeatedly is inefficient compared
to what commit --amend does: commitctx(), update, strip. The problem with the
latter is, to generate the synthetic changeset, copy records are gathered with
copies.pathcopies(). copies.pathcopies() is still implemented with merging in
mind and discards information like file replaced by the copy of another,
criss-cross copies and so forth. I believe this information should not be lost,
even if we decide not to interpret it fully later, at merge time.
The second issue with improving rebase --collapse is the option should not be
there to begin with. Rebasing and collapsing are orthogonal and a dedicated
command would probably enable a better, simpler ui. We should avoid advertizing
rebase --collapse, but with this fix it becomes the best shipped solution to
collapse changesets.
And for the record, available techniques are:
- revert + commit + strip: lose copies
- mq/qfold: repeated patching() (mostly correct, fragile)
- rebase: repeated merges (mostly correct, fragile)
- collapse: revert + tag rewriting wizardry, lose copies
- histedit: repeated patching() (mostly correct, fragile)
- amend: copies.pathcopies() + commitctx() + update + strip
Since f7e538c3b7ba, if a chunk starts with "@@ -0,1", oldstart turns into
a negative value. Because diffhelpers.testhunk() doesn't expect negative bstart,
it bypasses "alen > blen - bstart" condition and segfaults at
"PyList_GET_ITEM(b, i + bstart)".
When:
[mq]
check = True
is set, qpush, qpop and qgoto behave as if -c/--check were passed. If
incompatible options like -f/--force or --exact are set, this setting is
ignored.
This setting enables what many users expect mq default behaviour to be.
qpush help says the following about --force:
1- When -f/--force is applied, all local changes in patched files will
be lost.
2- Apply on top of local changes
In practice, qpush --force will attempt to apply the patch on top of
local changes, and on success will merge them in the pushed patch. On
failure, patched files will contain a mix of local changes (where the
patch could not apply) and a mix of patch changes (were it applied). So,
local changes are less lost than entangled with a mass of other changes.
This patch makes qpush --force backup all locally modified files touched
by the next patch being applied. When multiple patches are being pushed,
this logic is repeated for each patch. Note that modified but
successfully patched files are preserved as well.
Commands working without a repository, like "init", are listed in
commands.norepo. Commands optionally using a repository, like "showconfig", are
listed in commands.optionalrepo. Command aliases were inheriting the former but
not the latter.
brendan mentioned on IRC that b64decode raises a TypeError too, but while the
previous exception type may be better in general, it is much easier to make it
behave like the related C code and changes nothing for mercurial itself.
Calling strip() will eventually trigger localrepo.destroyed() which will
invalidate _parseroots. It will call filterunknown() upon reload.
Changes to test-keyword.t are related to commit --debug running after
either qpop or rollback.
The behaviour is correct but for bad reasons: the repo.set() call in
phase command fails for '-1'. It should be rejected explicitely by phase
boundary commands, sadly this is hard to do because phase changes are
not applied atomically.
largefiles status implementation attemps to rewrite the input match objects to
match the "standins" as well as the regular files. When fixing the directories
listed in match.files(), if there was related standin entry, it was kept and
the original path discarded. But directories can appear both as regular and
standin entries.
Note that aborting in subrepo.state() prevents "repairing" commands like revert
to be issued. The user will have to edit the .hgsubstate manually (but he
probably had already otherwise this would not be failing). The same behaviour
already happens with invalid .hgsub entries.
Let R be a repo served by an hg daemon on a machine with an empty largefiles
cache. Pushing a largefiles repo to R will result in a no-such-file-or-directory
OSError because putlfile will attempt to create a temporary file in
R/.hg/largefiles, which does not yet exist.
This patch also adds a regression test for this scenario.
This is essentially a copy of largefile's override of archive() in the
archival class, adapted for overriding hgsubrepo's archive(). That
means decoding isn't taken into consideration, nor is .hg_archival.txt
generated (the same goes for regular subrepos). Unlike subrepos, but
consistent with largefile's handling of the top repo, ui.progress() is
*not* called. This should probably be refactored at some point, but
at least this generates the archives properly for now. Previously,
the standins were ignored and the largefiles were archived only for
the top level repo.
Long term, it would probably be most desirable to figure out how to
tweak archival's archive() if necessary such that largefiles doesn't
need to override it completely just to special case the translating of
standins to the real files. Largefiles will already return a context
with the true largefiles instead of the standins if lfilesrepo's
lfstatus is True- perhaps this can be leveraged?
The initial version was to take the "Revision" field from svn info. It works
but produces false positive when parent paths are being moved or unrelated
changes are being committed, causing it to change while the svn checkout itself
remains the same. To avoid spurious commit, we took "Revision" and "Last
Changed Rev" for general comparison and kept the latter to answer "what is your
revision?" question. This is better but fails when the subrepo path exists at
"Revision" but not at "Last Changed Rev". This patch adds a check for this, and
returns "Revision" if the path does not exist. We try to avoid doing this as
much as possible at it implies an extra, *remote* call.
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 weirdness is --amend let you replace one file with another with same data
and flags if the new file copy record differ from the one in the parent
revision. In theory, there is no problem with this kind of thing, subversion
supports it, but here we see log and status disagree. The reason is log reads
the copy record from the filelog, while status calls copies.pathcopies() which
eventually invokes some expensiveness argument to discard this case (copies.py,
_forwardcopies(), line 132). Since the next patch will side with pathcopies(),
I prefer to call this behaviour a bug.
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.
Here is a script illustrating the previous behaviour:
The merge brings a new file 'b' from remote
$ hg merge 1 --debug
searching for copies back to rev 1
unmatched files in other:
b
resolving manifests
overwrite: False, partial: False
ancestor: 07f494440405, local: 540395c44225+, remote: 102a90ea7b4a
b: remote created -> g
updating: b 1/1 files (100.00%)
getting b
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Delete but do not remove b
$ rm b
$ hg st
! b
The commit succeeds
$ hg commit -m merge
$ hg parents --template "{rev} {desc|firstline} files: {files}\n"
3 merge files:
$ hg st
! b
b changes were ignored, but even b existence was ignored
$ hg manifest
a
This happens because localrepo.commitctx() checks the input ctx.files(), which
is empty for workingctx.files() only returns added, modified or removed
entries, and bypass files/manifest updates completely. So the committed
revision manifest is the same as its first parent one, not containing the 'b'
file.
This patch forces the commit to abort in presence of a merge and missing files.
test-merge4.t is modified accordingly as it was introduced to check hg was not
just terminating with a traceback (5cc0d3ba11f9).
