1. 04 Nov, 2019 1 commit
  2. 29 Oct, 2019 1 commit
    • epriestley's avatar
      When generating diffs in "arc diff", disable Git config option "diff.suppressBlankEmpty" · cc1ff388
      epriestley authored
      Ref T13432. Git has a "diff.suppressBlankEmpty" config option which makes it emit nonstandard diffs with trimmed trailing whitespace on unchanged blank lines.
      Currently, we don't parse these diffs correctly. Even if we do in the future, emitting a more standard diff is desirable.
      Explicitly disable this option when executing "git diff" so we build more standard diffs.
      Test Plan:
        - Configured this option.
        - Modified a file with a blank line in it without changing the blank line, got this goofy display diff:
        - Applied patch, rediffed the same change, saw "-c diff.suppressBlankEmpty" in "--trace" output and got this sensible diff:
      Maniphest Tasks: T13432
      Differential Revision: https://secure.phabricator.com/D20877
  3. 28 Oct, 2019 5 commits
    • epriestley's avatar
      Make "arc land --merge" an explicit error when targeting a Perforce remote · 73943d1b
      epriestley authored
      Summary: Ref T13434. Since "git p4 submit" gets more complicated when submitting merges, and empty merges (as with "--no-ff") seem to vanish, and it's not clear this is desirable or useful anyway, just make the "merge" strategy an explicit error with Perforce remotes.
      Test Plan: Ran "arc land --merge ..." in a Git/Perforce repository, got an explicit error. Ran "arc land --squash ...", got existing working behavior.
      Maniphest Tasks: T13434
      Differential Revision: https://secure.phabricator.com/D20871
    • epriestley's avatar
      In "arc land", when "remote/onto" does not exist locally, try to fetch it before giving up · 7383c2f4
      epriestley authored
      Fixes T10650. It's valid to `arc land --remote origin --onto master` without first fetching that ref. If we can't find a local ref for a specified remote branch, try to fetch it before giving up.
      (In the long run, this should be valid even if the remote branch does not exist at all and the user intends to create it -- see T12876 -- but this is a step toward that.)
      Test Plan:
        - Ran `rm .git/refs/remotes/origin/master`, then landed into "master".
        - Before: "arc land" bailed out immediately.
        - After: "arc land" fetches the missing ref.
      $ arc land
       TARGET  Landing onto "master", the default target under git.
       REMOTE  Using remote "origin", the default remote under Git.
       TARGET  No local ref exists for branch "master" in remote "origin", attempting fetch...
       FETCHED  Fetched branch "master" from remote "origin".
      Maniphest Tasks: T10650
      Differential Revision: https://secure.phabricator.com/D20870
    • epriestley's avatar
      Update "arc help land" to reference Perforce support · a76054f8
      epriestley authored
      Summary: Fixes T12668. Ref T13434. This is far from exhasutive, but suggest that Perforce probably works.
      Test Plan: Read documentation.
      Maniphest Tasks: T13434, T12668
      Differential Revision: https://secure.phabricator.com/D20869
    • epriestley's avatar
      Support Perforce/Git repositories in "arc land" · ca667439
      epriestley authored
      Summary: Ref T13434. Detect perforce remotes and use "git p4" commands in place of "git" commands when operating in Perforce mode.
      Test Plan:
        - Landed "master" onto itself, saw master update.
        - Landed "feature1" onto clean "master", saw master update.
        - Landed "feature2" onto dirty "master", saw master stay dirty.
        - Landed with "--hold", got sensible submit instructions.
      Maniphest Tasks: T13434
      Differential Revision: https://secure.phabricator.com/D20868
    • epriestley's avatar
      Move Git-specific "arc land" parsing of "--onto" and "--remote" into GitLandEngine · 9c7bbb76
      epriestley authored
      Summary: Ref T13434. Move some git-engine-specific handling of "arc land" arguments into the Git engine. This prepares to handle Perforce workflows.
      Test Plan: Will "arc land" this change.
      Maniphest Tasks: T13434
      Differential Revision: https://secure.phabricator.com/D20867
  4. 26 Oct, 2019 1 commit
  5. 17 Oct, 2019 1 commit
  6. 09 Sep, 2019 1 commit
  7. 05 Sep, 2019 1 commit
    • epriestley's avatar
      When running "arc land" from a detached HEAD, don't try to delete the source ref · 3cdfe1ff
      epriestley authored
      Fixes T10321. Some reasonable but less-common workflows involve running `arc land` from a detached HEAD state.
      When users do this, we currently try to delete the raw hash as though it were a branch during cleanup. Instead, detect if the thing we're thinking about deleting is a branch or not, and just leave it alone if it isn't.
      Test Plan:
        - Ran `git checkout <some hash>`, then `arc land --revision <some revision>`.
        - Before, everything worked but cleanup tried to `git branch -D <some hash>`.
        - After, everything worked and cleanup skipped branch deletion.
      Maniphest Tasks: T10321
      Differential Revision: https://secure.phabricator.com/D20786
  8. 22 Jun, 2019 1 commit
  9. 20 Jun, 2019 2 commits
  10. 28 May, 2019 1 commit
  11. 23 May, 2019 1 commit
    • Asher Baker's avatar
      Fix arc land on odd/modern git-svn checkouts · 7329bc7c
      Asher Baker authored
      The current code assumes git-svn is always working from a remote called
      `trunk`, but if the repository is initialized without the `-T` option it
      will instead be called `git-svn`, and if `--prefix` is used (which is
      set by default to `origin/` in Git 2+) the remote name will have the
      specified prefix as well.
      Instead, look at the `fetch` target refspec set in the git-svn config.
      Fixes T13293.
      Test Plan:
      `arc land` without errors (or manually creating a `trunk` branch) from a
      checkout made with Git 2.18.0 (verified this manually on a non-`-T`
      checkout as well).
      Reviewers: epriestley, #blessed_reviewers
      Reviewed By: epriestley, #blessed_reviewers
      Subscribers: Korvin
      Maniphest Tasks: T13293
      Differential Revision: https://secure.phabricator.com/D19681
  12. 21 May, 2019 1 commit
    • Joshua Spence's avatar
      Modify the `lint-test` file format to allow for more powerful assertions · dd514e26
      Joshua Spence authored
      Fixes T6854. The current format for `lint-test` files is somewhat inflexible and does not allow us to make assertions regarding the code or name of the linter messages (of class `ArcanistLintMessage`) that are raised. Specifically, the `${severity}:${line}:${char}` format is hardcoded in `ArcanistLinterTestCase`. In this diff, I extend the this format to achieve the following goals:
      - Allow for the lint message code and name to be specified. Specifically, the full format is `${severity}:${line}:${char}:${code}:${name}`.
      - Make all fields optional. `error:3:` will match any and all errors occuring on line 3.
      - Provide more useful output when assertions fail. Specifically, output //all// lint messages that are missing and/or surplus. Previously, only the first lint message was output.
      Test Plan: `arc unit`
      Reviewers: #blessed_reviewers, epriestley, chad
      Reviewed By: #blessed_reviewers, epriestley
      Subscribers: Korvin, epriestley
      Maniphest Tasks: T6854
      Differential Revision: https://secure.phabricator.com/D11176
  13. 16 May, 2019 1 commit
  14. 15 May, 2019 1 commit
    • Wenzheng Jiang's avatar
      Let lint rules support anonymous classes · 82445bb6
      Wenzheng Jiang authored
      Summary: Ref T4334. Depends on D19740. Improve some lint rules so they can handle anonymous classes.
      Test Plan: Ran updated tests
      Reviewers: joshuaspence, #blessed_reviewers, epriestley
      Reviewed By: joshuaspence, #blessed_reviewers, epriestley
      Subscribers: Korvin, epriestley
      Maniphest Tasks: T4334
      Differential Revision: https://secure.phabricator.com/D19741
  15. 14 May, 2019 5 commits
  16. 08 Mar, 2019 1 commit
  17. 07 Mar, 2019 2 commits
    • epriestley's avatar
      Make minor correctness changes to some "arc patch" command execution · 9830c931
      epriestley authored
      Since I'm in here for PHI1083:
        - Add some "--" so we get correct behavior when you have a file named "master", a branch named "README.txt", etc.
        - Stop using "%C" unnecessarily.
        - Fix some untranslatable strings.
      Test Plan: Ran `arc patch` a couple of times, ran the variations of `git` commands to catch anything weird with "--" handling.
      Reviewers: amckinley
      Reviewed By: amckinley
      Differential Revision: https://secure.phabricator.com/D20254
    • epriestley's avatar
      Fix a case where "arc patch" could skip submodule changes · 73804f00
      epriestley authored
      See PHI1083. Previously, see PHI648 and D19475.
      When you apply a submodule patch in Git, it leaves you with a working copy that has the "submodule pointer" dirtied but the actual submodule untouched:
      $ git status
      On branch ...
      Changes to be committed:
        (use "git reset HEAD <file>..." to unstage)
      	modified:   philter
      Changes not staged for commit:
        (use "git add <file>..." to update what will be committed)
        (use "git checkout -- <file>..." to discard changes in working directory)
      	modified:   philter (new commits)
      So, if you're applying `D123` and `submodule/` was previously pointed at commit "A" but `D123` updates it to point at commit "B", you get this after `git apply ...`:
        - Git index says "submodule/ = B".
        - On disk, "submodule/ = A".
      Now, if you `git add --all` or `git commit --all`, git picks up the "change" on disk as an intended modification of the submodule. This puts the submodule back to "A" and overwrites/undoes the "pointer" update that's trying to make it point to "B".
      To avoid this, update submodules after applying the patch.
      Also, every time we modify the working copy, just update submodules.
      Test Plan:
        - Add a submodule in branch "B1", pointed at commit "A".
        - Branch to create branch "B2". Update the submodule to point at commit "B". Commit this and `arc diff` it.
        - Go back to "B1". Use `arc patch D...` to apply the revision you just created.
        - Before change:
          - "arc patch" applies the submodule change, so "pointer = B", "disk = A".
          - "arc patch" runs "git commit --all", which looks at disk and sets "pointer = A".
          - This isn't a change, so we fail with an empty commit.
        - After change:
          - "arc patch" applies the submodule change, so "pointer = B", "disk = A".
          - "arc patch" updates submodules, so "pointer = B", "disk = B".
          - "arc patch" runs "git commit --all", which now has a change, and commits "submodule = B".
      Reviewers: amckinley
      Reviewed By: amckinley
      Differential Revision: https://secure.phabricator.com/D20253
  18. 06 Mar, 2019 1 commit
    • epriestley's avatar
      Implement "Warn When Landing" behavior for Build Plans in Arcanist · f6b8480a
      epriestley authored
      Ref T13258. This makes "arc land" respect the new "Warn When Landing" behavior.
      This will only work if you have very up-to-date APIs. Just fall back to the older code if the new API calls fail.
      Test Plan: Ran `arc land` on a revision with builds in various states and with the different "Warn When Landing" behaviors. Saw appropriate warnings.
      Reviewers: amckinley
      Reviewed By: amckinley
      Maniphest Tasks: T13258
      Differential Revision: https://secure.phabricator.com/D20236
  19. 28 Feb, 2019 1 commit
    • epriestley's avatar
      Improve performance of "arc diff" updates for changes with large diff text · 96fde137
      epriestley authored
      See PHI1104. The older "differential.querydiffs" method includes the entire raw diff text for all the diffs associated with a revision in its response, but we: only care about the most recent diff; and don't care about the text at all.
      For reasonably large changes with several updates, this can be significantly slow.
      We can get this same information more efficiently from the modern "differential.diff.search", since D19386 (April 2018). The only trick is that we need a "revisionPHID", which we don't have on hand.
      For now, just fetch the revision PHID. In the future, we can likely make adjustments so that we have the revision PHID already by the time we get here.
      This may slow down the normal case very slightly (since we now do two calls instead of one), but it speeds up the bad cases dramatically.
      Test Plan:
      Ran `arc diff` to update a change in a local repository. `var_dump()`'d the old and new algorithm results, saw the same outcome.
      Used `arc diff --trace` on an update to a change to verify that `differential.diff.search` is called but `differential.querydiffs` is not.
      Reviewers: amckinley
      Reviewed By: amckinley
      Differential Revision: https://secure.phabricator.com/D20221
  20. 23 Feb, 2019 1 commit
  21. 19 Feb, 2019 1 commit
    • epriestley's avatar
      Add Arcanist support for highlighting indent change intraline diffs · 9581dd0f
      epriestley authored
      Ref T13161. See D20181. This allows the intraline highlighter to accept new ">" and "<" spans and apply a different style for them.
      The input pattern is `list<segment>`. Each segment is `pair<wild kind, int byte_length>`, i.e. wrap the next `byte_length` bytes in a span of kind `kind`.
      Before this change, the possible kinds of segements are `0` (no intraline diff, do not highlight) or `1` (intraline diff, highlight in bright color).
      D20181 adds `<` (depth decreased) and `>` (depth increased). These are like `1`, but add a different class so the UI can handle them differently.
      Test Plan: See D20181.
      Reviewers: amckinley
      Reviewed By: amckinley
      Maniphest Tasks: T13161
      Differential Revision: https://secure.phabricator.com/D20182
  22. 16 Feb, 2019 1 commit
  23. 15 Feb, 2019 1 commit
    • epriestley's avatar
      In "arc diff", warn when some reviewers are away even if not everyone is away · 07a208d8
      epriestley authored
      Ref T13249. See PHI810. We currently warn you when //all// reviewers are away, but not when only some reviewers are away.
      This makes some amount of sense under the "anyone can accept anything" rules we sort of recommend, but a lot of installs realistically have tons of owner/package rules now.
      Instead, if any reviewers are away, show the user exactly who is away and until when, then make sure they don't want to make any adjustments.
      (We can do a better job of this after the toolsets change when we can use the new APIs, but this is an easy fix for now.)
      Test Plan: Created a revision with multiple reviewers, either some or all of whom were away. Got appropriate output and prompt behavior.
      Reviewers: amckinley
      Reviewed By: amckinley
      Maniphest Tasks: T13249
      Differential Revision: https://secure.phabricator.com/D20172
  24. 12 Feb, 2019 1 commit
  25. 28 Dec, 2018 2 commits
  26. 15 Dec, 2018 1 commit
  27. 12 Dec, 2018 1 commit
  28. 12 Nov, 2018 1 commit
  29. 08 Nov, 2018 1 commit