This allows extensions that modify changeset metadata (e.g.
description) by overriding methods of changectx to get consistent
behavior from all log-like commands, regardless of whether templates
or styles are used. Without this, overriding changectx methods works
if you use styles or templates, but not with default log format.
This meant adding filectx.extra() for consistency with changectx.
The help topics are reused in the HTML documentation, and there it
looks odd that whole sections are indented. We now only indent it for
output on the terminal.
This can be used for referring to revisions in a reasonable
meaningful, stable and monotonically increasing way, suitable for
releases or builds directly from a repository.
The latest tag is found by searching through untagged ancestors and
finding the latest tagged ancestor based on tag date. The distance is
found from the length of the longest path to the tagged revision.
For example:
hg log -l1 --template '{latesttag}+{latesttagdistance}\n'
can return
1.3.1+197
This is mostly work by Gilles Moris <gilles.moris@free.fr>
Patch from Jason Orendorff
The lower the threshold, the stronger the popularity hack's
influence. So at 3999 lines, the hack is disabled; and at 4000 lines,
the hack is enabled at maximum strength (t=4).
No source file in mercurial/crew is over 4000 lines. But there are, oh,
a few such files in Mozilla. I can testify that this hack causes hg to
generate some correct but eyebrow-raising patches.
I think the hack should phase in gradually. The threshold should be high
for small files where we don't need it so much. Like this:
t = (bn < 31000) ? 1000000 / bn : bn / 1000;
That would leave the popularity hack disabled for small files, then
gradually phase it in:
bn < 1000 -- t > bn (popularity hack is completely disabled)
bn == 1000 -- t = 1000 (still effectively disabled)
bn == 2000 -- t = 500 (only hits unusual files)
bn == 10000 -- t = 100 (only hits especially common lines)
bn == 31000 -- t = 31 (hack is at maximum power)
bn == 32000 -- t = 32 (hack could backfire, ease off)
subprocess allows the environment and working directory to be specified
directly, so the hacks for making temporary changes while forking is no longer
necessary.
This also fixes failures on solaris where the temporary changes can't be undone
because there is no unsetenv.
Demandimport breaks gtk. You get a meaningless error about
'failed loading gobject\_gobject.pyd'. Mercurial does not use gtk,
but this trips up many extension writers.
Combining translated string fragments into bigger strings is bad
practice because it removes context from the fragments. The translator
sees the fragments in isolation and might not jump back to the source
to see how a string like "%d files %s" is actually used.
Previously, as soon as a continuation would be met, "cont" would stay
forever set to True, but "item" was set back to "None".
This caused the continuation code bits to run every time, until the next
"self.get(section, item) + '\n'" which would crash.
If a buffer of an mutable object is passed to revlog.addrevision(), the revlog
will happily store it in its cache. Later when the revlog reuses the cached
entry, if the manifest modified the object in-between, all kind of bugs
appears.
We fix it by:
- passing immutable objects to addrevision() if they are already available
- only storing the text in the cache if it's of str type
Then we can remove the conversion of the cache entry to str() during
retrieval. That was probably just there hiding the bug for the common cases
but not really fixing it.
No need to copy the dict, dict.__init__() will do that for us.
It was responsible for a non-negligeable waste of time during a qpush of an
-mm queue on the kernel repo.
When flags was DECREF'ed, scope was referencing to the outer variable,
outside of the block.
It was in fact always NULL: the real Python object was never decref'ed.
This change narrows the race guard that was introduced by ffd022830d6d
("dirstate: ignore stat data for files that were updated too recently")
to not discard the _map entry's stat data if the mtime is in the future.
Without this change, status locks files having odd mtimes in the future
into the 'unset' state, causing needless file compares later (admittedly
harmless), but also inflicting highly irritating sticky effects on
tools/plugins that directly read .hg/dirstate (e.g. TortoiseHg).
