Summary:
The commit interactive test was creating a bundle to test committing
binary files. It had no reason to need bundle1, so let's update it to bundle2.
Reviewed By: quark-zju
Differential Revision: D7591170
fbshipit-source-id: 964cd2cfc4368a89c956b30389ca74ab0b87a486
Summary:
We want to deprecate the bundlev1 format, so let's start by adding a
develwarn. Later diffs will update the tests to not use v1, then remove v1 as a
supported outgoing bundle entirely.
Reviewed By: quark-zju
Differential Revision: D7591166
fbshipit-source-id: 143ad029bfe4d141f91d6d5077342dfa44ad2944
Summary:
With `buck build`, the single hg binary won't be guarnateed to have
access to i18n messages because directories like `mercurial/locale`
do not exist on filesystem. It could also mess up with `PYTHONPATH`
somehow because the python binary wrapper sometimes ignores
`PYTHONPATH`.
So let's add a hghave feature for it. And gate troublesome tests
with `#if normal-layout`.
Reviewed By: DurhamG, phillco
Differential Revision: D6879876
fbshipit-source-id: 3d63605b55c8f7096093b89be824add2ec491f81
GNU grep (2.21-2 or later) assumes that input is encoded in LC_CTYPE,
and input is binary if it contains byte sequence not valid for that
encoding.
For example, if locale is configured as C, a byte setting most
significant bit (MSB) makes such GNU grep show "Binary file <FILENAME>
matches" message instead of matched lines unintentionally.
This behavior is recognized as a bug, and fixed in GNU grep 2.25-1 or
later. But some distributions are shipped with such buggy version
(e.g. Ubuntu xenial, which is used by launchpad buildbot).
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19230https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800670http://packages.ubuntu.com/xenial/grep
This causes failure of test-commit-interactive.t, which applies grep
on CP932 byte sequence since 4681296e309b.
But, explicit setting LC_CTYPE for CP932 might cause another problem,
because it can't be assumed that all environment running Mercurial
tests allows arbitrary locale setting.
To resolve this issue, this patch escapes bytes setting MSB in input
of grep.
For this purpose:
- str.encode('string-escape') isn't useful, because it escapes also
control code (less than 0x20), and makes EOL handling complicated
- "f --hexdump" isn't useful, because it isn't line-oriented
- "sed -n" seems reasonable, but "sed" itself sometimes causes
portability issue, too (e.g. 215a8789129e or 6d02ef568139)
This patch is posted with "stable" flag, because 4681296e309b is on
stable branch.
Before this patch, patch.filterpatch() shows meaningless translation
of help message for chunk selection in some encoding.
It applies str.lower() instead of encoding.lower(str) on translated
message, but some encoding uses 0x41(A) - 0x5a(Z) as the second or
later byte of multi-byte character (for example, ja_JP.cp932), and
str.lower() causes unexpected result.
To show lower-ed translated message correctly, this patch replaces
str.lower() by encoding.lower(str).
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
hg commit tracked untracked -- fails complaining about untracked
prior to this commit,
hg commit -i tracked untracked -- did not fail
This is corrected by calling the refactored localrepo.checkcommitpatterns
This test generate a bundle to get a binary file to commit. We should ensure
this binary file remains the same when we move to general delta as default.
Before this patch, 'hg commit -i' under non-interactive mode suggests
'use commit instead', and it obviously meaningless.
This patch makes 'record.record'()' examine 'ui.interactive()' and
show suggestion by itself before calling 'commands.commit()'.
This allows 'commands.commit()' to specify 'None' for 'cmdsuggest'
argument of 'cmdutil.dorecord()' to omit meaningless 'commit'
suggestion at 'hg commit -i'.
To detect change of a file without redundant comparison of file
content, dirstate recognizes a file as certainly clean, if:
(1) it is already known as "normal",
(2) dirstate entry for it has valid (= not "-1") timestamp, and
(3) mode, size and timestamp of it on the filesystem are as same as
ones expected in dirstate
This works as expected in many cases, but doesn't in the corner case
that changing a file keeps mode, size and timestamp of it on the
filesystem.
The timetable below shows steps in one of typical such situations:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.patch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
- 'hg status' shows "f" as "clean" N N N
---- ----------------------------------- ---- ----- -----
The most important point is that 'dirstate.write()' is executed at N+1
or later. This causes writing dirstate timestamp N of "f" out
successfully. If it is executed at N, 'parsers.pack_dirstate()'
replaces timestamp N with "-1" before actual writing dirstate out.
This issue can occur when 'hg commit -i' satisfies conditions below:
- the file is committed partially, and
- mode and size of the file aren't changed before and after committing
The root cause of this issue is that (maybe partially changed) files
are restored with original timestamp but dirstate isn't updated for
them.
To detect changes of files correctly, this patch applies
'dirstate.normallookup()' on restored files. Status check is needed
before 'dirstate.normallookup()', because status other than "n(ormal)"
should be kept at failure of committing.
This patch doesn't examine whether each files are committed fully or
partially, because interactive hunk selection makes it difficult.
After this change, timetable is changed as below:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.internalpatch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
----------------------------------- ---- ----- -----
- normallookup("f") -1
- release wlock
- 'dirstate.write()' -1 -1 N
----------------------------------- ---- ----- -----
- 'hg status' shows "f" as "clean" -1 -1 N
---- ----------------------------------- ---- ----- -----
To reproduce this issue in tests certainly, this patch emulates some
timing critical actions as below:
- change "f" at N
'touch -t 200001010000' before command invocation changes mtime of
"f" to "2000-01-01 00:00" (= N).
- apply selected hunks at N
'patch.internalpatch()' with 'fakepatchtime.py' explicitly changes
mtime of patched files to "2000-01-01 00:00" (= N).
- 'dirstate.write()' at N+1 (or "not at N")
'pack_dirstate()' uses actual timestamp at runtime as "now", and
it should be different from the "2000-01-01 00:00" of "f".
BTW, in 'test-commit-interactive.t', files are sometimes treated as
modified , even though they are just committed fully via 'hg commit
-i' and 'hg diff' shows nothing for them.
Enabling win32text causes EOL style mismatching below:
- files are changed in LF style EOL
=> files restored after committing uses LF style EOL (1)
- 'merge.update()' reverts files in CRLF style EOL
- 'patch.internalpatch()' changes files in CRLF style EOL
=> 'dirstate.normal()' via 'repo.commit()' uses the size of files
in CRLF style EOL (2)
Therefore, fully committed files are treated as "modified", because
'lstat()' returns size of (1) restored files in LF style EOL, but
dirstate expects size of (2) committed files in CRLF style EOL.
After this patch, 'dirstate.normallookup()' on committed files forces
subsequent 'hg status' to examine changes exactly, and fully committed
files are treated as clean as expected.
This is reason why this patch also does:
- add some 'hg status' checking status of fully committed files
- clear win32text configuration before size/timestamp sensitive examination
Before this patch, exiting a hunk edit in record with a non-zero status lead
to the end of the recording session, losing previously-selected hunks to record.
This patch introduces the more desirable behavior of warning the user and
continuing the recording session.
The phase of the pending commit depends on the parent of the working directory
and on the phases.newcommit configuration.
First, this information rather depend on the commit line which describe the
pending commit.
Then, we only want to be advertised when the pending phase is going to be higher
than the default new commit phase.
So the format will change from
$ hg summary
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge)
update: (current)
phases: 1 secret (secret)
to
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
update: (current)
phases: 1 secret
The number of draft and secret changesets are currently not summarized.
This is an important information because the number of drafts give some rough
idea of the number of outgoing changesets in typical workflows, without needing
to probe a remote repository. And a non-zero number of secrets means that
those changeset will not be pushed.
If the repository is "dirty" - some draft or secret changesets exists - then
summary will display a line like:
phases: X draft, Y secret (public)
The phase in parenthesis corresponds to the highest phase of the parents of
the working directory, i.e. the current phase.
By default, the line is not printed if the repository is "clean" - all
changesets are public - but if verbose is activated, it will display:
phases: (public)
On the other hand, nothing will be printed if quiet is in action.
A few tests have been added in test-phases.t to cover the -v and -q cases.
In my latest change on record (edit newly added file), I forgot the
repo.wjoin() so that record was not computing the paths properly to delete
the backups and was crashing.
I tried to fix this issue in the past and had to revert the fix. This is a
second attempt without the regression we found with the first one.
record defines special headers (of file) as headers whose hunk are not shown
to the user for editing, they are used to represent deleted, moved and new
files. Since we want to authorize editing the patch of newly added file we
make the newly added file with some content not special anymore. This entails
that we have to save their content before applying the backup to be able to
revert it if the patch does not apply properly.
We reintroduce the test showing that newly added files can be edited and that
their content is shown to the user.