Change the behavior of the forget command such that explicit paths in
subrepos are handled by forgetting the file in the subrepo. This eliminates the
previous behavior where if you called "hg forget" for an explicit path in a
subrepo, it would state that the file is already untracked.
Prior to this patch "hg diff -U0", i.e., zero lines of context, would
output hunk headers with a start line one greater than what GNU patch
and git output. Guido van Rossum documents the unified diff format[1]
as having a start line value "one lower than one would expect" for
zero length hunks.
Comparing the behaviour of the three systems prior to this patch in
transforming
c1
c3
to
c1
c2
c3
- GNU "diff -U0" reports the hunk as "@@ -1,0 +2 @@"
- "git diff -U0" reports the hunk as "@@ -1,0 +2 @@"
- "hg diff -U0" reports the hunk as "@@ -2,0 +2,1 @@"
After this patch, "hg diff -U0" reports "@@ -1,0 +2,1 @@".
Since "hg export --config diff.unified=0" outputs zero-context unified
diffs, "hg import" has also been updated to account for start lines
one less than expected for zero length hunk ranges.
[1]: http://www.artima.com/weblogs/viewpost.jsp?thread=164293
Complex merges with divergent renames can cause a file to be 'moved'
twice, causing dirstate.drop() to be called twice. Rather than try to
ensure there are no unexpected corner cases where this can happen, we
simply ignore drops of files that aren't tracked.
# this change redones part of e0051068893a, backed out by 38c00c035629
Some character encodings use ASCII characters other than
control/alphabet/digit as a part of multi-bytes characters, so direct
replacing with such characters on strings in local encoding causes
invalid byte sequences.
[mpm: test changed to simple doctest]
While Chrome, Firefox, and IE 6+ support the current date format being
passed to Date(), Safari doesn't:
> new Date('Mon Oct 24 13:58:01 2011 +0200')
Invalid Date
However, the rfc822date format--officially supported by
ECMAScript[1]--does work:
> new Date('Mon, 24 Oct 2011 13:58:01 +0200')
Mon Oct 24 2011 04:58:01 GMT-0700 (PDT)
This change replaces all instances of {date|date} in HTML with
{date|rfc822date}. For elements that only have the "age" class,
there's no outward change for users with JavaScript enabled. For
elements with both the "age" and "date" classes, the full date
displayed uses the new format.
Tested in IE 6, Safari 5.1.1, Google Chrome 15, and Firefox 7.0.1.
[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
When dirstate parent is changed with dirstate.setparent before a
revert so it no longer points to where the dirstate refered to, revert
does not remove all files it should:
Revert to a different revision needs also to remove files that are not
found through disptables and not in the context or parent manifest.
The 'Bin' marker was added to every changed file for which we could not find
any diff changes. This included binary files but also copy/renames and mode
changes. Since Mercurial regular diff format emits a 'Binary file XXX has
changed' line when fed with binary files, we use that and the usual git marker
to tell them from other cases. In particular, new empty files are no longer
reported as binary.
Still, this fix is not complete since copy/renames/mode changes are now
reported as '0' lines changes, instead of 'Bin'.
On Windows, we store symlinks as plain files with the link contents.
Via user error or NFS/Samba assistance, these files often end up with
'normal' file contents. Committing these changes thus gives an
invalid symlink that can't be checked out on Unix.
Here we filter out any modified symlink placeholders that look
suspicious when computing status:
- more than 1K (looks more like a normal file)
- contain NULs (not allowed on Unix, probably a binary)
- contains \n (filenames can't contain \n, very unusual for symlinks,
very common for files)
Before this patch, Windows always did the wrong thing with exec bits
when committing a merge: consult the flags in first parent.
Now we manually recompute the result of merging flags at commit time,
which almost always does the right thing (except when there are
conflicts between symlink and exec flags).
To do this, we:
- pull flag synthesis out into its own function
- delay building this function unless it's needed
- add a merge case that compares flags in local and other against the ancestor
This has been tested in multiple ways on Linux:
- running the whole test suite with both old and new code in place,
checking for differences in each flags() result
- running the whole test suite while comparing real on-disk flags
against synthetic ones for merges
- test-issue1802 (from Martin Geisler) which disables exec bit
checking on Unix
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
Matching lines without trailing '\n' was missing the last character.
That seems to have been an unintended side effect of 8abe3f27975c.
The test in c21748e4cd4d documents the bad behaviour.
When talking to old server discovery use heads of the 'None' branch to refer to
topological heads. This use of None should never make it to the end user.
Before, we deleted foo when we determined that there were zero
changesets in the foo subrepo. Any files in foo was deleted too. We
now delete foo/.hg instead, and the normal checks in hg.clone will
then abort if there are untracked files in foo.
Before, running 'hg archive -S' could result in
abort: unknown revision '65903cebad86f1a84bd4f1134f62fa7dcb7a1c98'!
if a subrepo was missing completely or had missing changesets. Now,
the missing changesets will be pulled or cloned as appropriate.
This make Mercurial subrepos match Git subrepos which already took
care to fetch any missing commits before starting the archive.
