Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Jan 2015 20:44:11 -0500] rev 23976
largefiles: don't interfere with logging normal files
The previous code was adding standin files to the matcher's file list when
neither the standin file nor the original existed in the context. Somehow, this
was confusing the logging code into behaving differently from when the extension
wasn't loaded.
It seems that this was an attempt to support naming a directory that only
contains largefiles, as a test fails if the else clause is dropped entirely.
Therefore, only append the "standin" if it is a directory. This was found by
running the test suite with --config extensions.largefiles=.
The first added test used to log an additional cset that wasn't logged normally.
The only relation it had to file 'a' is that 'a' was the source of a move, but
it isn't clear why having '.hglf/a' in the list causes this change:
@@ -47,6 +47,11 @@
Make sure largefiles doesn't interfere with logging a regular file
$ hg log a --config extensions.largefiles=
+ changeset: 3:2ca5ba701980
+ user: test
+ date: Thu Jan 01 00:00:04 1970 +0000
+ summary: d
+
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
The second added test used to complain about a file not being in the parent
revision:
@@ -1638,10 +1643,8 @@
Ensure that largefiles doesn't intefere with following a normal file
$ hg --config extensions.largefiles= log -f d -T '{desc}' -G
- @ c
- |
- o a
-
+ abort: cannot follow file not in parent revision: ".hglf/d"
+ [255]
$ hg log -f d/a -T '{desc}' -G
@ c
|
Note that there is still something fishy with the largefiles code, because when
using a glob pattern like this:
$ hg log 'glob:sub/*'
the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this
(this test lives in test-largefiles.t at 1349), it was just something that I
noticed when the code was loaded up with print statements.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:11:02 +0000] rev 23975
discovery: properly exclude locally known but filtered heads
The conditional was a bit too narrow and produced buggy result when a node was
present in both common and heads (because it pleased the discovery) and it was
locally known but filtered.
This resulted in buggy getbundle request and server side crash.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:40:30 +0000] rev 23974
test: make test-extdiff resilient to /usr/bin/echo
My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 18:49:33 +0000] rev 23973
obsstore: make the invalid markers check wrap-able
Some evolve user ignored the invalid markers for about two years and still have
some of them in some repository. This lead to plain abort whenever mercurial try
to open such repo. We need reinstall some way to clean this up in the evolve
extension. For this purpose, we need the checker code wrap-able independently.
This is scheduled for stable as this issue is blocking some evolve user.
Mads Kiilerich <madski@unity3d.com> [Fri, 30 Jan 2015 18:51:20 +0100] rev 23972
convert: replace revision references in messages if they are >= short hashes
Convert will try to find references to revisions in commit messages and replace
them with references to the converted revision. It will take any string that
looks like a hash (and thus also decimal numbers) and look it up in the source
repo. If it finds anything, it will use that in the commit message instead.
It would do that for all hex digit sequences of 6 to 40 characters. That was
usually no problem for small repos where it was unlikely that there would be a
matching 6 'digit' hash prefix. It was also no problem on repos with less than
100000 changesets where numbers with 6 or more digits not would match any
revision number. With more than 100000 revisions random numbers in commit
messages would be replaced with a "random" hash. For example, 'handle 100000
requests' would be changed to to 'handle 9117c6 requests'. Convert could thus
not really be used on real repositories with more than 100000 changesets.
The default hash length shown by Mercurial is 12 'digits'. It is unexpected and
unwanted that convert by default tries to replace revision references that use
less than that amount of 'digits'.
To fix this, don't match strings that are less than the default hash size of 12
characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 30 Jan 2015 04:59:05 +0900] rev 23971
merge: mark .hgsubstate as possibly dirty before submerge for consistency
Before this patch, failure of updating subrepos may cause inconsistent
".hgsubstate". For example:
1. dirstate entry for ".hgsubstate" of the parent repo is filled
with valid size/date (via "hg state" or so)
2. "hg update" is invoked at the parent repo
3. ".hgsubstate" of the parent repo is updated on the filesystem as
a part of "g"(et) action in "merge.applyupdates"
4. it is assumed that size/date of ".hgsubstate" on the filesystem
aren't changed from ones at (1)
this is not so difficult condition, because just changing hash
ids (every ids are same in length) in ".hgsubstate" doesn't
change the file size of it
5. "subrepo.submerge()" is invoked to update subrepos
6. failure of updating in one of subrepos raises exception
(e.g. "untracked file differs")
7. "hg update" is aborted without updating dirstate of the parent repo
dirstate entry for ".hgsubstate" still holds size/date at (1)
Then, ".hgsubstate" of the parent repo is treated as "CLEAN"
unexpectedly, because updating ".hgsubstate" at (3) doesn't change
size/date of it on the filesystem: see assumption at (4).
This inconsistent ".hgsubstate" status causes unexpected behavior, for
example:
- "hg revert" forgets to revert ".hgsubstate"
- "hg update" misunderstands that (not yet updated) subrepos diverge
(then, it shows the prompt to confirm user's decision)
To avoid inconsistent ".hgsubstate" status above, this patch marks
".hgsubstate" as possibly dirty before "submerge" invocation.
"normallookup"-ed (= dirty) dirstate should be written out, even if
processing is aborted by failure.
This patch marks ".hgsubstate" as possibly dirty before "submerge",
also when it is removed or merged while merging, for safety. This
should prevent Mercurial from misunderstanding inconsistent
".hgsubstate" as clean.
To satisfy conditions at (1) and (4) above, this patch uses "hg status
--config debug.dirstate.delaywrite=2" (to fill valid size/date into
dirstate) and "touch" (to fix date of the file).
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 Jan 2015 12:33:56 +0000] rev 23970
rebase: ensure rebase revision remains visible (issue4504)
Before this changeset rebase was getting very confused if any revision in the
rebase set became hidden. This was fairly easy to achieve if a rebased revision
was made visible by the working copy location. The rebase process would update
somewhere else and the revision would become hidden.
To work around this issue, we ensure rebased revisions remain visible for the
whole process.
This is a simple change suitable for stable. More subtle usage of unfiltered
repository in rebase may solve this issue more cleanly.
Mads Kiilerich <madski@unity3d.com> [Wed, 28 Jan 2015 02:28:39 +0100] rev 23969
extdiff: reintroduce backward compatibility with manual quoting of parameters
72a89cf86fcd broke things ... and the following cleanups didn't fix all issues.
It didn't work with the diffargs shipped in mergetools.rc with explicit
quoting. Parameters would end up with being quoted twice - especially if they
really needed quoting.
To work around that, look for explicit quotes around the variables that will be
substituted with proper quoting. Also accept an additional prefix so we can
handle both
--foo='$parent'
and
'--foo=$parent'
It will however still fail if the user intentionally place the variable inside
a quoted string, as in
'parent $parent is on the left'
There is currently no good way to handle that, short of knowing exactly which
quoting mechanism will be used.
Mads Kiilerich <madski@unity3d.com> [Wed, 28 Jan 2015 02:28:38 +0100] rev 23968
mergetools: drop incorrect quoting of diffargs variables
72a89cf86fcd introduced automatic quoting of diffargs in a not entirely
backwards compatible way. That rendered some of the configuration in
mergetools.rc invalid. It would fail when running extdiff on a single file with
a name that needed quoting.
Before:
$ hg config merge-tools.meld.diffargs
-a --label='$plabel1' $parent --label='$clabel' $child
$ hg --config extdiff.meld= -v --debug meld
running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ...
meld: error: too many arguments (wanted 0-3, got 4)
After:
$ hg config merge-tools.meld.diffargs
-a --label=$plabel1 $parent --label=$clabel $child
$ hg --config extdiff.meld= -v --debug meld
running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ...
(success)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 28 Jan 2015 22:22:59 +0900] rev 23967
namespace: introduce logfmt to show l10n-ed messages for hg log correctly
Before this patch, "_()" is used incorrectly for "tag:" and
"bookmark:" fields. "changeset_printer()" looks up keys composed at
runtime, and it prevents "xgettext" command from getting strings to be
translated from source files.
Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
and "bookmark:".
This patch introduces "logfmt" information into "namespace" to show
l10n-ed messages "hg log" (or "changeset_printer()") correctly.
For similarity to other namespaces, this patch specifies "logfmt" for
"branches" namespace, even though it isn't needed (branch information
is handled in "changeset_printer()" specially).
To find related code paths out easily, this patch adds "i18n: column
positioning ..." comment to the line composing "logfmt" by default,
even though this line itself doesn't contain any strings to be
translated.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:17:16 -0500] rev 23966
osutil: fix memory leak of PyBytes of path in statfiles
Spotted with cpychecker.
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 19:52:26 -0800] rev 23965
revert: move prefetch to after the actions logic
The prefetch logic came before the actual population of the actions collection,
so it was always being passed an empty action list. This fixes it by moving it
to after that logic.
The only consumer of this function at the moment is remotefilelog, and I
verified it works with this change.
Augie Fackler <raf@durin42.com> [Wed, 28 Jan 2015 13:34:20 -0500] rev 23964
diffhelpers: fix botched return statement from c8e7fa41bfc5
Spotted by Sean Farley using clang.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 27 Jan 2015 20:57:43 -0500] rev 23963
subrepo: don't abort in add when non-hg subrepos are present (issue4513)
This change should have been part of 9994f45ba714.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:14:23 -0500] rev 23962
osutil: fix leak of stat in makestat when Py_BuildValue fails
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:12:55 -0500] rev 23961
osutil.c: clean up space before a tab
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:10:04 -0500] rev 23960
dirs: fix leak of iterator in dirs_fromiter
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:07:04 -0500] rev 23959
diffhelpers: verify hline was created before using it
Found with cpychecker.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Jan 2015 22:55:10 -0500] rev 23958
largefiles: revert to lfilesrepo.status() being an unfiltered method
This effectively reverts 67d63ec85eb7, which caused some normal file copies to
not be displayed as copies. Other normal file copies could be displayed- the
exact reason isn't clear. This also adds two tests that were failing prior to
this backout, so that this can be sorted out next cycle.
The difference between copy cases that worked and those that didn't seemed to be
in copies.pathcopies(). When largefiles isn't enabled for the changed test, or
lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'.
That wasn't true otherwise, which fell through to the _chain() method. In this
case, the copy is removed in the criss cross loop.
'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type
in the failing case. I tried adding the ancestor method to the lfilesctx class
to change the type of the ancestor context, however the context when printed as
a string then gains a '+'. This points to it being a context.committablectx,
which clearly isn't correct for an ancestor. Possibly the problem is the
lfilesctx needs to subclass context.committablectx in some cases, but
context.changectx in others, within the same invocation? I'm not sure how to
pull that off, and backing out this change is safer during the freeze.
As to the status changing when a path is specified, I haven't looked into it
yet.
Matt Mackall <mpm@selenic.com> [Sun, 25 Jan 2015 20:13:54 -0600] rev 23957
test-tools: portability tweak
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Jan 2015 20:20:27 +0900] rev 23956
revset: fix ancestors(null) to include null revision (issue4512)
Since 13c0327eeb6f, null parent is explicitly excluded. So, there is no reason
to have nullrev in the initial seen set.
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 13:14:00 +0900] rev 23955
log: use rev() to build revset of --follow option from numeric revision
startrev can be -1.
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 12:56:38 +0900] rev 23954
revset: allow rev(-1) to indicate null revision (BC)
This can simplify the conversion from numeric revision to string. Without it,
we have to handle -1 specially because repo['-1'] != repo[-1].
The -1 revision is not officially documented, but this change makes sense
assuming that "rev(%d)" exists for scripting or third-party tools.
Siddharth Agarwal <sid0@fb.com> [Fri, 23 Jan 2015 20:30:49 -0800] rev 23953
extensions: don't quit loading extensions in the middle if traceback is on
This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if
loading an extension failed when --traceback was on, then at some point morphed
into a 'return 1' in a function that otherwise returns nothing.
At this point, if ui.traceback is enabled and if loading an extension fails for
whatever reason, including one as innocent as it not being present, we leave
any extensions loaded so far in a bogus half-initialized state. That doesn't
really make any sense.