Transplant filtering used a tmp file ending with the (stripped) commit
message and thus no final LF. Text files not ending with LF is usually
not used on Unix and is thus wrong ;-)
The missing LF had bad consequences because Solaris sed chokes on
unterminated input lines, so
echo -n foo|sed 's,o,0,g'
doesn't output anything, and the filter used in tests/test-transplant
thus stripped the last (and only) line in the message away on solaris.
When using hg.tagsbranch, all conversions fail at
transcribing the source repo topology with conversion
scenarios interleaving:
- initial repo conversion,
- then upstream tag
- then later incremental conversion
The problem is caused by the usage of the last source
revid as source revid for the tagnode in the revision
map.
On a later incremental conversion, when resolving some
child commit of the true last source revid, convert
will parent the nodes to the tag node. If using
tagsbranch you get a bad topology where all incremental
commit nodes end up in the tag branch.
Analysis and test by Edouard Gomez <ed.gomez@free.fr>
We are not currently using that API function in inotify, hence the reason
for the "silent" bug. But returning NULL here causes the interpreter to crash.
Let's keep code clean for reusers :)
The whole "bail" logic was unneeded here.
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 patch treats all files inside repository as encoded by
locale's encoding when pygmentize.
We can assume that most files are written in locale's encoding,
but current implementation treats them as UTF-8.
So there's no way to specify the encoding of files.
Current implementation, e2f3244d5179 (issue1341):
1. Convert original `text`, which is treated as UTF-8, to locale's encoding.
`encoding.tolocal()` is the method to convert from internal UTF-8 to local.
If original `text` is not UTF-8, e.g. Japanese EUC-JP, some characters
become garbled here.
2. pygmentize, with no UnicodeDecodeError.
This patch:
1. Convert original `text`, which is treated as locale's encoding, to unicode.
Pygments prefers unicode object than raw str. [1]_
If original `text` is not encoded by locale's encoding, some characters
become garbled here.
2. pygmentize, also with no UnicodeDecodeError :)
3. Convert unicode back to raw str, which is encoded by locale's.
.. [1] http://pygments.org/docs/unicode/
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).
Bottom portion fixes full path imports on source installs on Windows.
The top portion further fixes full path imports on binary installs.
Initial patch by Roman V. Kiseliov
I wanted to check if mercurial.demandimport could speed up the loading of
PyObjC, and ran into this: the level argument for __import__, available in
Python 2.5 and later, is silently dropped when doing an 'import *'. I have no
idea what these arguments mean, but this minor change made it work.
(Oh, and because of that 'from ... import *', PyObjC still took about 2s...)
patch.extract extracts just the message below HG changeset patch. So to not
parse comments above the patch, we reset the message if we find a changeset
patch as we know the commit message comes after the changeset patch data.
This is similar to the behavior of patch.extract.
The drawback of this approach, after a qref -e the comment above HG changeset
patch is gone. Without this patch the message would become part of the commit
message in the HG changset patch part.
