Summary:
This change fixes 'arc patch' in some circumstances.
Closes T15254
Test Plan: I was able to run "arc patch D25111" without issues
Reviewers: O1 Blessed Committers, Matthew
Reviewed By: O1 Blessed Committers, Matthew
Subscribers: speck, tobiaswiese, Matthew, Cigaryno
Maniphest Tasks: T15187, T15254
Differential Revision: https://we.phorge.it/D25123
Summary:
Ref T13588. "arc-ls-markers" emits a "branch-state" marker so callers can identify which branch is active in the working copy.
This marker doesn't have an associated commit, so trying to generate a display name fails under stricter PHP 8.1 rules when we try to `substr(null, ...)`.
Don't attempt to generate a display name for markers with no commit hash.
Test Plan:
- Ran `arc branches` under PHP 8.1 in a Mercurial repository.
- Before: fatal.
- After: sensible output.
Maniphest Tasks: T13588
Differential Revision: https://secure.phabricator.com/D21825
Summary:
Refs T13665
In the update to D21716 the `str_starts_with` function was added which is only available in PHP 8. This changes it to use `strncmp()` which is compatible back to PHP 4.
Additionally fixed running into an error when trying to run `arc amend` on a commit which already matches the content known in Phabricator. Mercurial throws an error when running `amend` without file changes and using the exact same commit message it already has.
Test Plan:
I created a commit and revision then used `hg amend -e` to modify the commit message locally.
I used `arc amend` to update the commit message back to the appropriate message from Phabricator.
I ran `arc amend` again to verify that the command did not fail even though the commit message is unchanged.
I ran `arc inspect --explore -- 'commit(674492bb460)'` and verified it matched the appropriate commit, to verify the substring matching works properly.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13665
Differential Revision: https://secure.phabricator.com/D21723
Summary:
Mercurial does not have an implementation for querying commit symbol hardpoints, which is what the "arc amend" workflow uses.
This provides an implementation for Mercurial as well as updating `ArcanistMercurialAPI` to specify the current working directory symbol as `.`.
Additionally removed an erroneous early return in `ArcanistAmendWorkflow` which prevents a check against uncommitted changes.
Fixes T13665
Test Plan:
1. I created a diff on a Mercurial revision.
2. I updated the revisions summary in phabricator.
3. I ran `arc amend` and it successfully amended the local commit with the updated commit message.
4. I modified a file in the repository and left the change uncommitted.
5. I ran `arc amend` and verified that it reported an error due to uncommited commits.
I ran the following commands to verify that they resolved to the correct commits
1. `arc inspect --explore -- 'commit(674492bb460)'` properly matched the right commit as a commit hash prefix
2. `arc inspect --explore -- 'commit(674492bb4606666d5321feb38d2a467a8733c786)'` properly matched the right commit as a full commit hash
3. `arc inspect --explore -- 'commit(master)'` properly matched the right commit as a bookmark
4. `arc inspect --explore -- 'commit(tip)'` properly matched the right commit as a tag
5. `arc inspect --explore -- 'commit(.)'` properly matched the right commit as the working directory
6. `arc inspect --explore -- 'commit(cafe)'` properly matched the right commit as a commit hash prefix
7. I created a 'cafe' bookmark on a changeset
8. `arc inspect --explore -- 'commit(cafe)'` properly matched the right commit as a bookmark
9. `arc inspect --explore -- 'commit(67449)'` properly matched the right commit as a revision number
10. `arc inspect --explore -- 'commit(2147483648)'` properly did not match any revision (no python exception)
11. `arc inspect --explore -- 'commit(0)'` properly matched the first commit
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13665
Differential Revision: https://secure.phabricator.com/D21716
Summary: Ref T13659. I don't think this name actually matters since Mercurial doesn't care what the extension name is, but be a little more consistent.
Test Plan: Ran "arc land ..." and saw it run "arc-hg" commands. There's no behavioral change here: Mercurial loads the extension and runs fine no matter what name we provide.
Reviewers: cspeckmim
Reviewed By: cspeckmim
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21711
Summary:
Refs T13659, D21697.
I suppose I missed these cases.
Test Plan:
- I ran `arc land --test` and verified the rebase used by `ArcanistMercurialLandEngine` was run with the flag to enable the extension.
```
$ hg --encoding utf-8 --config 'extensions.rebase=' rebase --dest 2fd68f4c48aaab9f6d5613b90e60b8219a9af0ae --rev 6132da63090c2c8a8d479aaae7b20497dda3e8fd..6132da63090c2c8a8d479aaae7b20497dda3e8fd --logfile - --keep --collapse
```
- I modified the merging to throw an exception before writing to the future's stdin and verified that after `arc` completed there was no rebase active.
- I set up 3 dependent diffs and landed the middle revision and verified the first and second revisions landed but not the tip revision and there were no errors and the resulting working directory was correct.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21706
Summary:
Currently there are a number of `--config extensions.blah=` sprinkled throughout the Mercurial APIs which aren't pleasant to look at. Additionally it turns out the `rebase` command requires the `rebase` extension which is not turned on by default. Uses of `rebase` should also be including this flag to enable the extension when it's in use.
This adds `ArcanistMercurialAPI::buildMercurialExtensionCommand()` which allows running a Mercurial command that requires an extension just by naming the extension instead of providing the full `--config..` argument.
It can be used e.g.
```lang=php
$api->execxLocalWithExtension(
'strip',
'strip --rev %s --',
$rev);
$api->execxLocalWithExtension(
'arc-hg',
'arc-amend --logfile %s',
$tmp_file);
```
Which produces
```lang=console
$ hg --encoding utf-8 --config 'extensions.strip=' strip --rev 82567759e2d703e1e0497f5f41363de3a1500188 --
$ hg --encoding utf-8 --config 'extensions.arg-hg=/Users/cspeckrun/Source/phacility/arcanist/support/hg/arc-hg.py' arc-amend --logfile /private/var/folders/cg/364w44254v5767ydf_x1tg_80000gn/T/6bwck66ccx0kwskw/89989-5F8JaL
```
Refs T13659
Test Plan: I ran through several scenarios of running `arc diff` and `arc land` with uncommitted changes on non-head commits, while not having the `evolve` extension enabled. Using the `--trace` argument I verified that `rebase`, `strip`, `arc-amend`, and `arc-ls-markers` were all invoked and the corresponding `arc diff` and `arc land` commands succeeded. I also ran `arc land --onto-remote default` while `arc-hg.py` raised an exception for the "remote" case and verified that the error was caught by Arcanist and displayed the error and prevented further execution. I removed the error from `arc-hg.py` and re-ran the command and verified it succeeded.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13659
Differential Revision: https://secure.phabricator.com/D21697
Summary:
After `arc diff` creates a revision in Phabricator it amends the commit to include a link to the revision in the commit message. For Mercurial this is done with `hg commit --amend --logfile` however this will fail when trying to create a diff for a non-head commit.
This updates `ArcanistMercurialAPI::amendCommit()` to allow amending a non-head commit in two ways, depending on whether `evolve` is in use:
No evolve:
1. Rebasing the current commit onto the current commit's parent, using the new commit message
2. Rebasing all children + descendants of the current commit onto the new resulting commit
3. Stripping the original commit
With evolve:
1. Amend the commit with `hg amend --logfile`
2. Run `hg evolve` to tidy up all commits
Test Plan:
I created 6 commits in a row placing a bookmark at commits 2 `bookmark1`, 4 `bookmark2`, and 6 `bookmark3`, and ensured I had `arc:bookmark` in my base ruleset.
No evolve, non-head changeset:
1. I verified I did not have `evolve` enabled by running `hg debugextensions` and did not see `evolve` in the listed active extensions.
2. I updated to `bookmark1` and modified a file to leave a dirty working state.
3. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
4. I checked the status of my repository and verified it was still linear and the bookmarks pointed to the proper commits.
5. I ran `hg log -r bookmark1 --template {desc}` to view the full commit message and verified it contained both `Summary: ...` and `Differential Revision: https://...`.
6. I ran `hg diff -c bookmark1` and verified the changes for that commit included the changes I made in step 2.
No evolve, head changeset:
1. I updated to `bookmark3` which is the head commit and modified a file to leave a dirty working state.
2. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
3. I checked the status of my repository and verified it was still linear and all the bookmarks pointed to the proper commits.
4. I ran `hg log -r bookmark3 --template {desc}` to view the full commit message and verified it contained both `Summary: ...` and `Differential Revision: https://...`.
5. I ran `hg diff -c bookmar3` and verified the changes for that commit included the changes I made in step 1.
With evolve:
1. I enabled `evolve` and verified it was enabled by running `hg debugextensions` and saw `evolve` in the listed active extensions.
2. I updated to `bookmark2` and modified a file to leave a dirty working state.
3. I ran `arc diff` and when prompted to amend my changes I said "yes", and verified a phab revision was created properly.
4. I checked the status of my repository and verified it was still linear and all the bookmarks pointed to the proper commits.
5. I ran `hg log -r bookmark2 --template {desc}` to view the full commit message and verfieid it contained both `Summary: ...` and `Differential Revision: https://...`.
6. I ran `hg diff -c bookmark2` and verified the changes for that commit included the changes I made in step 2.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D21686
Summary:
Refs T13546
**Behavior Changes**
1. Currently, after landing the `--onto` bookmark will not be advanced to the newly pushed commit(s)
- This updates so that after pushing commits upstream, onto-marker bookmarks are pulled back from the server to retrieve their updated state
2. Currently, after landing the working directory will typically be the old `--onto` commit
- This updates the behavior in the following ways
1. If the starting working state is a commit that is part of a revision being landed, the post-land state will be the newly published commit for that revision
2. If the starting working state is a commit for a tip revision being landed and there is only a single `--onto` target, the post-land state will be the newly published commit and the `--onto` bookmark will be activated, if applicable. If there are multiple `--onto` targets defined (uncommon) then the resulting working state will be the same behavior as before, as the desired behavior for this case is ambiguous.
3. If the starting working state is a commit that is not part of any revision being landed, then the post-land state will be that same commit, activating the same previous bookmark if applicable.
**Bugs Fixed**
1. When landing a diff that includes multiple commits, where the non-tip commit adds a file and later commit modifies that file, the land process would fail during rebasing.
2. When landing, the display of what commits are going to be landed only includes the commit hash but should include part of the commit message for easy identification.
3. If errors occur during a rebase while landing, the resulting state is an in-progress rebase. Users will typically not be able to resolve this in-progress rebase and possibly confuse them further as they have to first abort the rebase before trying to clean up. These rebases will now be aborted by arcanist before exiting.
4. If using evolve, landing a non-tip revision would leave behind orphaned commits.
Test Plan:
Bookmark test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to activate `test`
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Non-bookmark test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to be the new commit, but not activate `test` even though it points to that same commit
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Not-working state test
- I created a diff with bookmark `test`, as a branch from before the `master` commit
- I updated working state to an older commit not related to the one being landed
- I landed that diff
- I verified the ending resulting working state was on the older commit I was on prior to landing
Multiple commits test
- Using `test` bookmark I created a commit that added a new file, made a diff, made another new commit on top of it which modified that file, then updated the diff
- I updated my working state to the first commit for the diff (non-head)
- I ran `arc land test` to land the diff
- I verified that the resulting working state was on the newly published `master` commit
Landing while on `master`
- I created a diff with a bookmark `test`, as a branch from before the `master` commit
- I updated working state to the `master` bookmark
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit
Landing with no local `master` bookmark
- I created a diff consisting of two commits with bookmark `test`, as a branch from before the `master` commit
- I left working state on `test` and deleted my local `master` bookmark
- I landed that diff
- I verified that the resulting working state was on the newly published `master` commit and the `master` bookmark was pulled and active
Cascading diffs while on an earlier diff changeset
- I setup two diffs, each consisting of two commits, one depending on the other
- I put the working state onto a commit from the earlier diff
- I landed the later diff
- I verified that the resulting working state was on the newly published commit associated with the earlier diff, which is not the new `master` commit so there was no active bookmark
Cascading diffs while on the later diff changeset
- I setup two diffs, each consisting of two commits, one depending on the other
- I put the working state into a commit from the later diff
- I landed the later diff
- I verified that the resulting working state was on the newly published commit for the later diff which was `master` and `master` was active
Landing a non-tip revision, with evolve
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I verified I had the evolve extension enabled via `hg debugextensions`
- I put the working state on a commit in the first revision
- I landed the second revision
- I verified that the resulting working state was clean, that revisions 1 and 2 were properly landed and published, and the resulting working state was on the published commit for the first revision.
Landing a non-tip revision, without evolve
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I verified I did not have the evolve extension enabled via `hg debugextensions`
- I put the working state on a commit in the first revision
- I landed the second revision
- I verified that the resulting working state was clean, that revisions 1 and 2 were properly landed and published, and the resulting working state was on the published commit for the first revision.
Landing a non-tip revision, while the non-landing revision is active
- I setup three diffs, each consisting of two commits, creating a dependency chain
- I put the working state on the latest tip revision commit and its bookmark
- I landed the second revision
- I verified that revisions 1 and 2 were properly landed and published, and the resulting working state was still on the latest tip revision commit and its bookmark was active.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21680
Summary:
When non-ascii characters appear in revision titles/summaries the `patch` and `diff` (to update) commands will fail on Windows systems. This often occurs due to “smart quotes” or "em—dash" characters being inserted into commit messages by editors on "user-friendly" operating systems like macOS.
This can be worked around by forcing all mercurial commands to use the global option `--encoding utf-8` which applies for any mercurial command. This option was [[ https://www.mercurial-scm.org/repo/hg/rev/a88e02081a88 | added in ~2006 ]] so this should work across all supported versions of mercurial.
Refs T13649
Test Plan:
I created a diff on a mercurial repository using smart quotes in the "Title" and "Summary" fields as well as in the content of a file being changed. Then on macOS, Windows (PowerShell), and Windows (cmd.exe) I was able to `patch` down the revision, make a modification, and `diff` the change back up to Phabricator, as well as `land` the change. I verified the commit and content looked correct on macOS as well as on Windows by using `nvim` which seems to properly detect and render the encoding, whereas mercurial displays the smart quotes and em-dashes with odd characters instead.
I did a grep through Arcanist codebase to find other places where `--encoding` might be specified for mercurial commands and could not find any. In the event that somehow this argument is added elsewhere I verified that multiple specifications of `--encoding utf-8` does not cause any issues and the later specification of `--encoding` appears to "win".
```lang=console
$ hg --encoding utf-8 --encoding utf-8 log -r tip
# prints out results in UTF-8 without issue
$ hg --encoding utf-8 log --encoding latin-1 -r tip
# prints out results in latin-1 without issue
```
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin
Maniphest Tasks: T13649
Differential Revision: https://secure.phabricator.com/D21676
Summary: Ref T13589. See that task for discussion.
Test Plan:
- Created this diff, ran most commands in isolation.
- This change is difficult to test extensively.
Maniphest Tasks: T13589
Differential Revision: https://secure.phabricator.com/D21509
Summary:
Ref T13577. After the lint rule fix in D21453, it can identify more errors. Fix the errors it identifies in "arcanist/".
These all seem fairly obscure/benign.
Test Plan: Ran `arc lint` on the files before and after these changes. Did not specifically re-test these particular messages, but they mostly very obscure.
Maniphest Tasks: T13577
Differential Revision: https://secure.phabricator.com/D21456
Summary:
Ref T13555. Currently:
- If an exception is raised in "start()", the exception state is not set on the future.
- Futures do not always call "startFuture()" before starting, and do not always call "endFuture()" once they become resolvable.
- If you start an ExecFuture which immediately fails and then call "getPID()" on it, you get an unclear exception.
Simplify these behaviors:
- In FutureIterator, only start futures which have not already started.
- When starting a future on any pathway, run start code.
- When a future becomes resolvable on any pathway, run end code.
- Raise a more clear exception when calling "getPID()" on a future with no subprocess.
Test Plan: Faked a failing subprocess with "$proc = null", ran "bin/phd debug taskmaster" etc. Got clearer errors and more consistent future lifecycle workflows.
Maniphest Tasks: T13555
Differential Revision: https://secure.phabricator.com/D21423
Summary:
Ref PHI1808. In Mercurial, we must save and restore bookmark state explicitly.
- Save and restore bookmarks.
- Clean up concepts in "arc-ls-markers" slightly, so we don't need separate "isCurrent" and "isActive" flags, hopefully.
I believe the totality of Mercurial state is:
- A (non-bare) working copy points at exactly one commit (which might be the empty/null commit, in an empty repository).
- A working copy has exactly one active branch.
- Each branch has zero or more heads.
- Each head may be closed.
- Each (non-null) commit belongs to exactly one branch.
- Note that the active branch may have zero heads and zero commits which belong to it!
- A working copy has zero or one active bookmark.
To capture this, we now emit:
- A list of branch heads. If a branch head is a working copy commit, that head is flagged as active.
- A list of bookmarks. If a bookmark is the current bookmark, that bookmark is flagged as active.
- A single "branch-state" virtual marker. This covers the case where you have run "hg branch X" to create X, but no objects in the working copy actually correspond to X yet. It also covers the case where you are on a concrete branch, but not any head of that branch.
- A single "commit-state" virtual marker. This always shows the current commit in the working copy.
Test Plan:
- Useful states to test are:
- Empty repository (not all commands currently work here).
- Normal repository, on a bookmark.
- Normal repository, no bookmark.
- "hg up 123" to update to somewhere in history.
- "hg branch X", to start a new branch with no commits.
- Ran "arc branches" and "arc bookmarks" in various states. Saw generally sensible output.
- Ran "arc land --hold ..." in various states against a failing remote. Saw generally sensible output, and saw working properly restored to the original state.
Differential Revision: https://secure.phabricator.com/D21396
Summary: See PHI1805. This call is constructed improperly and can lead to a fatal in `arc patch` under Mercurial.
Test Plan: In Mercurial, ran a valid `arc patch` operation.
Differential Revision: https://secure.phabricator.com/D21391
Summary:
Ref T13546. Try using unicode box drawing characters to render a more obvious tree struture in "arc branches".
Unclear if this has enough support to use, but seems okay so far.
Test Plan: Ran "arc branches", saw a nicer tree display.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21390
Summary: Ref T13546. Fixes some issues where marker selection in Mercurial didn't work, and selects "draft()" as the set of commits to show, which is at least somewhat reasonable.
Test Plan: Ran "arc branches" and "arc bookmarks" in Mercurial, got more reasonable output.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21380
Summary: Ref T13546. Allow the commit graph to be queried by date range, and Git to be queried for multiple disjoint commits.
Test Plan: Ran "arc branches" and future code which searches for alternate commit ranges for revisions.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21379
Summary: Ref T13546. If your history includes a long linear sequence of published revisions, summarize them.
Test Plan: Ran "arc branches", saw better summarization of linear published revision sequences.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21367
Summary: Ref T13546. In cases where a given set has a large number of commits, summarize them in the output.
Test Plan: Ran "arc branches", saw long lists of commits (like the history of "stable" summarized).
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21366
Summary: Ref T13546. Make "arc branches" use a flexible grid width and try to match the content to the display width in a reasonable way.
Test Plan: Ran "arc branches" at various terminal widths, got generally sensible output.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21365
Summary: Ref T13546. This is no longer necessary after the introduction of "msortv_natural()", which can handle natural string sorting.
Test Plan: Ran "arc branches", saw the same sorting applied.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21364
Summary:
Ref T13546. Currently, each "land" workflow executes custom graph queries to find commits: move toward abstracting this logic.
The "land" workflow also has a potentially dangerous behavior: if you have "master > A > B > C" and "arc land C", it will land A, B, and C. However, an updated version of A or B may exist elsewhere in the working copy. If it does, "arc land" will incorrectly land an out-of-date set of changes.
To find newer versions of "A" and "B", we need to search backwards from all local markers to the nearest outgoing marker, then compare the sets of changes we find to the sets of changes selected by "arc land".
This is also roughly the workflow that "arc branches", etc., need to show local markers as a tree, and starting in "arc branches" allows the process to be visualized.
As implemented here ,this rendering is still somewhat rough, and the selection of "outgoing markers" isn't good. In Mercurial, we may plausibly be able to use phase markers, but in Git we likely can't guess the right behavior automatically and probably need additional configuration.
Test Plan: Ran "arc branches" and "arc bookmarks" in Git and Mercurial.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21363
Summary:
Ref T13546. When running "arc branches", we want to show all unpublished commits. This is often a different set of commits than "commits not present in any remote".
Attempt to identify published commits by using the permanent ref rules in Phabricator.
Test Plan: Ran "arc look published", saw sensible published commits in Git.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21378
Summary:
Ref T13546. Query and associate known Phabricator repositories to working copy remotes by normalizing and comparing URIs.
This primarily gives us access to "permanentRefRules" so we can tell which branches have published changes.
Test Plan: Ran "arc look remotes" in Git and Mercurial working copies, saw repositories map properly.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21377
Summary:
Ref T13546. Currently, "arc which" provides some amount of inspection but it generally isn't very helpful to users and is too limited and inflexible. "arc inspect" is an internal/debugging workflow.
The new "arc look" is much more aggressively unhelpful.
Test Plan: I'm not sure if this command should allow you to continue at night, because it's too dark.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21376
Summary: Ref T13546. Allow construction of remote refs in Git; previously they were only supported in Mercurial.
Test Plan: Ran "arc inspect remote(origin)" in Git, got a ref.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21375
Summary: Ref T13546. Expose remote refs for inspection via "arc inspect". For now, this only works in Mercurial.
Test Plan: Ran "arc inspect remote(default)" in Mercurial, got a ref out.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21374
Summary: Ref T13546. Move toward smarter remote repository lookup by providing URI normalization code in Arcanist. This diff duplicates code from Phabricator; the next change will collapse it.
Test Plan: Ran unit tests.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21372
Summary: Ref T13546. If "arc land" would create a branch, warn the user before it does.
Test Plan: Ran "arc land --onto mtarse", a typo of "master".
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21354
Summary: Ref T13546. All of LandEngine, LocalState, and RepositoryAPI implement "getDisplayHash()". Always use the RepositoryAPI implementation.
Test Plan: Grepped for symbols.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21353
Summary:
Ref T13546. Show ongoing and failed builds more clearly in "arc land" output.
Also rename "DisplayRef" (which is not a "Ref") to "RefView" with the goal of improving clarity, and let callers "build...()" it so they can add more status, etc., information.
Get rid of "[DisplayRef|RefView]Interface". In theory, future refs (say, in Phabricator) might not do anything here, but every Ref just ends up implementing it. This could perhaps be subclassed more narrowly in the future if necessary.
Test Plan: Ran "arc land", grepped for various symbols.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21352
Summary:
Ref T13546. Ref T9948.
- Make "--hold" show the same set of commands to manually push that the normal workflow would use.
- Make save/restore state work.
- Make bookmark creation prompt for confirmation.
- Improve / provide some additional warnings and help text.
Test Plan: Ran various increasingly complex "arc land" workflows, e.g. "arc land --hold --onto fauxmark1 --onto fauxmark2 --into default . --revision 118 --trace"
Maniphest Tasks: T13546, T9948
Differential Revision: https://secure.phabricator.com/D21351
Summary: Ref T9948. Ref T13546. Clean up some minor behaviors to allow "arc land" to function in the simplest cases again. Also, do a capability test for "prune" rather than just falling back.
Test Plan: Ran "arc land <mark>" in Mercurial, got changes pushed.
Maniphest Tasks: T13546, T9948
Differential Revision: https://secure.phabricator.com/D21350
Summary:
Ref T9948. Ref T13546. This change moves toward a functional "arc land" in Mercurial.
Because of how "bundlerepo.getremotechanges()" works, "hg arc-ls-markers" does not actually list markers in the remote that aren't different from local markers so it's hard to get anywhere with this.
Test Plan: Got somewhat-encouraging output from "arc land" and "hg arc-ls-markers", but too many things are still broken for this to really work yet.
Maniphest Tasks: T13546, T9948
Differential Revision: https://secure.phabricator.com/D21348
Summary: Ref T13546. Ref T9948. It seems challenging to examine a remote in vanilla Mercurial. Provide an "hg arc-ls-remote" command which functions like "git ls-remote" so we can figure out if "--into X" is a bookmark, branch, both, neither, or a branch with multiple heads without mutating the working copy as a side effect.
Test Plan: Ran various "arc land --into ..." commands in a Mercurial working copy, saw apparently-sensible resolution of remote marker names.
Maniphest Tasks: T13546, T9948
Differential Revision: https://secure.phabricator.com/D21343
Summary: Ref T13546. Parse "hg paths" and validate that the remotes "arc land" plans to interact with actually exist.
Test Plan: Ran "arc land" with good and bad "--into-remote" and "--onto-remote" arguments, got sensible validation behavior.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21342
Summary: Ref T13546. Moves away from the older workflows in favor of "arc branches", "arc bookmarks", and "arc work".
Test Plan: Grepped for affected symbols, didn't find any callers.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21337
Summary: Ref T13546. Fixes T2928. Adds a new "arc work" workflow which functions like the older "arc feature" workflow, but with modern infrastructure.
Test Plan: Used "arc work" to begin work on branches, bookmarks, and revisions in Git and Mercurial.
Maniphest Tasks: T13546, T2928
Differential Revision: https://secure.phabricator.com/D21336
Summary: Ref T13546. Update the Mercurial code which finds default targets and maps symbols to targets under "arc land" to use the new MarkerRef workflow.
Test Plan: Ran "arc land" with (and without) various arguments in Mercurial, saw them resolve in a seemingly sensible way.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21335
Summary:
Ref T13546. Various Arcanist workflows, and particularly the MercurialAPI, currently repeat quite a lot of code around parsing branches and bookmarks.
In modern Mercurial, we can generally use the "head()" and "bookmark()" revsets to do this fairly sensibly.
This change mostly adds //more// code (and introduces "arc bookmarks" and "arc branches" as replacements for "arc bookmark" and "arc branch") but followups should be able to mostly delete code.
Test Plan: Ran "arc branches" and "arc bookmarks" in Git and Mercurial.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21333
Summary: Ref T13546. The minimum required Mercurial version should now always have these features; if not, they should move to more modern feature tests.
Test Plan: Grepped for affected symbols.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21334
Summary:
Fixes T13380. Ref T13546. Use slightly nicer command formatting for passthru commands, to make it more obvious what's going on and which pieces of output are from "arc" vs various subcommands.
Also, execute repository API passthru commands from the working copy root. All other commands already did this, the older API just didn't support it.
Test Plan: Ran "arc land" in Git and Mercurial repositories, saw nicer output formatting.
Maniphest Tasks: T13546, T13380
Differential Revision: https://secure.phabricator.com/D21330
Summary: Ref T13546. Implement the equivalents of "git stash" in Mercurial.
Test Plan: Dirtied a working copy in Mercurial, ran "arc land", saw dirty changes survive the process.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21329
Summary: Ref T13546. Update some of the "arc land --hold" behavior to be more functional/consistent with the updated workflow.
Test Plan: Ran "arc land --hold" under various conditions, got sensible forward/restore instructions.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21328
Summary:
Fixes T12876. Ref T13546. When you make the first change in a new Git repository, "arc land" currently can not merge it because there's nothing to merge into.
Support merging into the empty state formally, reachable by using "--into-empty" (which should be uncommon) or "arc land" in an empty repository.
Test Plan:
- Used "arc land --into-empty --hold ..." to generate merges against the empty state under "squash" and "merge" strategies in Git.
- Got sensible result commits with appropriate parents and content.
Maniphest Tasks: T13546, T12876
Differential Revision: https://secure.phabricator.com/D21324
Summary: Ref T13546. This has a lot of dangerously rough edges, but has managed to land at least one commit in each Git and Mercurial.
Test Plan:
- Landed one commit under ideal conditions in Git and Mercurial.
- See followups.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21315
Summary:
Ref T13546. Introduces a more structured construct for saving and restoring local repository state.
This is similar to old behavior, except that:
- "arc.autostash" is no longer respected;
- untracked changes are stashed; and
- we do not offer to amend.
Test Plan: In future changes, saved and restored various permutations of local state.
Maniphest Tasks: T13546
Differential Revision: https://secure.phabricator.com/D21314
Summary:
See D21190. The ".gitattributes" approach fails when ".gitattributes" is in a subdirectory (or global). These are probably unusual cases, but at least one is known in the wild.
Instead:
- Restore the ":(attr:filter=lfs)" test, which seems to be the fastest accurate test available in modern Git.
- If the test fails, assume the repository is not LFS. This only impacts users running very old versions of Git.
Test Plan:
- In LFS and non-LFS repositories, created diffs. Saw correct detection again.
- Broke the command on purpose, saw LFS detection conclude "no LFS", but not fail disastrously.
Subscribers: ptarjan
Differential Revision: https://secure.phabricator.com/D21192
Summary:
See PHI1718. See also <https://discourse.phabricator-community.org/t/arc-diff-fails-due-to-git-cmd-fails/3680/>.
Currently, `arc diff` detects Git LFS with `git ls-files -z -- ':(attr:filter=lfs)'` magic. This is an accurate test, but does not work on older Git.
Try a simpler, dumber test and see if that will work. If this also has issues, we can try this stuff:
- do version detection;
- pipe the whole tree to `git check-attr`;
- try a command like `git lfs ls-files` instead, which is probably a wrapper on one of these other commands.
Test Plan:
- In a non-LFS repository, ran "arc diff" and saw the repository detect as non-LFS.
- In an LFS repository, ran "arc diff" and saw the repository detect as LFS.
Differential Revision: https://secure.phabricator.com/D21190
