Summary:
Previously, running arc lint on a set of changes that only
existed in your working copy threw an exception in mercurial repos.
It was trying to use the revset "...." (i.e. the range from . to .),
which didn't parse. Even if I fix that it still doesn't work because
getRawDiffText did not include the working copy changes (which it does
in git). I removed the check so the function now acts the same as in
git and arc lint works on working copy changes. I've seen this error before
in other places so hopefully this change will also fix any other areas,
that depended on getRawDiffText working the same as git.
The logic I removed was added in D1954 to support diffing against
uncommited changes. That workflow should be unchanged. arc diff will
still prompt the user if there are uncommited changes, and the user can
still choose to abort or continue.
Let me know if I missed something important which makes this a bad idea.
Test Plan:
Edited a file in the working directory of a hg repo.
arc lint
Verified lint ran successfully.
Also ran arc diff and land with and without working copy changes to make sure
they still work. I'd kill for some tests in this area...
Reviewers: epriestley, vrana
Reviewed By: epriestley
CC: dschleimer, bos, sid0, aran, Korvin
Maniphest Tasks: T1631
Differential Revision: https://secure.phabricator.com/D5130
Summary:
Mercurial 'arc land --hold' was taking 90+ seconds on our large
repository. Since most of arc land doesn't require any particular working
directory, I've changed the mercurial logic to avoid all updates except for
two: the one prior to finding the revision (only applies if the user specified
--branch), and the one at the end to leave the user in a good state.
Also got rid of a 'hg outgoing' call when phases are supported. Also changed
the hg-subversion detection to just look for .hg/svn instead of running 'hg
svn info', which was taking 4 seconds.
Now arc land takes about 50 seconds. Still much worse than git's 25 seconds.
One big hot spot is in the two 'hg rebase' calls, which account for 25 seconds
(versus 11 seconds of git).
Test Plan:
Tested arc land with mercurial and git. Tested with and without the --branch
options.
Reviewers: epriestley, bos, sid0, dschleimer
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5014
Summary: This chunk of code is kind of iffy and not really correct, but make it not fail, at least.
Test Plan:
- Added a file named `swamp@2x.jpg` to a working copy.
- Used `svn propedit svn:mime-type swamp@2x.jpg@` to incorrectly set its mime type to `text/plain`.
- Ran `arc diff`.
- Saw `arc diff` "correctly" change its mime-type to a binary mime type. This isn't really correct, but doing it successfully is better than throwing an exception.
Reviewers: mbishopim3, chad
Reviewed By: mbishopim3
CC: aran
Differential Revision: https://secure.phabricator.com/D4998
Summary: The `svn diff --xml --summarize` command reports a bunch of item statuses, which may include "none" if you make property changes to a directory (this is fairly rare).
Test Plan: Created property changes, saw "none" status.
Reviewers: chad, mbishopim3
Reviewed By: chad
CC: aran
Differential Revision: https://secure.phabricator.com/D4978
Summary: Followup to D4703. When we give paths to `svn`, we need to escape them if they contain an `@`.
Test Plan:
Created a patch full of modifications to files with `@` in their names, and applied it:
$ arc patch --diff 192
A A@2xcopy2
A A@2xcopy
D A@2x
OKAY Successfully applied patch to the working copy.
Reviewers: chad, mbishopim3
Reviewed By: chad
CC: aran
Differential Revision: https://secure.phabricator.com/D4977
Summary:
After D4383, we escape the base commit when constructing a command like this:
hg log --rev (base::. - base)
However, if the base commit is a revset like ".^", we now escape it and Mercurial looks for a commit named ".^" (a valid mercurial branch name) instead.
Fix this by returning nodes for these rules instead of revsets. The "arc:this" rule is automatically used in some operations, like "arc amend", so users can hit this during normal workflows, not just with weird `--base` rules.
Test Plan: Ran "arc amend" in a Mercurial repository, didn't fatal out.
Reviewers: DurhamGoode, sid0
Reviewed By: DurhamGoode
CC: tido, aran
Differential Revision: https://secure.phabricator.com/D4949
Summary: Git spits these out with \n at the end.
Test Plan:
```
>>> orbital ~/devtools/arcanist $ git branch --set-upstream trim master
Branch trim set up to track local branch master.
>>> orbital ~/devtools/arcanist $ arc which --base arc:upstream
RELATIVE COMMIT
If you run 'arc diff', changes between the commit:
acf7600e6e Temporarily restore apache/license linters
...and the current working copy state will be sent to Differential, because
it is the merge-base of the upstream of the current branch and HEAD, and
matched the rule 'arc:upstream' in your args 'base' configuration.
You can see the exact changes that will be sent by running this command:
$ git diff acf7600e6e728395..HEAD
These commits will be included in the diff:
3580555e4b30598f WIP
MATCHING REVISIONS
These Differential revisions match the changes in this working copy:
(No revisions match.)
Since there are no revisions in Differential which match this working copy, a
new revision will be created if you run 'arc diff'.
```
Reviewers: brennantaylor
Reviewed By: brennantaylor
CC: aran
Differential Revision: https://secure.phabricator.com/D4913
Summary:
Previously 'arc diff X' with mercurial meant to use X as the base
to diff against. Now it means use gca(X,working directory) as the base to
diff against. This matches the git behavior.
Test Plan:
Ran 'arc diff master' on a repo where master was ahead of the feature branch.
Verified that the diff result included only the diffs in the feature branch.
Reviewers: epriestley, sid0, bos, dschleimer
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4865
Summary:
arc diff on large mercurial repos was taking 14 seconds just to get
to the commit message prompt. With these optimizations it takes 4.
- "ancestor(.) - ancestor(XYZ)" is expensive because it has to build the
entire 400000+ revision history for both. "XYZ::. - XYZ" is much cheaper
because it only looks at the revisions between XYZ and the working directory.
- "hg outgoing" has to talk to the server, which is slow. "hg log -r draft()"
gives us the same information and is much cheaper. We fall back to 'outgoing'
on older versions of mercurial.
Of the remaining 4 seconds, 2.5 are spent in 'hg status', which is a bit harder
improve.
Test Plan: Ran arc diff on our hg repo. Verified it ran faster and the diff was created.
Reviewers: epriestley, sid0, bos, dschleimer
Reviewed By: epriestley
CC: aran, Korvin, tido
Differential Revision: https://secure.phabricator.com/D4838
Summary:
Record author email information in `arc diff`, so we can recreate it in `arc patch` and elsewhere without creating any kind of email exposure issues.
In Mercurial, we currently store the whole string ("username <email@domain.com>"). Make this consistent with Git.
Test Plan: Created git and hg diffs, saw authorEmail populated.
Reviewers: btrahan, edward, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4825
Summary:
We assume `git` is available now, but should not. Specifically, if a user runs a working copy operation like `arc list` in an SVN working copy without `git` available, they get this error: P707
We interpret git errors very narrowly; be more liberal in how we interpret them. This assumes users working with `git` will have a functional `git`, but this seems like a reasonable assumption and lets us remove some error text matching code.
Test Plan: Changed `git` to `girt`, ran `arc list`, saw a reasonable exception. Changed back to `git`, saw git detected.
Reviewers: btrahan, vrana
Reviewed By: vrana
CC: svemir, aran
Differential Revision: https://secure.phabricator.com/D4804
Summary: Fixes T2438. We currently escape everything with '@', but SVN rejects that for '.'
Test Plan:
Unit tests. Performed this commit:
$ svn st
M .
A x@123
$ arc commit --conduit-uri=http://local.aphront.com:8080/ --revision 53
Revision 'D53: asdf' has not been accepted. Commit this revision anyway?
[y/N] y
Committing 'D53: asdf'...
Sending .
Adding x@123
Transmitting file data .
Committed revision 37.
Done.
I grepped for more '@' adding but couldn't find any. It's a bit tricky to grep for though, so it's possible I missed some.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran, mbishopim3
Maniphest Tasks: T2438
Differential Revision: https://secure.phabricator.com/D4703
Test Plan: Deleted file in Git, ran `arc diff`, confirmed the question, saw the file as deleted.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4603
Summary:
A git submodule looks a lot like a normal git repo, but the .git
directory is replaced with a file that git reads to find the real
location of the git directory. When arcanist tries to write a file into
a directory inside of there, it was failing silently, and then crashing
silently when it couldn't read results back out. Instead of assuming the
git directory is a directory named .git at the toplevel of the tree, we
use the appropriate git command to get the correct git directory.
Test Plan: submit a diff from a submodule
Reviewers: epriestley, vrana
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4482
Summary:
D4186 added an "svn status --xml x y" form to getSVNStatus(), but the parser doesn't work for multiple files, since we get multiple <target /> elements in the XML output. So, curently, `arc diff` works (one target, all files) and `arc diff x` works (one target, x) but `arc diff x y` does not (more than one target, hits the exception).
$ arc diff QUACK2 QUACK3
Exception
Expected exactly one XML status target.
Test Plan: Ran `arc diff QUACK2 QUACK3` in a working copy with modified QUACK2, QUACK3. Ran `arc diff`; `arc diff QUACK2`.
Reviewers: vrana, btrahan, codeblock, JThramer
Reviewed By: codeblock
CC: aran
Differential Revision: https://secure.phabricator.com/D4372
Summary: If you are explicit then there is no need to ask you.
Test Plan:
$ touch a
$ arc diff
$ arc diff a
$ arc diff existing
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4186
Summary:
See D4049, D4096.
- Move commit range storage from Mercurial and Git APIs to the base API.
- Move caching up to the base level.
- Store symbolic name and resolved name separately, so we can re-resolve the correct commit from the symbolic name after dirtying caches.
- Rename `supportsRelativeLocalCommit()` to `supportsCommitRanges()` (old name wasn't very good, and not consistent with new terminology like the `--base` flag).
- Rename `getRelativeCommit()` and `setRelativeCommit()` to `getBaseCommit()` and `setBaseCommit()`.
- Introduce `reloadCommitRange()` and call it from `reloadWorkingCopy()`.
I think this fixes the problem in D4049, and provides a general solution for the class of problems we're running into here, with D4096. Specifically:
- We no longer get dirty caches, as long as you call reloadWorkingCopy() after changing the working copy (or call a method which calls it for you).
- We no longer get order-of-parsing-things problems, because setBaseCommit() reloads the appropriate caches.
- We no longer get nasty effects from calling `requireCleanWorkingCopy()` too early.
Test Plan: This is pretty far-reaching and hard to test. Unit tests; ran various arc commands. :/
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4097
Summary:
This method is used in three cases:
# For unit tests, to set the range to 'HEAD^' or '.^' in an agnostic way.
# For "amend", to set the range to the commit to be amended (also 'HEAD^' or '.^').
# For "patch" and "upgrade" so we don't fail just because there's an invalid "base" rule somewhere in the config when doing clean-working-copy tests.
For cases (1) and (2), introduce an "arc:this" rule to mean "the current commit". For case (3), remove the call; it is no longer necessary to check the commit range in order to do tests for the working copy state after D4095.
Test Plan: Ran unit tests, "arc upgrade", "arc patch", "arc amend".
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4096
Summary:
See discussion in D4049.
The getWorkingCopyStatus() method gets called from requireCleanWorkingCopy() in a lot of places, which triggers resolution of the base of the commit range. This is unnecessary; we do not need to examine the base commit in order to determine whether the working copy is dirty or not. This causes problems, in D4049 and elsewhere (we currently have a lot of fluff calls to setDefaultBaseCommit() in workflows which need to call requireCleanWorkingCopy() but do not ever use commit ranges, such as `arc patch`). This is mostly an artifact of SVN, where the "commit range" and "uncommitted stuff in the working copy" are always the same.
- Split the method into two status methods: getUncommittedStatus() (uncommitted stuff in the working copy, required by requireCleanWorkingCopy()) and getCommitRangeStatus() (committed stuff in the commit range).
- Lift caching out of the implementations into the base class.
- Dirty the cache after we commit.
This doesn't do anything useful on its own and creates one caching problem (`commitRangeStatusCache` is not invalidated when the commit range changes because of `setBaseCommit()` or similar) but I wanted to break things apart here. I won't land it until there's a more complete picture.
This creates a minor performance regression in git and hg (we run less stuff in parallel than previously) but all the commands should be disk-bound anyway and the regression should be minor. It prevents a larger regression in `hg` in D4049, and lets us do less work to arrive at common error states (dirty working copy). We can examine perf at the end of this change sequence.
Test Plan: Ran unit tests, various `arc` commands.
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4095
Summary:
Makes arc land support hg repositories. Both bookmarks and named branches can be landed. For the most part all the arc land options work, but there are a few caveats:
- bookmarks can only be landed on bookmarks
- branches can only be landed on branches
- landing a named branch with --merge creates a commit to close the branch before the merge.
- since mercurial doesn't start with a default master bookmark, landing a bookmark requires specifying --onto or setting arc.land.onto.default
Test Plan:
Tested arc land with all permutations of --merge, --keep-branch on both bookmark branches and named branches. Also tested --hold, --revision, --onto, --remote.
See https://secure.phabricator.com/P619
Also tested git arc land with --merge and --keep-branch.
Reviewers: dschleimer, sid0, epriestley, bos
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4068
Summary: I plan to use it in `save_lint.php`.
Test Plan:
$api->getUnderlyingWorkingCopyRevision(); // In Git SVN repo
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4054
Summary: `svn info` is the slowest command for discovering repository (up to 300 ms) and Subversion is probably the least used repository type with Arcanist. Let's discover it last.
Test Plan:
$ arc lint --trace
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4039
Summary: Also delete extra newlines.
Test Plan:
$ arc diff # on top of my commit
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2025
Differential Revision: https://secure.phabricator.com/D3996
Summary:
There's quite some logic in here:
- It automatically decides whether to create a new commit or amend.
- It partially respects 'default-relative-commit'.
- However if it points to a closed revision then it creates a new commit.
Resolves T2025.
Test Plan:
`arc diff` on:
- Clean committed repository.
- Dirty repository without commit since 'default-relative-commit'.
- Dirty repository with non-revision commit since 'default-relative-commit'.
- Dirty repository with revision commit since 'default-relative-commit'.
- `arc diff HEAD^` on dirty repository on top of closed revision.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2025
Differential Revision: https://secure.phabricator.com/D3967
Summary:
accommodate git's diff.suppress-blank-empty=true setting
Without this change, if you were to set diff.suppress-blank-empty=true
in your .gitconfig (as I do), then "arc diff" would always fail with the
cryptic diagnostic, "Diff Parse Exception: Found the wrong number of
hunk lines."
Test Plan:
Put this in ~/.gitconfig or .git/config
[diff]
suppress-blank-empty = true
and run "arc lint". It should pass. Without this chnage,
it would fail as described above.
Reviewers: vrana, epriestley
Reviewed By: vrana
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D3963
Summary:
Run `hg status` as a Future while getting the diff. Add a cache for
getRawDiffText().
Test Plan:
Run `arc lint --trace` on a HG repo and confirm that `diff` is only called once
and `status` is run in the background.
Reviewers: epriestley
Reviewed By: epriestley
CC: yliang, dpepper, aran, Korvin
Maniphest Tasks: T2016
Differential Revision: https://secure.phabricator.com/D3913
Summary:
This commit doesn't change license of any file. It just makes the license implicit (inherited from LICENSE file in the root directory).
We are removing the headers for these reasons:
- It wastes space in editors, less code is visible in editor upon opening a file.
- It brings noise to diff of the first change of any file every year.
- It confuses Git file copy detection when creating small files.
- We don't have an explicit license header in other files (JS, CSS, images, documentation).
- Using license header in every file is not obligatory: http://www.apache.org/dev/apply-license.html#new.
This change is approved by Alma Chao (Lead Open Source and IP Counsel at Facebook).
Test Plan: Verified that the license survived only in unit tests and LICENSE file.
Reviewers: epriestley, btrahan, edward
Reviewed By: epriestley
CC: aran, Korvin, davidrecordon
Maniphest Tasks: T2035
Differential Revision: https://secure.phabricator.com/D3881
Summary:
This is horrible and git specific, but fixes a case where people are using "arc
patch --nobranch ..." when they're not currently on a branch.
The old code assumed you were on a branch and used getBranchName() to record
this, in order to return to that branch later and cherry-pick the patch.
When not on a branch, and using arc patch --nobranch, this was trying to return
to the branch '(no branch)'.
Now, I detect that we're not on a branch and just record what HEAD is instead.
Test Plan:
Checkout the SHA of master (so I'm on master, but not on a branch) then try to
patch it with a feature diff:
€ git checkout e7a3ec68159d6847372cab5ad913f2f15aa7c249
Warning: you are leaving 1 commit behind, not connected to
any of your branches:
ac1ad39 Updating a-file
If you want to keep them by creating a new branch, this may be a good time
to do so with:
git branch new_branch_name ac1ad392350a51edd10343f12b9713f5e5b3707c
HEAD is now at e7a3ec6... Fix arcconfig
€ arc patch --nobranch D7
Created and checked out branch arcpatch-D7.
OKAY Successfully committed patch.
€ git branch
* (no branch)
feature
haddock
master
€ git log --oneline | head -2
38c0235 Updating a-file
e7a3ec6 Fix arcconfig
Reviewers: vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D3743
Summary: `arc patch` currently warns about "This diff is against commit svn+ssh://... but the commit is nowhere in the working copy" in Git SVN repository.
Test Plan:
$ arc patch # in Git SVN repository
$ svn find-rev r121212112 # invalid revision
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D3539
Git commit messages must have 2 newlines between the subject and body
If used to rewrite a commit message then the commit message will be
incorrectly reformatted.
Summary:
This reduces time of `arc branch` from 13s to 7s in my repo which is faster than `git branch --verbose` (10s).
The price for this speedup is that we loose the information [ahead 1, behind 21242] but we showed it only in branches with no revision so it's not a big deal.
Test Plan:
$ arc branch
Reviewers: epriestley
Reviewed By: epriestley
CC: ahupp, aran, Korvin
Differential Revision: https://secure.phabricator.com/D3005
