templater: pass (context, mapping) down to unwraphybrid()
See the subsequent patches for why.
I initially thought it would be wrong to pass a mapping to flatten() and
stringify() since these functions may be applied to a tree of generators,
where each node should be bound to the mapping when it was evaluated. But,
actually that isn't a problem. If an intermediate node has to override a
mapping dict, it can do on unwraphybrid() and yield "unwrapped" generator
of byte strings:
"{f(g(v))}" # literal template example.
^^^^ # g() want to override a mapping, so it returns a wrapped
# object 'G{V}' with partial mapping 'lm' attached.
^^^^^^^ # f() stringifies 'G{V}', starting from a mapping 'm'.
# when unwrapping 'G{}', it updates 'm' with 'lm', and
# passes it to 'V'.
This structure is important for the formatter (and the hgweb) to build a
static template keyword, which can't access a mapping dict until evaluation
phase.
Make a narrow clone then archive it
$ . "$TESTDIR/narrow-library.sh"
$ hg init master
$ cd master
$ for x in `$TESTDIR/seq.py 3`; do
> echo $x > "f$x"
> hg add "f$x"
> hg commit -m "Add $x"
> done
$ hg serve -a localhost -p $HGPORT1 -d --pid-file=hg.pid
$ cat hg.pid >> "$DAEMON_PIDS"
$ cd ..
$ hg clone --narrow --include f1 --include f2 http://localhost:$HGPORT1/ narrowclone1
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 2 changes to 2 files
new changesets * (glob)
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
The tar should only contain f1 and f2
$ cd narrowclone1
$ hg archive -t tgz repo.tgz
$ tar tfz repo.tgz
repo/f1
repo/f2