Fix theoretical issue in filecommit.
If the file was copied, we don't want to reuse the original entry.
I think this is mostly a theoretical issue - when there are copies,
fp1 == nullid, so it's very unlikely that the fl.cmp(fp1, t) would
think the file was unmodified. In any case, if there was a copy,
we should forcefully create a new entry.
Avoid adding to the changelog executable files added by the second parent.
This was a regression introduced by
b51a8138292a.
avoid double slash problem mentioned in
issue695
clone: remove "file://" before making the path absolute
This avoids writing bogus paths to .hgrc. Fixes
issue695.
pull -r: pass the revisions as the heads argument of findincoming
This can make a hg pull -r faster if the remote repo has many heads,
and fixes an "abort: received changelog group is empty".
convert: fix
issue702 about GIT_DIR= construct unsupported under Windows.
check exec: return fallback in case of error during the check
If there is any error while checking if exec is supported,
we can return fallback.
fix
issue705
merge: forcefully mark files that we get from the second parent as dirty
After a hg merge, we want to include in the commit all the files that we
got from the second parent, so that we have the correct file-level
history. To make them visible to hg commit, we try to mark them as dirty.
Unfortunately, right now we can't really mark them as dirty[1] - the
best we can do is to mark them as needing a full comparison of their
contents, but they will still be considered clean if they happen to be
identical to the version in the first parent.
This changeset extends the dirstate format in a compatible way, so that
we can mark a file as dirty:
Right now we use a negative file size to indicate we don't have valid
stat data for this entry. In practice, this size is always -1.
This patch uses -2 to indicate that the entry is dirty. Older versions
of hg won't choke on this dirstate, but they may happily mark the file
as clean after a full comparison, destroying all of our hard work.
The patch adds a dirstate.normallookup method with the semantics of the
current normaldirty, and changes normaldirty to forcefully mark the
entry as dirty.
This should fix
issue522.
[1] - well, we could put them in state 'm', but that state has a
different meaning.