Mercurial > hg
view tests/test-convert-bzr-merges.t @ 23167:a3c2d9211294 stable
templater: don't overwrite the keyword mapping in runsymbol() (issue4362)
This keyword remapping was introduced in e06e9fd2d99f as part of converting
generator based iterators into list based iterators, mentioning "undesired
behavior in template" when a generator is exhausted, but doesn't say what and
introduces no tests.
The problem with the remapping was that it corrupted the output for keywords
like 'extras', 'file_copies' and 'file_copies_switch' in templates such as:
$ hg log -r 142b5d5ec9cc --template "{file_copies % ' File: {file_copy}\n'}"
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
File: mercurial/changelog.py (mercurial/hg.py)
What was happening was that in the first call to runtemplate() inside runmap(),
'lm' mapped the keyword (e.g. file_copies) to the appropriate showxxx() method.
On each subsequent call to runtemplate() in that loop however, the keyword was
mapped to a list of the first item's pieces, e.g.:
'file_copy': ['mercurial/changelog.py', ' (', 'mercurial/hg.py', ')']
Therefore, the dict for the second and any subsequent items were not processed
through the corresponding showxxx() method, and the first item's data was
reused.
The 'extras' keyword regressed in de7e6c489412, and 'file_copies' regressed in
0b241d7a8c62 for other reasons. The common thread of things fixed by this seems
to be when a list of dicts are passed to the templatekw._hybrid class.
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Mon, 03 Nov 2014 12:08:03 -0500 |
parents | f2719b387380 |
children | 89872688893f |
line wrap: on
line source
N.B. bzr 1.13 has a bug that breaks this test. If you see this test fail, check your bzr version. Upgrading to bzr 1.13.1 should fix it. $ . "$TESTDIR/bzr-definitions" test multiple merges at once $ mkdir test-multimerge $ cd test-multimerge $ bzr init -q source $ cd source $ echo content > file $ bzr add -q file $ bzr commit -q -m 'Initial add' $ cd .. $ bzr branch -q source source-branch1 $ cd source-branch1 $ echo morecontent >> file $ echo evenmorecontent > file-branch1 $ bzr add -q file-branch1 $ bzr commit -q -m 'Added branch1 file' $ cd ../source $ sleep 1 $ echo content > file-parent $ bzr add -q file-parent $ bzr commit -q -m 'Added parent file' $ cd .. $ bzr branch -q source source-branch2 $ cd source-branch2 $ echo somecontent > file-branch2 $ bzr add -q file-branch2 $ bzr commit -q -m 'Added brach2 file' $ sleep 1 $ cd ../source $ bzr merge -q ../source-branch1 $ bzr merge -q --force ../source-branch2 $ bzr commit -q -m 'Merged branches' $ cd .. $ hg convert --datesort source source-hg initializing destination source-hg repository scanning source... sorting... converting... 4 Initial add 3 Added branch1 file 2 Added parent file 1 Added brach2 file 0 Merged branches $ glog -R source-hg o 5@source "(octopus merge fixup)" files: |\ | o 4@source "Merged branches" files: file-branch2 | |\ o---+ 3@source-branch2 "Added brach2 file" files: file-branch2 / / | o 2@source "Added parent file" files: file-parent | | o | 1@source-branch1 "Added branch1 file" files: file file-branch1 |/ o 0@source "Initial add" files: file $ manifest source-hg tip % manifest of tip 644 file 644 file-branch1 644 file-branch2 644 file-parent $ cd ..