Fri, 24 Mar 2017 14:59:19 -0700 statfs: change Linux feature detection
Jun Wu <quark@fb.com> [Fri, 24 Mar 2017 14:59:19 -0700] rev 31622
statfs: change Linux feature detection Previously we check three things: "statfs" function, "linux/magic.h" and "sys/vfs.h" headers. But we didn't check "struct statfs" or the "f_type" field. That means if a system has "statfs" but "struct statfs" is not defined in the two header files we check, or defined without the "f_type" field, the compilation will fail. This patch combines the checks (2 headers + 1 function + 1 field) together and sets "HAVE_LINUX_STATFS". It makes setup.py faster (less checks), and more reliable (immutable to the issue above).
Fri, 24 Mar 2017 16:20:10 -0700 rebase: don't require destination if commands.rebase.requiredest=False
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Mar 2017 16:20:10 -0700] rev 31621
rebase: don't require destination if commands.rebase.requiredest=False
Fri, 24 Mar 2017 16:20:04 -0700 tests: add tests with commands.{update,rebase}.requiredest=False
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Mar 2017 16:20:04 -0700] rev 31620
tests: add tests with commands.{update,rebase}.requiredest=False This shows how rebase is currently broken with commands.rebase.requiredest=False.
Sun, 12 Mar 2017 12:33:35 -0700 rebase: move state serialization to use unfiltered repo
Durham Goode <durham@fb.com> [Sun, 12 Mar 2017 12:33:35 -0700] rev 31619
rebase: move state serialization to use unfiltered repo Now that rebasestate is serialized as part of the transaction, the repo state it sees is the version at the end of the transaction, which may have hidden nodes. Therefore, it's possible parts of the rebase commit set are no longer visible by the time the transaction is closing, which causes a filtered revision error in this code. I don't think state serialization should be blocked from accessing commits it knows exist, especially if all it's trying to do is get the hex of them, so let's use an unfiltered repo here. Unfortunately, the only known repro is with the fbamend Facebook extension, so I'm not sure how to repro it in core Mercurial for a test.
Fri, 24 Mar 2017 22:29:22 +0900 largefiles: avoid redundant standin() invocations
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 24 Mar 2017 22:29:22 +0900] rev 31618
largefiles: avoid redundant standin() invocations There are some code paths, which apply standin() on same value multilpe times instead of using already standin()-ed value. "fstandin" is common name for "path to standin file" in lfutil.py, to avoid shadowing "standin()".
Fri, 24 Mar 2017 22:29:22 +0900 largefiles: replace hashrepofile by hashfile (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 24 Mar 2017 22:29:22 +0900] rev 31617
largefiles: replace hashrepofile by hashfile (API) There is only one user for the former, and repo.wjoin()-ed value is alread known by that user.
Fri, 24 Mar 2017 22:26:34 +0900 largefiles: call readstandin() with changectx itself instead of rev or node
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 24 Mar 2017 22:26:34 +0900] rev 31616
largefiles: call readstandin() with changectx itself instead of rev or node readstandin() takes "node" argument to get changectx by "repo[node]". There are some readstandin() invocations, which use ctx.node(), ctx.rev(), or '.' as "node" argument above, even though corresponded changectx object is already looked up on caller side. This patch calls readstandin() with already known changectx itself, to avoid meaningless re-construction of changectx (indirect case via copytostore() is also included). BTW, copytostore() uses "rev" argument only for readstandin() invocation. Therefore, this patch also renames it to "revorctx" to indicate that it can take not only revision ID or so but also changectx, for readability.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip