Summary:
Create a new class for them, pass instance around as need.
This looks like it's mostly working, but I'd like to replace the various `new ArcanistConfigurationManager()`
calls with something more suitable.
And maybe get a better name for ArcanistConfigurationManager ("Configuration" is already taken).
Test Plan: arc unit --everything, and then some.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley
CC: Korvin, epriestley, aran, chad
Differential Revision: https://secure.phabricator.com/D7271
Summary: Nice title. Ref T479.
Test Plan:
Actually, help on that? I want to make sure I properly build up the "depends" on data. Is it as simple as
-- observe at some commit hash RAZZMATAZZ
-- git checkout -B "foo"
-- <work>
-- git commit -m "stash"
-- arc diff -> yields DX
-- git checkout -B "foo_prime"
-- <work>
-- git commit -m "stash"
-- arc diff -> yield DY
-- git checkout RAZZMATAZZ
-- arc patch DY
-- get prompted in workflow, agree
-- git log and observe DX and DY applied
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran, davidressman
Maniphest Tasks: T479
Differential Revision: https://secure.phabricator.com/D6790
Summary:
If in a subdirectory, any changes made in a different location
is missed from the patch with no errors from git. The other
option was to run some logic to compare the files being changed.
Test Plan:
Run arc patch from a subdirectory that would miss some files
previously.
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Maniphest Tasks: T3733
Differential Revision: https://secure.phabricator.com/D7167
Summary:
The existing lint configurations do not allow for linting only the lines that have
changed when paths are added. --lintall has a default behavior of true when paths are specified,
and false when paths are not specified. Because of this (and because it does not take a boolean
param) it is not possible to lint a path for only the errors on changed lines - only-new is not
working presently.
Test Plan: play around with the linter
Reviewers: lifeihuang
Reviewed By: lifeihuang
CC: epriestley, aran
Differential Revision: https://secure.phabricator.com/D7055
Summary:
Fixes T3856.
Detailed code coverage iterates over all of the files with changes in the current repository, however the code coverage tool might not generate a report for all changed files in the repository, and this would result in an undefined index error.
As an additional bonus, since changes to binary files won't be reported by code coverage tools, this also prevents binary data from being outputted to the console.
Test Plan:
Change a binary file in a repository and run a code coverage tool. The binary file should be reported as 0% code coverage, but the file contents should not be rendered to the console.
Change a code file that is not covered by a code coverage tool and run code coverage. The file should be reported as 0% code coverage, and the file contents should not be displayed.
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Maniphest Tasks: T3856
Differential Revision: https://secure.phabricator.com/D7051
Test Plan: Saw 'Do you want to add these files to the commit?'
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6991
Summary:
Make sure on failure (restoreBranch()) we call `git submodule update --init --recursive` to handle all those purdy submodules. For the pushing step, wrap the push commands in the try / catch block so everything gets cleaned up nice if there's failure. BONUS - add --recursive to arc patch workflow to so nested submodules work correctly. (Crazy git users)
Fixes T3407, T2945.
Test Plan: I wasn't sure how to simulate a good "push" failure but I think this should work.
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Maniphest Tasks: T2945, T3407
Differential Revision: https://secure.phabricator.com/D6885
Summary:
When running arc diff in a repository that supports commit ranges, it is
possible that the setting for the default relative commit hasn't been set.
If this is the case, the user will be prompted. This change makes sure that
the prompt happens (and thus the setting is set) before we run the
background lint and unit runs.
Test Plan:
```
rm .git/arc/default-relative-commit
arc diff
```
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Maniphest Tasks: T2351
Differential Revision: https://secure.phabricator.com/D6854
Summary:
Ref T3776, Ref T479. Say you have some DN, with a submodule X@Y. Later, X@Z in your working copy / repo. If you run arc patch DN, you'd end up with a dirty working copy claiming that X@Z was wrong and it should be X@Y.
To fix, basically run 'submodule init' and 'submodule update'. This makes it so after "arc patch" if you run "git status" it looks clean.
Gross part though now is if you then "git checkout master" you'll have a dirty checkout the other way. I think this is better though.
Test Plan: made a new repository where I added libphutil @ X, did some work (DX), then made libphutil @ y. When I arc patch'd DX, things looked good!
Reviewers: epriestley
Reviewed By: epriestley
CC: csilvers, Korvin, aran
Maniphest Tasks: T479, T3776
Differential Revision: https://secure.phabricator.com/D6837
Summary:
Currently, we prompt the user to mark non-UTF8 files as binary, but don't actually attach the data to the change when they do. This means we don't upload the data, and can't patch it later.
A simple reproduction case is to build a test file (I used one with bytes from 1..255):
$ # Don't include \0, since Git treats that specially.
$ ./echo_every_byte_from_1_to_255_inclusive.erl > example.txt
Then add it:
$ git add example.txt
$ git commit -a -m derp
$ arc diff --only HEAD^
You'll be prompted to convert the file to binary:
Do you want to mark this file as binary and continue? [Y/n] y
Before this patch, that would be followed by:
Uploading 0 files...
...which is incorrect; we need to upload the new data. After this patch, this shows:
Uploading 1 files...
...which is also incorrect, but only grammatically. Diffs created after this patch apply back cleanly with `arc patch` and restore the file properly.
Test Plan: Followed instructions above, restoring a textual binary conversion by using `arc patch`.
Reviewers: zeeg, btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D6815
Summary: Fixes T3696. Currently, we abort. If stdin is not a TTY, we should just continue. A script which cares could conceivably run `arc lint` and `arc unit` separately, but it seems unlikely that any script would ever want to fail here.
Test Plan: Ran `echo -n '' | arc diff --create --verbatim` with a lint error and got a revision (D6720).
Reviewers: Firehed, btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3696
Differential Revision: https://secure.phabricator.com/D6721
Summary:
Ref T2039. That task has a bunch of discussion, but basically we do a poor job of serving the midrange of lint configuration right now.
If you have something simple, the default linters work.
If you have something complex, building your own engine lets you do whatever you want.
But many users want something in between, which isn't really well accommodated. The idea is to let you write a `.arclint` file, which looks something like this:
{
"linters" : {
"css" : {
"type" : "csslint",
"include" : "(\.css$)",
"exclude" : "(^externals/)",
"bin" : "/usr/local/bin/csslint"
},
"js" : {
"type" : "jshint",
"include" : "(\.js$)",
"exclude" : "(^externals/)",
"bin" : "support/bin/jshint",
"interpreter" : "/usr/local/bin/node"
}
}
}
...which will provide a bunch of common options around lint severity, interpreter and binary locaitons, included and excluded files, etc.
This implements some basics, and very rough support in the Filename linter.
Test Plan:
Generated a `.arclint` file and saw it apply filename lint correctly. Used `debug` mode and tried invalid regexps.
{
"debug" : true,
"linters" : {
"filename" : {
"type" : "filename",
"exclude" : ["@^externals/@"]
}
}
}
Next steps include:
- Provide an external linter archetype (T3186) and expose a common set of configuration here ("bin", "interpreter", "flags", "severity").
- Provide a `.arcunit` file which works similarly (it can probably be simpler).
Reviewers: btrahan, Firehed
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2039
Differential Revision: https://secure.phabricator.com/D6797
Summary:
arc for mercurial on windows was broken in several way.
Executing a command via passthru failed because passthru on windows
skips the shell so 'set HGPLAIN=1 & ...' was an invalid command. The
fix was to just not set HGPLAIN for passthru commands on windows.
Also removed hardcoded '' quotes in mercurial commands since windows
doesn't support single quots.
Test Plan: arc land --hold on a windows machine
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6763
Summary: Corrects relative vs absolute branch name when using 'arc commit'
Test Plan: 'arc commit' on a release branch gave an error before making the change (change was generated from 'branches/yyy' but working copy root is 'https://xxx/branches/yyy', now it does not.
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6743
Summary: My recent change adding --everything to arc lint could sometimes cause a "diff is empty" error, this patch fixes it.
Test Plan: Ran "arc lint --everything" before and after patch. No longer errors out. Only appeared to originally happen when there were uncommited changes in an svn repo.
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6732
Summary:
When trying to find an unused bookmark we append hyphened suffixes to the end of the bookmark name. In Mercurial, these are treated the same as the bookmark name without the suffix, here's the output from hg log -r:
```
[mehdi] HGPLAIN=1 hg log -r "arcpatch-1"
abort: unknown revision 'arcpatch'!
[mehdi] HGPLAIN=1 hg log -r "arcpatch_1"
abort: unknown revision 'arcpatch_1'!
```
Test Plan: None.
Reviewers: epriestley, dschleimer
Reviewed By: dschleimer
CC: aran, Korvin, DurhamGoode, dschleimer
Differential Revision: https://secure.phabricator.com/D6698
Summary:
If you are trying to commit someone else's diff, arc commit gives warnings about path mismatch. This changes the path comparison to be based on the repo url rather than the local working directory. E.g. if both the author and committer are working in branches/release/2013_08_07 despite being checked out in ~/dev/2013_08_07 (system user being different, of course) it no longer warns that the WC path is different
Original behavior:
eric@Eric-MBP ~/dev/2013_07_31: arc commit --revision 21
You are not the author of 'D21: WeMerge Automatic Request'. Commit this
revision anyway? [y/N] y
Revision 'D21: WeMerge Automatic Request' was generated from '', but
current working copy root is '/Users/eric/dev/2013_07_31/'. Commit this
revision anyway? [y/N] y
Committing 'D21: WeMerge Automatic Request'...
Adding test
Transmitting file data .
Committed revision 52676.
Closing revision D21 'WeMerge Automatic Request'...
Exception
ERR-CONDUIT-CORE: You can not mark a revision you don't own as closed.
(Run with --trace for a full exception trace.)
New behavior:
eric@Eric-MBP ~/dev/2013_07_31: arc commit --revision 24
You are not the author of 'D24: WeMerge Automatic Request'. Commit this
revision anyway? [y/N] y
Committing 'D24: WeMerge Automatic Request'...
Adding test
Transmitting file data .
Committed revision 52679.
Closing revision D24 'WeMerge Automatic Request'...
Exception
ERR-CONDUIT-CORE: You can not mark a revision you don't own as closed.
(Run with --trace for a full exception trace.)
Test Plan: 'arc diff' changes with one user. 'arc patch Dxx' on a different working copy by a different user to review and test changes. accept review. 'arc commit --revision xx' as reviewer to land the patch. complaint goes away.
Reviewers: epriestley, ghostwriter78
Reviewed By: epriestley
CC: aran, epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D6665
Summary:
Support for no output from arc unit (For scripts, etc).
Also include --output param, analogous to arc lint --output.
Test Plan: run all 6 variants + `--output bad-value`
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6642
Summary:
Single quotes aren't valid in the windows cmd prompt, so arc feature
didn't work in mercurial when it got to this line.
I have no idea why %C was used before. Nothing in that string should be
broken by the escaping.
Test Plan:
Ran arc feature --trace on my mac. Verified the command was escaped correctly
and the correct feature results were printed.
I don't have a windows machine to try it on, but the builtin escaping should
now account for windows machines.
Reviewers: epriestley
Reviewed By: epriestley
CC: sid0, aran, Korvin
Differential Revision: https://secure.phabricator.com/D6637
Summary:
When adding arcanist support to a new project or adding a new linter,
it's helpful to be able to run new linters against the entire codebase. This
patch adds support for this with an '--everything' option, similar to 'arc unit
--everything'
Test Plan:
Run 'arc lint --everything' and check out the code. Optionally dump
the paths to test in the current lint engine's buildLinters() function to
demonstrate that it's receiving all files in the project rather than just the
changed and/or specified ones
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley, Korvin
Differential Revision: https://secure.phabricator.com/D6592
Summary:
- Replace `maniphest.find` with `maniphest.query`. These calls are nearly identical, it was just a rename for consistency.
- Replace `differential.find` with `differential.query`.
Test Plan:
- Ran `arc tasks`.
- Ran `arc close-revision` on valid, nonexistent, and existent-but-invalid revisions.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D6336
Summary: Makes sense now
Test Plan: Get someone else to test it
Reviewers: epriestley
CC: aran, Korvin
Maniphest Tasks: T3342
Differential Revision: https://secure.phabricator.com/D6307
Summary: Enables the process to pass the user input for library name. Fixes T3342
Test Plan: Little help... `arc liberate` doesn't run on windows. Though I saw the flag :)
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3342
Differential Revision: https://secure.phabricator.com/D6306
Summary:
Previously, updating a commit via arc diff in mercurial would
prepopulate the update message with part of the commit message. In an
amend workflow this doesn't make sense, so I disabled it. Git already
does this, so now mercurial matches git in this scenario.
We had users complain that new users would often submit diffs with the
default update message, and it wasn't useful since they were using a
amend flow.
Test Plan:
arc diff on a commit that already had a diff
Verified the editor did not have a update message
arc diff on a stack of commits where the bottom one had a diff
Verified the editor provided a default update message
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6215
Summary: We currently swallow the exception message, but this isn't useful. Fixes T3354.
Test Plan:
$ arc diff HEAD^ --conduit-uri=http://local.aphront.com:8080/ --only
Uploading 1 files...
Failed to upload new binary 'large.png'.
[HTTP/500] Internal Server Error
As received by the server, this request had a nonzero content length but no POST data.
Normally, this indicates that it exceeds the 'post_max_size' setting in the PHP configuration on the server. Increase the 'post_max_size' setting or reduce the size of the request.
Request size according to 'Content-Length' was '2093052', 'post_max_size' is set to '100K'.
Continue? [Y/n]
Reviewers: jamesr, chad
Reviewed By: chad
CC: aran
Maniphest Tasks: T3354
Differential Revision: https://secure.phabricator.com/D6186
Summary: Now that we examine these in lint, this came up. There is no `ConduitException`; the class is `ConduitClientException`.
Test Plan: Lint.
Reviewers: vrana, chad
Reviewed By: chad
CC: aran
Differential Revision: https://secure.phabricator.com/D6158
Summary:
Piping data around on Windows doesn't work well when it contains zany characters like "null" and "newline". Fixes T3266.
Instead of piping data into `git apply`, write to a temporary file.
Test Plan:
Ran `arc patch`, got good results.
>>> [17] <exec> $ git apply --index --reject -- '/private/var/folders/8k/c3vkmjy5335gcxdzxkhwq82w0000gn/T/7z9iea6srikoo0sc/4266-ZEyvz9'
Reviewers: btrahan, hach-que
Reviewed By: hach-que
CC: aran
Maniphest Tasks: T3266
Differential Revision: https://secure.phabricator.com/D6070
Summary:
Arc Revert does the following:
1. Git revert
2. Go to the differential of the rev you are reverting and either repoen it or set it to a reverted state
3. File a hipri task to orig author
[Preview] Creating Arc Revert workflow
Porting arc revert from FB4A to phabricator for general usage. This is my first stab,
so totally appreciate feedback and assistance. I'm currently focused
on making this work for git. However, I built out the functions through the GitAPI so this
could be easily extendable to Mercurial later on.
Stuck on the following (help):
1. Creating a task for FB internal. I tried building on top of existing arc listeners
but getting errors on failures to load the TaskCreator (and other) tasks.
2. I'm using a hacky way to grab the diff revision id from the newly created
revert diff. (see line 204) I'm looking for a way to just fetch the diff ID
from arc after the diff is created; is this possible?
Test Plan:
-
1. Ran arc revert on a www and fbcode diff
2. Confirmed that revert was run on the diffs and a proper diff filed
-
Reviewers: royw, sdwilsh, nh, epriestley
Reviewed By: epriestley
CC: aran, epriestley, Korvin, pti, keir
Maniphest Tasks: T1751
Differential Revision: https://secure.phabricator.com/D5553
Summary:
During my attept to `arc land master` on `master` branch
I have discovered that error message is missing few spaces between words.
I have added them and used this ugly readonly command:
pcregrep --include="\.php$" -M -r '(?<!\\n| )("|'"'"')\.\n\s*\1(?!\\n| )' ~/arc/arcanist/src
to detect other instances of this serious bug.
Two more were found.
This time they were probably introduced in order to abide
to the draconian lint rule about number of columns.
Since I want to be a good citizen,
I have added this missing space to the begining of the next line in both cases.
It is an ugly hack, but I think user should not suffer due to missing spaces.
Another solution could be preserving no leading spaces and splitting long lines.
Or just providing excuse to lint.
Test Plan: Ran `arc land master` on `master` branch.
Reviewers: epriestley, vrana
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3008
Differential Revision: https://secure.phabricator.com/D5827
Summary:
Fixes T2266. Motivation:
- The lint cache does not always invalidate correctly. Because of the nature of the cache, this is a hard problem (right after "naming things").
- We already have a fair amount of complexity in trying to invalidate it, and are still discovering new places where it doesn't work (e.g., Windows with "/" vs "\" paths).
- One invalidation failure is when linter code changes, which seems unresolvable in the general case (e.g., changes to external linters).
- It's not obvious what's happening when the lint cache causes some kind of issue.
- Particularly while developing or debugging linters, your changes often won't be reflected in the lint output. Some of this is theoretically tractable but the external linter case probably isn't.
- When someone reports a problem with the lint cache in IRC or elsewhere, there is essentially never a way for me to fix it. The lint cache can't be debugged effectively without access to a working copy where the problem reproduces.
- The cache provides limited benefit outside of Facebook's install.
To remedy these issues:
- Introduce configuration which controls cache usage.
- Default it off.
- Print a message when the cache is in use.
(I'd tentatively support removing the cache entirely, but I don't know how @vrana and Facebook feel about that.)
Test Plan: Ran `arc set-config --show`, `arc lint --cache 0`, `arc lint --cache 1`.
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran, mbishopim3, nh, edward, wez
Maniphest Tasks: T2266
Differential Revision: https://secure.phabricator.com/D5766
named the same as a file path.
Summary: (In fbcode and www at least, the only places I tried) if a
branch happens to be named the same as a file path (from root) (like if
a branch is called `spec` and there is a directory in `www` called
`spec`) then `arc land` will fail with git complaining that the argument
(to `git log ...`) is ambiguous as it could refer to both a path and a
revision; so this diff adds a `--` to the end so that git knows that
both are revisions and not paths.
Test Plan: Try and land something from www (I did, see D752219) where
the branch is named `spec`.
Reviewed by: epriestley
Test Plan:
$ set # on Windows
Reviewers: epriestley, dschleimer
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5733
Summary:
Arc lint for git is currently adding all untracked files when it
amends the commit with lint fixes. This changes the git add -A to be
git add -u. This only adds files that were already tracked. -A was adding
untracked files as well which was not the desired behavior here.
Test Plan:
Create an untracked file.
Commit a lint failure another file.
arc diff and choose to amend the lint patches.
Verify that the untracked file was not added but the tracked file was amended.
Reviewers: epriestley, wez, chad
Reviewed By: chad
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5731
Summary:
arc lint was hardcoded for git for amending commits with lint
patches. This enables the same functionality for mercurial.
Test Plan:
Made some changes that would result in a lint patch.
arc diff
Verify that the patches it produces were amended into the commit.
Verified it still works in git as well.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5716
Summary:
@ender is reporting a parsing issue in SVN, but we don't build a parser with setWriteDiffOnFailure() set in this workflow right now so I can't get the raw file to fix the issue.
Use the onboard mechanism to build a parser with `setWriteDiffOnFailure()` set, so it will write the diff, so I can get a copy so I can fix the problem.
Test Plan: Ran `arc diff --preview` in an SVN repo with a linter.
Reviewers: ender, btrahan
Reviewed By: ender
CC: aran
Differential Revision: https://secure.phabricator.com/D5699
Summary:
This adds a arcconfig setting to allow specifying whether to use the merge
or rebase strategy when doing the feature branch update.
arc.land.update.default can be set to either 'rebase' or 'merge'. The command
line flags will override this setting.
We have had trouble with arc land producing merge commits (introduced
with D4080) in git. They usually appear when arc land fails, and our users
are confused by the presence of a merge commit afterwards. Today it got even
worse since a user managed to get arc land to push the merge commit to the
server. This setting will allow us to turn it off for our uses.
Test Plan:
Verified the following combinations:
update.default not set + arc land (saw git merge in the trace)
update.default = 'rebase' + arc land (saw git rebase)
update.default = 'merge' + arc land (saw git merge)
update.default = 'rebase' + arc land --update-with-merge (saw git merge)
update.default = 'merge' + arc land --update-with-rebase (saw git rebase)
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5683
Summary:
The `emailuser` template is a relatively recent addition to Mercurial, and a few users have complained about it. It also doesn't actually do what I thought it did, e.g. in an address like this:
"Abraham Lincoln" <alincoln@whitehouse.gov>
^^^^^^^^^^^^^^^ ^^^^^^^^
(1) (2)
^^^^^^^^^^^^^^^^^^^^^^^
(3)
...I want (1), but `emailuser` means (2). Instead, extract (1) with `getDisplayName()` and (3) with `getAddress()` using PhutilEmailAddress.
The implementation in Mercurial is not particularly sophisticated or magical (it just looks for "@" and "<") so we aren't really missing anything by doing this ourselves, at least today.
Also fix some issues in `arc export`, which literally no one uses, but which is occasionally useful for testing (as here).
Test Plan:
- Ran `arc diff --only` in an `hg` repo, checked DB to see that name/email were correctly extracted.
- Ran `arc export --git` in an `hg` repo, didn't get a long series of fatals.
Reviewers: btrahan, DurhamGoode
Reviewed By: DurhamGoode
CC: aran
Maniphest Tasks: T2866, T2858
Differential Revision: https://secure.phabricator.com/D5539
Summary:
Arc land is a bit magical and some users have gotten bitten by
the fact that it collapses and lands every commit on the branch. To make
it explicit what is being landed, it now shows a list of the commits
that are being landed. I also added a --preview flag that will just
print the commits that would be landed, but does nothing else.
Hopefully this make arc land a little less magical for people.
Test Plan:
arc land in the following scenarios:
- Landing one change
- Landing no changes
- Landing a stack of changes
Did it with hg and git.
Reviewers: epriestley
Reviewed By: epriestley
CC: nh, sid0, dschleimer, bos, aran, Korvin
Differential Revision: https://secure.phabricator.com/D5460
Summary:
Previously, arc patch would create a new commit under the existing
current bookmark in mercurial. There have been two discussions about what the
right behavior should be (D3334 and D3658). One side wants no commit at all,
and one side wants a commit under a new bookmark. The current implementation is
the worst of both worlds :(
This change makes it create a new bookmark at the revision's base before commiting,
same as the --bookmark flag used to do (which is now obsolete). That way the
existing bookmark doesn't move (in mercurial >=1.8). This is the same behavior
git has, which is convienent for groups migrating between the two.
Also makes hg's getCanonicalRevision handle svn revisions just like git. This way
arc patch will try to apply the patch to the appropriate revision in the history.
Test Plan:
Ran:
arc patch - Verified it created a new bookmark and commited on top of the
revision's base commit.
arc patch --nobranch - Verified it put the new commit on top of the current
bookmark without a new bookmark.
arc patch --nocommit - Verified it left all the changes in the working copy.
Also verified arc patch still works with git.
Reviewers: epriestley
Reviewed By: epriestley
CC: sid0, bos, dschleimer, aran, Korvin
Differential Revision: https://secure.phabricator.com/D5408
