- Jun 21, 2017
-
-
Matt Harbison authored
I tried adding quotes to the $PYTHON variable, and also tried converting the path from the current 'c:/Python/python.exe' form to '/c/python/python.exe', but neither worked. I'm not sure why one of these needs '\"' around the variable and the other doesn't.
-
- Jun 20, 2017
-
-
Augie Fackler authored
Spotted one of these, then wrote a check-code rule that caught them all. It will be the next change.
-
- Jan 12, 2017
-
-
Matthieu Laneuville authored
The result of diffstatdata should not depend on having noprefix set or not, as was reported in issue 4755. Forcing noprefix to false on call makes sure the parser receives the diff in the correct format and returns the proper result. Another way to fix this would have been to change the regular expressions in path.diffstatdata(), but that would have introduced many unecessary special cases.
-
- Oct 17, 2016
-
-
Mads Kiilerich authored
-
- Oct 08, 2016
-
-
Ryan McElroy authored
Previously, when a patch contained a move or copy from a source that did not exist, `hg import` would crash. This patch changes import to raise a PatchError with an explanantion of what is wrong with the patch to avoid the stack trace and bad user experience.
-
- Aug 26, 2016
-
-
liscju authored
Import uses paths relative to the root of the repository, so when user imports patch with paths relative to the current working directory import aborts with 'unable to find file for patching'. This patch improves this situation by warning the user that paths are relative to the root of repository when patching fails.
-
- Jul 03, 2016
-
-
Pulkit Goyal authored
This patch includes addition of absolute_import and print_function to the files where they are missing. The modern importing conventions are also followed.
-
- Nov 16, 2015
-
-
Matt Harbison authored
The extension was failing to load on Windows because $TESTTMP contains a path component 'test', prefixed by a path separator '\'. That combination ends up converted to "...<tab>est...".
-
- Oct 16, 2015
-
-
Katsunori FUJIWARA authored
This patch centralizes passing HG_PENDING to external hook process into '_exthook()'. To make in-memory changes visible to external hook process, this patch does: - write (or schedule to write) in-memory dirstate changes, and - set HG_PENDING environment variable, if: - a transaction is running, and - there are in-memory changes to be visible This patch tests some commands with some hooks, because transaction activity of a same hook differs from each other ("---": "not tested"). ======== ========= ========= ============ command preupdate precommit pretxncommit ======== ========= ========= ============ unshelve o --- --- backout x --- --- import --- o o qrefresh --- x o ======== ========= ========= ============ Each hooks are examined separately to prevent in-memory changes from being visible to external process accidentally by side effect of hooks previously invoked.
-
Katsunori FUJIWARA authored
Before this patch, external editor process for the commit log can't view some in-memory changes (especially, of dirstate), because they aren't written out until the end of transaction (or wlock). This causes unexpected output of Mercurial commands spawned from that editor process. To make in-memory changes visible to external editor process, this patch does: - write (or schedule to write) in-memory dirstate changes, and - set HG_PENDING environment variable, if: - a transaction is running, and - there are in-memory changes to be visible "hg diff" spawned from external editor process for "hg qrefresh" shows: - "changes newly imported into the topmost" before 49148d7868df(*) - "all changes recorded in the topmost by refreshing" after this patch (*) 49148d7868df changed steps invoking editor process Even though backward compatibility may be broken, the latter behavior looks reasonable, because "hg diff" spawned from the editor process consistently shows "what changes new revision records" regardless of invocation context. In fact, issue4378 itself should be resolved by 800e090e9c64, which made 'repo.transaction()' write in-memory dirstate changes out explicitly before starting transaction. It also made "hg qrefresh" imply 'dirstate.write()' before external editor invocation in call chain below. - mq.queue.refresh - strip.strip - repair.strip - localrepository.transaction - dirstate.write - localrepository.commit - invoke external editor Though, this patch has '(issue4378)' in own summary line to indicate that issues like issue4378 should be fixed by this. BTW, this patch adds '-m' option to a 'hg ci --amend' execution in 'test-commit-amend.t', to avoid invoking external editor process. In this case, "unsure" states may be changed to "clean" according to timestamp or so on. These changes should be written into pending file, if external editor invocation is required, Then, writing dirstate changes out breaks stability of test, because it shows "transaction abort!/rollback completed" occasionally. Aborting after editor process invocation while commands below may cause similar instability of tests, too (AFAIK, there is no more such one, at this revision) - commit --amend - without --message/--logfile - import - without --message/--logfile, - without --no-commit, - without --bypass, - one of below, and - patch has no description text, or - with --edit - aborting at the 1st patch, which adds or removes file(s) - if it only changes existing files, status is checked only for changed files by 'scmutil.matchfiles()', and transition from "unsure" to "normal" in dirstate doesn't occur (= dirstate isn't changed, and written out) - aborting at the 2nd or later patch implies other pending changes (e.g. changelog), and always causes showing "transaction abort!/rollback completed"
-
- Oct 13, 2015
-
-
Katsunori FUJIWARA authored
'localrepository.rollback()' explicilty restores dirstate, only if at least one of current parents of the working directory is removed at rollbacking (a.k.a "parent-gone"). After DirstateTransactionPlan, 'dirstate.write()' will cause marking '.hg/dirstate' as a file to be restored at rollbacking. https://mercurial.selenic.com/wiki/DirstateTransactionPlan Then, 'transaction.rollback()' restores '.hg/dirstate' regardless of parents of the working directory at that time, and this causes unexpected dirstate changes if not "parent-gone" (e.g. "hg update" to another branch after "hg commit" or so, then "hg rollback"). To avoid such situation, this patch restores dirstate to one before rollbacking if not "parent-gone". before: b1. restore dirstate explicitly, if "parent-gone" after: a1. save dirstate before actual rollbacking via dirstateguard a2. restore dirstate via 'transaction.rollback()' a3. if "parent-gone" - discard backup (a1) - restore dirstate from 'undo.dirstate' a4. otherwise, restore dirstate from backup (a1) Even though restoring dirstate at (a3) after (a2) seems redundant, this patch keeps this existing code path, because: - it isn't ensured that 'dirstate.write()' was invoked at least once while transaction running If not, '.hg/dirstate' isn't restored at (a2). In addition to it, rude 3rd party extension invoking 'dirstate.write()' without 'repo' while transaction running (see subsequent patches for detail) may break consistency of a file backup-ed by transaction. - this patch mainly focuses on changes for DirstateTransactionPlan Restoring dirstate at (a3) itself should be cheaper enough than rollbacking itself. Redundancy will be removed in next step. Newly added test is almost meaningless at this point. It will be used to detect regression while implementing delayed dirstate write out.
-
- Oct 07, 2015
-
-
Pierre-Yves David authored
As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook point to do extra work after the import have been committed.
-
- Oct 06, 2015
-
-
Pierre-Yves David authored
As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook points to alter the changeset (especially extra) before we commit. There would be more to do for a full featured hooking, but this currently fit my needs.
-
- Jun 18, 2015
-
-
Matt Mackall authored
-
- Jun 02, 2015
-
-
Matt Harbison authored
-
- May 29, 2015
-
-
Gilles Moris authored
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
-
- May 18, 2015
-
-
Matt Harbison authored
-
- May 14, 2015
-
-
Gilles Moris authored
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.
-
- Mar 10, 2015
-
-
Siddharth Agarwal authored
This makes hg import --prefix dir/ (without bypass) work.
-
- Apr 18, 2014
-
-
Mads Kiilerich authored
commitctx already showed notes with filenames but didn't provide any context. It is just as relevant to know when manifest or changelog is committed. So, in addition to filenames, also show headlines 'committing files:', 'committing manifest' and 'committing changelog'.
-
- Oct 15, 2014
-
-
durin42 authored
This makes running the testsuite with pypy possible.
-
- Oct 09, 2014
-
-
Pierre-Yves David authored
This test, written after 3.0, is relying on addset being enforced ascending if both side are ascending. We are about to restore the ordering to 2.9 behavior (elements are ordered in the order they are specified). We fix the test before fixing the order.
-
- Aug 23, 2014
-
-
Katsunori FUJIWARA authored
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.
-
- Aug 16, 2014
-
-
Katsunori FUJIWARA authored
"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".
-
- May 09, 2014
-
-
Pierre-Yves David authored
The `hg import` command gains a `--partial` flag. When specified, a commit will always be created from a patch import. Any hunk that fails to apply will create .rej file, same as what `hg qimport` would do. This change is mainly aimed at preserving changeset metadata when applying a patch, something very important for reviewers. In case of failure with `--partial`, `hg import` returns 1 and the following message is displayed: patch applied partially (fix the .rej files and run `hg commit --amend`) When multiple patches are imported, we stop at the first one with failed hunks. In the future, someone may feel brave enough to tackle a --continue flag to import.
-
- May 10, 2014
-
-
Katsunori FUJIWARA authored
This patch also enhances "test-import-bypass.t" and "test-import.t", because "hg import" hasn't been explicitly tested around editor invocation and "--edit" option. This patch explicitly tests below: - with "--bypass" (regardless of "--edit"): - not invoked, if the patch contains the commit message - not invoked, if the commit message is explicitly specified - invoked, otherwise (just adding comment) - without "--bypass": - with "--edit": - not invoked, if "--no-commit" is not specified - invoked, otherwise - without "--edit": - not invoked, if the patch contains the commit message - not invoked, if "--message" or "--logfile" is specified (just adding comment) - invoked, otherwise
-
- Jul 28, 2013
-
-
Matt Mackall authored
We used to do this based on X-mailer: mentioning git, but git doesn't put X-mailer in its git-format-patch output.
-
- Feb 08, 2013
-
-
kiilerix authored
'export' is the official export format and used by patchbomb, but it would only show date as a timestamp that most humans might find it hard to relate to. It would be very convenient when reviewing a patch to be able to see what timestamp the patch will end up with. Mercurial has always used util.parsedate for parsing these headers. It can handle 'all' date formats, so we could just as well use a readable one. 'export' will now use the format used by 'log' - which is the format described as 'Unix date format' in the templating help. We assume that all parsers of '# HG changeset patch'es can handle that.
-
- Oct 08, 2012
-
-
Idan Kamara authored
-
- Jun 10, 2012
-
-
kiilerix authored
Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
-
- Jun 08, 2012
-
-
Adrian Buehlmann authored
-
Adrian Buehlmann authored
As pointed out by Mads, setting the x bit on dummypatch.py is unneeded, because it is called with 'python ../dummypatch.py'.
-
- May 12, 2012
-
-
Yuya Nishihara authored
Since 2b1ec74c961f, if a chunk starts with "@@ -0,1", oldstart turns into a negative value. Because diffhelpers.testhunk() doesn't expect negative bstart, it bypasses "alen > blen - bstart" condition and segfaults at "PyList_GET_ITEM(b, i + bstart)".
-
- Feb 13, 2012
-
-
Patrick Mézard authored
The previous code was assuming a default context of 3 lines. When fuzzing, it would take this value in account to reduce the amount of removed line from hunks top or bottom. For instance, if a hunk has only 2 lines of bottom context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove one of those lines. A hunk with one line of bottom context could not be fuzzed at all. patch(1) has apparently no such restrictions and takes the fuzz level at face value. - test-import.t: fuzz/offset changes at the beginning of file are explained by the new fuzzing behaviour and match patch(1) ones. Patching locations are different but those of my patch(1) do not make a lot of sense right now (patched output are the same) - test-import-bypass.t: more agressive fuzzing makes a patching supposed to fail because of context, succeed. Change the diff to avoid this. - test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply with fuzz, but fortunately we disallow this behaviour. The new output is kept. I have not enough experience with patch(1) fuzzing to know whether aligning our implementation on it is a good or bad idea. Until now, it has been the implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t runs the special case of pushing merge revisions where fuzzing is forbidden).
-
Patrick Mézard authored
When applying hunks such as: @@ -2,1 +2,2 @@ context +change fuzzing would empty the "old" block and make patchfile.apply() traceback. Instead, we apply the new block at specified location without testing. The "bottom hunk" test was removed as patch(1) has no problem applying hunk with no context in the middle of a file.
-
- Feb 16, 2012
-
-
Patrick Mézard authored
There is no reason to discard copy sources from the set of files considered by addremove(). It was done to handle the case where a first patch would create 'a' and a second one would move 'a' to 'b'. If these patches were applied with --no-commit, 'a' would first be marked as added, then unlinked and dropped from the dirstate but still passed to addremove(). A better fix is thus to exclude removed files which ends being dropped from the dirstate instead of removed. Reported by Jason Harris <jason@jasonfharris.com>
-
- Nov 20, 2011
-
-
kiilerix authored
'hg import' of a patch with mode changes requires unix permissions support in the file system.
-
- Nov 16, 2011
-
-
kiilerix authored
Stdout redirection is not binary safe everywhere - for example not on windows with msys.
-
- 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
-
- Oct 21, 2011
-
-
Kevin Bullock authored
-