FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Feb 2016 22:06:35 +0900] rev 27956
doc: prevent non-literal text block from being treated as literal one
This creates hg.1.html as expected.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Feb 2016 20:29:20 +0900] rev 27955
histedit: show correct hash ID at verification error
node.short() on 'ha' in verifyactions() causes broken hash ID, because
it is initialized with node.hex()-ed node value.
Yuya Nishihara <yuya@tcha.org> [Sat, 30 Jan 2016 18:00:11 +0900] rev 27954
backout: disable --merge with --no-commit (issue4874)
Because "backout --merge" have to make a commit before merging, it doesn't
work with --no-commit. We could change "backout --merge" to make a merge
commit automatically, and --no-commit to bypass a merge commit, but that
change would be undesirable because:
a) it's hard to fix bad merges in general
b) two commits would be created with the same --message
So, this patch simply disables "--merge --no-commit".
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Jan 2016 09:07:28 -0800] rev 27953
changegroup: fix pulling to treemanifest repo from flat repo (issue5066)
In c0f11347b107 (changegroup: don't support versions 01 and 02 with
treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2
with treemanifest repos. What I had not considered was that it's
perfectly safe to pull *to* a treemanifest repo using any changegroup
version. As reported in issue5066, I therefore broke pull from old
repos into a treemanifest repo. It was not covered by the test case,
because that pulled from a local repo while enabling treemanifests,
which enabled treemanifests on the source repo as well. After
switching to pulling via HTTP, it breaks.
Fix by splitting up changegroup.supportedversions() into
supportedincomingversions() and supportedoutgoingversions().
Martin von Zweigbergk <martinvonz@google.com> [Thu, 28 Jan 2016 13:49:05 -0800] rev 27952
tests: minor cleanup to treemanifest test
Siddharth Agarwal <sid0@fb.com> [Fri, 29 Jan 2016 14:19:29 -0800] rev 27951
merge: don't try to merge subrepos twice (issue4988)
In my patch series ending with rev 25e4b2f000c5 I switched most change/delete
conflicts to be handled at the resolve layer. .hgsubstate was the one file that
we weren't able to handle, so we kept the old code path around for it.
The old code path added .hgsubstate to one of the other lists as the user
specifies, including possibly the 'g' list.
Now since we did this check after converting the actions from being keyed by
file to being keyed by action type, there was nothing that actually removed
.hgsubstate from the 'cd' or 'dc' lists. This meant that the file would
eventually make its way into the 'mergeactions' list, now freshly augmented
with 'cd' and 'dc' actions.
We call subrepo.submerge for both 'g' actions and merge actions.
This means that if the resolution to an .hgsubstate change/delete conflict was
to add it to the 'g' list, subrepo.submerge would be called twice. It turns out
that this doesn't cause any adverse effects on Linux due to caching, but
apparently breaks on other operating systems including Windows.
The fix here moves this to before we convert the actions over. This ensures
that it .hgsubstate doesn't make its way into multiple lists.
The real fix here is going to be:
(1) move .hgsubstate conflict resolution into the resolve layer, and
(2) use a real data structure for the actions rather than shuffling data around
between lists and dictionaries: we need a hash (or prefix-based) index by
file and a list index by action type.
There's a very tiny behavior change here: collision detection on
case-insensitive systems will happen after this is resolved, not before. I think
this is the right change -- .hgsubstate could theoretically collide with other
files -- but in any case it makes no practical difference.
Thanks to Yuya Nishihara for investigating this.