Since a map file has another level to select a template (spec -> mapfile
-> topic), this isn't exactly the same as how a map file works. But I believe
most users would expect the new behavior.
A literal template is stored as an unnamed template so that it will never
conflict with the templates defined in [templates] section.
This provides a simpler API for callers which don't need full templating
stack. Instead of storing the given template as the name specified by topic,
use '' as the default template to be rendered.
This will allow us to change the initial template reference depending on how
the template is looked up. For example,
-Tdefault => (ref='changeset', tmpl=None, mapfile='map-cmdline.default')
-T'{rev}' => (ref='', tmpl='{rev}', mapfile=None)
A literal template given by -T option will be stored as an unnamed template,
which will free up the template namespace so that we can load named templates
from [templates] section of user config.
I'm going to add more options to the templatespec tuple.
cmdutil.logtemplatespec() is just an alias now, but it will be changed to
a factory function later.
changeset_templater has lots of arguments, but most callers only need to
specify a literal template 'tmpl'.
"hg debugtemplate" has no diff option, which means 'opts' were effectively {},
so dropped opts.
ui.graphnodetemplate config should be a literal template as ui.logtemplate is.
The use of formatter.gettemplater() is valid only for a template string
given by -T/--template option.
It seemed silly to convert ctx.hex() back to binary to use node.hex/short(),
or to use [:12] instead of node.short() because ctx.node() could be None.
Eventually I want to change wctx.rev() and wctx.node() to return wdirrev and
wdirid respectively, but that's quite big API breakage and can't be achieved
without some compatibility wrappers.
This makes it slightly easier to sort basectx objects by key=scmutil.intrev.
We're most likely to have ctx objects where changectx/workingctx abstraction
is necessary, so this won't increase the abstraction overhead.
Prepares for porting to the formatter API. We won't be able to utilize the
abstraction provided by makefilename() because formatter must be instantiated
per file.
This simplifies things a little by making the actual act of turning a
revision into patch data a single function. After this, adding
formatter support to `hg export` should be much simpler.
The goal is to get rid of the debugcommands -> commands dependency.
Since globalopts is the property of the commands, it's kept in the commands
module.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
By recording what operation created the obsmarker, we can show very intuitive
messages to the user in various UIs. For instance, log output could have
messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.
@ ac28e3 durham
/ First commit
|
| o d4afe7 durham
| | Second commit
| |
| x 8e9a5d (Amended as ac28e3) durham
|/ First commit
|
opts in add command were passed again to cmdutil.add() as kwargs so we need
to convert them again to str. Intstead we convert them to bytes when passing
scmutil.match(). Opts handling is also corrected for all the functions which
are called from cmdutil.add().
commands.commit() calls cmdutil.dorecord() where opts are passed as unicodes
being keyword arguments. This patch converts them back to bytes as they are
required.
I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths]
configuration for awhile without issue. Let's ditch the need for the manual
configuration in this case, and limit the repos served to the actual subrepos.
This doesn't attempt to handle the case where a new subrepo appears while the
server is running. That could probably be handled with a hook if somebody wants
it. But it's such a rare case, it probably doesn't matter for the temporary
serves.
The main repo is served at '/', just like a repository without subrepos. I'm
not sure why the duplicate 'adding ...' lines appear on Linux. They don't
appear on Windows (see 3f4ff1bdf101), so they are optional.
Subrepositories that are configured with '../path' or absolute paths are not
cloneable from the server. (They aren't cloneable locally either, unless they
also exist at their configured source, perhaps via the share extension.) They
are still served, so that they can be browsed, or cloned individually. If we
care about that cloning someday, we can probably just add the extra entries to
the webconf dictionary. Even if the entries use '../' to escape the root, only
the related subrepositories would end up in the dictionary.
This was originally written for JSON templating where we would have to be
careful to not add extra comma, but seems generally useful.
Inner loop started by % operator has its own counter.
Until now there were no label to highlight obsolete changesets in log output,
only evolution troubles (unstable, bumped, divergent) are supported. We add a
"changeset.obsolete" label on changeset entries produced by changeset_printer
so that obsolete changesets can be highlighted in log output. This is useful
because, unless using a graph log where obsolete changesets have a 'x' marker,
there's no way to identify obsolete changesets. And even in graph mode, when
working directory's parent is obsolete, we get a '@' marker and we do not see
it as obsolete.
