- Nov 20, 2011
-
-
Matt Mackall authored
-
- Nov 18, 2011
-
-
Wagner Bruna authored
-
kiilerix authored
This help entry didn't try to describe the 'localhost' notation. It described a non-standard host-less notation where 'local' just was the first part of a sample relative path. It describe "urls" with relative and absolute paths like: file://file.txt file:///tmp/file.txt file://c:/tmp/file.txt
-
- Nov 20, 2011
-
-
Matt Mackall authored
-
- Nov 11, 2011
-
-
Eric Roshan Eisner authored
It turns out there's a separate command to force git to look at file contents if the stat has changed.
-
- Nov 16, 2011
-
-
Thomas De Schampheleire authored
When hook output redirection is enabled (e.g. when cloning over ssh), hook output on stdout is redirected to stderr, to prevent the repository data on stdout from being corrupted. In certain cases, the redirection could cause part of the repository data to end up on stderr as well. In case of a clone, this causes: "abort: consistency error in delta!" This was seen with a clone over ssh, an outgoing hook present (any non-python type, e.g. 'pwd'), on certain repositories only, probably depending on the distribution of the sent data) This patch updates the hook redirection code to flush stdout before redirecting, removing the problem.
-
Patrick Mezard authored
With "wp1" and "wp2" the current working directory parents, "p1" and "p2" the patch parents and "parents" the resulting commit parents, the current behaviour is: --bypass --exact p2 parents 0 0 0 [wp1, wp2] 0 0 1 [wp1, wp2]/buggy 0 1 0 [p1] 0 1 1 [p1, p2] 1 0 0 [wp1, wp2] 1 0 1 [p1, p2] 1 1 0 [p1] 1 1 1 [p1, p2] The original behaviour before f53dc0787424 was: --bypass --exact p2 parents 0 0 0 [wp1, wp2] 0 0 1 if p1 == wp1 then [p1, p2] otherwise [wp1, wp2] 0 1 0 [p1] 0 1 1 [p1, p2] This patch restores the previous behaviour when --bypass is not set, and align --bypass behaviour when --exact is not set with merge diffs.
-
- Nov 13, 2011
-
-
Patrick Mezard authored
It was ignoring changes from: ab to: a b
-
- Nov 12, 2011
-
-
Stefano Tortarolo authored
In particular, we do not allow: - grafting an already grafted cset onto its original branch - grafting already grafted csets with the same origin onto each other
-
Stefano Tortarolo authored
-
Stefano Tortarolo authored
-
- Nov 13, 2011
-
-
Dmitry Panov authored
Python's time module sets timezone and altzone based on UTC offsets of two dates: first and middle day of the current year. This approach doesn't work on a year when DST rules change. For example Russia abandoned winter time this year, so the correct UTC offset should be +4 now, but time.timezone returns 3 hours difference because that's what it was on 01.01.2011. Related python issue: http://bugs.python.org/issue1647654
-
- Nov 16, 2011
-
-
Marc-Antoine Ruel authored
-
- Nov 15, 2011
-
-
kiilerix authored
posixpath normpath of c:\foo\bar/../baz is baz, so now we pconvert first.
-
- Nov 11, 2011
-
-
kiilerix authored
-
- Nov 15, 2011
-
-
file://localhost/c:/fookiilerix authored
The path was parsed correctly, but localpath prepended an extra '/' (as in '/c:/foo') because it assumed it was an absolute unix path.
-
file://localhost/file://local/kiilerix authored
The documentation has apparently always been wrong.
-
Matt Mackall authored
We used to use os.path.normcase which was a no-op, which was unhelpful for cases like VFAT on Linux.
-
Thomas Arendsen Hein authored
54c0517c0fe8 introduced a new block in test-convert-bzr-directories.t which produces a slightly different output with older bzr versions. Tested with bzr 1.5 on Debian lenny.
-
- Nov 10, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
"hg status" may treat cache missed largefiles as "removed" incorrectly. assumptions for problem case: - there is no cache for largefile "L" - at first, update working directory to the revision in which "L" is not yet added, - then, update working directory to the revision in which "L" is already added and now, "hg status" treats "L" as "removed". current implementation does not allocate entry for cache missed largefile in ".hg/largefiles/dirstate", but files without ".hg/largefiles/dirstate" entry are treated as "removed" by largefiles extension. "hg revert" can not recover from this situation, but "rm -rf .hg/largefiles", because it causes dirstate rebuilding. this patch invokes normallookup() for cache missed largefiles to allocate entry in ".hg/largefiles/dirstate", so "hg status" can treat it as "missing" correctly.
-
Matt Mackall authored
-
- Nov 08, 2011
-
-
Stefano Tortarolo authored
This could happen in specific situations in which 'target' was selected as external and used for p1 _and_ p2.
-
- Nov 09, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
- Nov 06, 2011
-
-
Stefano Tortarolo authored
When storing/restoring a nullmerge (-2), a 'standard' conversion was made and an existing changeset was wrongly used. Nullmerge should instead be treated as a special case.
-
- Nov 08, 2011
-
-
Stefano Tortarolo authored
-
- Nov 10, 2011
-
-
Nicolas Venegas authored
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
-
- Nov 08, 2011
-
-
Patrick Mezard authored
With renames like: a -> b a/c -> a/c We were ignoring or duplicating the second one instead of leaving files unchanged or moving them to their proper destination only. To avoid this, we process the files in reverse lexicographic order, from most to least specific change, and ignore files already processed. v2: - Add a test - Change "reverse=1" into "reverse=True"
-
- Nov 04, 2011
-
-
Martin Geisler authored
-
David M. Carr authored
Add details on which commands are supported for Subversion subrepos.
-
David M. Carr authored
Add details on which commands are supported for git subrepos.
-
David M. Carr authored
Update the subrepo help to be consistent with the new default behavior, which is to abort if any subrepo is dirty.
-
- Nov 03, 2011
-
-
Wagner Bruna authored
This is just a stopgap until a proper solution is implemented.
-
Hao Lian authored
When (1) findfile links a largefile from the user cache to the store and (2) the store directory doesn't exist yet, findfile errors out. A simple call to util.makedirs fixes it.
-
Matt Mackall authored
Spotted by Victor Stinner <victor.stinner@haypocalc.com>
-
- Nov 01, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
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.
-