Such unknown files may need to be backed up. Having them identified beforehand
will help simplify the backup logic.
We now use different sets with different backup strategies.
During the silicon age, humans on planet Earth discovered the use of
variables. This marvelous invention let them improve both code
readability and performance.
Now that we removed the (hopeless) attempt to backup file we knew to be
missing in the target changeset, we can stop checking if the file exists in
the target changeset.
There is only one case where a backup is required in the `dsadded` set, and the
current backup mechanism fails to handle it. So we stop trying to do backups at
all for now. This will help us to simplify the backup code and finally fix
this backup issue.
This allow extensions that mess with the storage layer (remotefilelog,
largefile) to prefetch any data that will be accessed during the revert
operation.
We are currently fetching more data than theoretically required because the
backup code is a bit stupid. Future patches will improve that.
Before this patch, no message is shown for failure of merging at "hg
import".
In such case, merging patch is imported as a normal revision silently,
and it may confuse users.
For simplicity, this patch recommends just using "--exact", even
though importing the merging patch itself is possible without it if:
- the hash of the 1st parent in the patch is equal to one of the
patch imported just before (or the parent of the working
directory, for the 1st patch of the series), and
- the hash of the 2nd parent in the patch is known in the local
repository
Previously, there was a copy / paste error with using the current changeset's
phase information. We now look up the parent context explicitly.
The line was too long so it is stored into a variable first.
The internal API used IOError to indicate that a file should be marked as
removed.
There is some correlation between IOError (especially with ENOENT) and files
that should be removed, but using IOErrors to represent file removal internally
required some hacks.
Instead, use the value None to indicate that the file not is present.
Before, spurious IO errors could cause commits that silently removed files.
They will now be reported like all other IO errors so the root cause can be
fixed.
Before this patch, external editor is invoked when imported patch has
no commit message, even if "--exact" is specified. Then, exact-ness is
broken, because empty commit message causes failure of committing.
This patch avoids editor invocation at importing with "--exact" for
exact-ness, because commit message in the patch should be kept as it
is in such case, even if it is empty.
We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.
This patch makes commit message shown in text editor customizable by
template. For example, this can advertise:
- sample commit messages for routine works,
- points to call attention before commit,
- message of the day, and so on
To show commit message correctly even in problematic encoding, this
patch chooses the latter below:
- replace "buildcommittext" with "buildcommittemplate" completely
- invoke "buildcommittemplate" only if '[committemplate] changeset'
is configured explicitly
For example, if multibyte character ending with backslash (0x5c) is
followed by ASCII character 'n' in the customized template, sequence
of backslash and 'n' is treated as line-feed unexpectedly (and
multibyte character is broken, too).
This corruption occurs in 'decode("string-escape")' while parsing
template string.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
other in "hg import" without "--bypass" case.
This patch assumes "editform" variations for "hg import" below:
import.normal.normal
import.normal.merge
import.bypass.normal
import.bypass.merge
Unlike other patches in this series, this patch uses "editor.sh"
instead of "checkeditform.sh" for the name of the script to check
"HGEDITFORM", because it has to do more than checking "HGEDITFORM".
To invoke editor forcibly in "test-import-merge.t", this patch creates
the patch not having patch description as "merge.nomsg.diff".
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "amend.normal" and "amend.merge" as ROUTE of
"editform" instead of "amend", to distinguish merge commits from other
in "hg commit --amend" case.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
others in "hg commit" without "--amend" case.
This patch assumes "editform" variations for "hg commit" below:
commit.normal.normal
commit.normal.merge
commit.amend.normal
commit.amend.merge
"mergeeditform" is factored out for subsequent patches. It takes
"ctxorbool" argument, because context object can't be passed in some
cases.
We check for rename information in the dirstate. This is probably not enough to
preserve this behavior when using an explicit target rev.
I just spotted this while working on this code, but this is outside the scope
of my series so I'm just adding a comment to highlight this suspicious
situation.
All those checks were here to catch cases where files were not modified in
dirstate but were different in the target revision. This is now properly handled
by calling status on the target node too.
In case of merge, file that are actually added can be reported as modified. This
is currently handled by special-case code. We detect it beforehand instead. This
will lets use remove the special-case code at some point in the future.
There are multiple possible cases for added files. But it's all handled by magic
much lower in the stack. We document them, simplify the codes and move on.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
Using status information against the target ensures we are catching all
files with modifications that need reverting.
We still need to distinguish fresh modifications for backup purpose.
test-largefile is affected because it reverted a file that needs no content
change.
We had a special case for file not caught by any categories. It was
aimed at files missing in wc and wc's parent but existing in the target
revision. This is now properly handled using status information.
Using status information against the target to make sure we are catching all
files that need to be re-added.
We still need to distinguish fresh removal because they use a different
message.
Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.
This fixes a couple of test outputs where the lack of changes was not reported.
Status can return file as "deleted". This is only a special case
related to working directory state: file is recorded as tracked but no
file exists on disk. This will never be a state obtainable from
manifest comparisons.
"Deleted" files have another working directory status shadowed by the lack of
file. They will -alway- be touched by revert. The "lack of file" can be seen as
a modification. The file will never match the same "content" as in the revert
target. From there we have two options:
1. The file exists in the target and can be seen as "modified".
2. The file does not exist in the target and can be seen as "added".
So now we just dispatch elements from delete into appropriate categories.
When a file was marked as removed in the working copy and did not existed in the
target of the revert, we did not issued any message pointing that no change was
needed to the file (implicitly saying that revert had changed the file).
We now properly issue a message in this situation. Tests change in and handful
of case where the message was documented as missing.
We now call status against the target (and possibly against the working
directory parent is different). We do not use the information from the two
sources yet, but this is coming soon.
We need the status information aganst the dirstate in all case because we need
to be able to backup local modification.
