1. 22 Jun, 2020 1 commit
  2. 25 Oct, 2019 1 commit
  3. 03 Sep, 2019 1 commit
  4. 29 Aug, 2019 1 commit
    • epriestley's avatar
      Provide a simple read-only maintenance mode for repositories · 3c26e384
      epriestley authored
      Summary:
      Ref T13393. While doing a shard migration in the Phacility cluster, we'd like to stop writes to the migrating repository. It's safe to continue serving reads.
      
      Add a simple maintenance mode for making repositories completely read-only during maintenance.
      
      Test Plan: Put a repository into read-only mode, tried to write via HTTP + SSH. Viewed web UI. Took it back out of maintenance mode.
      
      Maniphest Tasks: T13393
      
      Differential Revision: https://secure.phabricator.com/D20748
      3c26e384
  5. 12 Aug, 2019 1 commit
    • epriestley's avatar
      When many commits are discovered at once, import them at lower priority · 82cf97ad
      epriestley authored
      Summary:
      Ref T13369. See that task for discussion.
      
      When the discovery daemon finds more than 64 commits to import, demote the worker queue priority of the resulting tasks.
      
      Test Plan:
        - Pushed one commit, ran `bin/repository discover --verbose --trace ...`, saw commit import with "at normal priority" message and priority 2500 ("PRIORITY_COMMIT").
        - Pushed 3 commits, set threshold to 3, ran `bin/repository discover ...`, saw commist import with "at lower priority" message and priority 4000 ("PRIORITY_IMPORT").
      
      Maniphest Tasks: T13369
      
      Differential Revision: https://secure.phabricator.com/D20712
      82cf97ad
  6. 21 May, 2019 1 commit
  7. 25 Apr, 2019 1 commit
    • epriestley's avatar
      Merge the "Herald" and "Owners" daemon workers into a single "Publish" worker · c0a4d1de
      epriestley authored
      Summary:
      Depends on D20466. Ref T13277. Currently:
      
        - The "Owners" worker writes ownership relationships (e.g., commit X affects package Y, because it touches a path in package Y) -- these are just edges.
        - It also triggers audits.
        - Then it queues a "Herald" worker.
        - This formally publishes the commit and triggers Herald.
      
      These aren't really separate steps and can happen more easily in one shot. Merge them.
      
      Test Plan:
        - Ran `bin/repository reparse --publish` to republish various commits, got sensible behavior.
        - Grepped for "IMPORTED_OWNERS", "IMPORTED_HERALD", "--herald", "--owners", and "--force-local" flags.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20467
      c0a4d1de
  8. 24 Apr, 2019 2 commits
    • epriestley's avatar
      Remove nearly all remaining references to "Autoclose" · 8f43c773
      epriestley authored
      Summary:
      Depends on D20464. Ref T13277. Broadly:
      
        - Move all the "should publish X" and "why aren't we publishing X" stuff to a separate class (`PhabricatorRepositoryPublisher`).
        - Rename things to be more consistent with modern terminology ("Publish", "Permanent Refs").
      
      Test Plan:
      This could use some trial-by-fire on `secure`, but:
      
        - Grepped for all symbols.
        - Viewed various commits.
        - Reparsed commits.
        - Here's a commit with an explanation:
      
      {F6394569}
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20465
      8f43c773
    • epriestley's avatar
      Remove "--force-autoclose" from "bin/repository reparse" · 45b9859f
      epriestley authored
      Summary: Depends on D20463. Ref T13277. This flag was added some time before 2015 and I don't think I've ever used it. Just get rid of it.
      
      Test Plan: Grepped for `force-autoclose`, `forceAutoclose`, `AUTOCLOSE_FORCED`.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20464
      45b9859f
  9. 18 Apr, 2019 5 commits
    • epriestley's avatar
      Rename some internal "Autoclose" mentions to "Permanent Refs" · 6449a0ec
      epriestley authored
      Summary: Depends on D20428. Ref T13277.
      
      Test Plan: Grep / reading.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20432
      6449a0ec
    • epriestley's avatar
      Expose repository ref rules via "diffusion.repository.search" · aed755e1
      epriestley authored
      Summary:
      Depends on D20425. Ref T13277. See PHI1067. There's currently no way to retrieve branch/ref rules over the API, which makes some management operations against a large number of repositories difficult.
      
      Expose these rules to the API.
      
      Test Plan: Called `diffusion.repository.search`, got rules in the result set.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20426
      aed755e1
    • epriestley's avatar
      In repository settings, fold "Autoclose On/Off" into "Publishing On/Off" · ec9237fe
      epriestley authored
      Summary:
      Depends on D20423. Ref T13277. Repositories currently have separate toggles for "Autoclose" and "Publishing".
      
      Merge the "Autoclose" toggle into the "Publishing" toggle. I'm unaware of any valid use case for enabling one but not the other.
      
      (This doesn't fix all the documentation, yet.)
      
      Test Plan: Edited a repository, saw only one publishing option.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20424
      ec9237fe
    • epriestley's avatar
      Add "Fetch Rules" to observed Git repositories · e910c76e
      epriestley authored
      Summary:
      Depends on D20421. Ref T13277. I'd generally like to move away from "Track Only".
      
      Some of the use cases for "Track Only" (or adjacent to "Track Only") are better resolved with "Fetch Rules" -- basically, rules to fetch only some subset of refs from the observed remote.
      
      Add configurable "Fetch Rules" for Git repositories. For example, if you only want to fetch `master`, you can now speify:
      
      ```
      refs/heads/master
      ```
      
      If you only want to fetch branches and tags, you can use:
      
      ```
      refs/heads/*
      refs/tags/*
      ```
      
      In theory, this is slightly less powerful in the general case than "Track Only", but gives us better behavior in some cases (e.g., when the remote has 50K random temporary branches). In practice, I think this and a better "Autoclose Only" will let us move away from "Track Only", get default behavior which is better aligned with what users actually expect, and dodge all the "track tags/refs" questions.
      
      Test Plan: Configured repositories with "Fetch Refs" rules, used `bin/repository pull --verbose --trace ...` to run pulls, saw expected pull/fetch behavior.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277
      
      Differential Revision: https://secure.phabricator.com/D20422
      e910c76e
    • epriestley's avatar
      Do not publish/notify about commits which are not reachable from any "Autoclose" ref · 1cda1402
      epriestley authored
      Summary:
      Depends on D20418. Ref T13277. Fixes T11314.
      
      Currently, when you push commits to some arbitrary ref or tag (like `refs/pull/123` on GitHub, `refs/tags/phabricator/diff/123` on Phabricator, or `refs/changes/whatever` on Gerrit), we do not "autoclose" related objects. This means that we don't process `Ref T123` to create links to tasks, and don't process `Differential Revision: xyz` to close revisions.
      
      However, we //do// still publish these commits. "Publish" means: trigger audits, publish feed stories, and run Herald rules.
      
        - Stop publishing these commits.
        - In the UI, show these commits as "Not Permanent" with a note that they are "Not [on any permanent branch]."
      
      These commits will publish and autoclose if they ever become reachable from an "autoclose" ref (most commonly, if they are later merged to "master").
      
      Test Plan:
        - Pushed a commit to `refs/tags/quack`.
        - Before: got a feed story.
        - After: no feed story, UI shows commit as "Not Permanent".
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13277, T11314
      
      Differential Revision: https://secure.phabricator.com/D20419
      1cda1402
  10. 14 Feb, 2019 1 commit
  11. 01 Feb, 2019 1 commit
    • epriestley's avatar
      Allow "inactive" repositories to be read over SSH for cluster sync · f3e154eb
      epriestley authored
      Summary:
      Fixes T13192. See PHI1015. When you deactivate a repository, we currently stop serving it.
      
      This creates a problem for intracluster sync, since new nodes can't sync it. If nothing else, this means that if you "ship of theseus" your cluster and turn nodes over one at a time, you will eventually lose the entire repository. Since that's clearly a bad outcome, support sync.
      
      Test Plan:
      Testing this requires a "real" cluster, so I mostly used `secure`.
      
      I deactivated rGITTEST and ran this on `secure002`:
      
      ```
      ./bin/repository thaw --demote secure002.phacility.net --force GITTEST && ./bin/repository update GITTEST
      ```
      
      Before the patch, this failed:
      
      ```
      [2019-01-31 19:40:37] EXCEPTION: (CommandException) Command failed with error #128!
      COMMAND
      git fetch --prune -- 'ssh://172.30.0.64:22/diffusion/GITTEST/' '+refs/*:refs/*'
      
      STDOUT
      (empty)
      
      STDERR
      Warning: Permanently added '172.30.0.64' (RSA) to the list of known hosts.
      phabricator-ssh-exec: This repository ("rGITTEST") is not available over SSH.
      fatal: Could not read from remote repository.
      
      Please make sure you have the correct access rights
      and the repository exists.
      ```
      
      After applying (a similar patch to) this patch to `secure001`, the sync worked.
      
      I'll repeat this test with the actual patch once this deploys to `secure`.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13192
      
      Differential Revision: https://secure.phabricator.com/D20077
      f3e154eb
  12. 21 Jan, 2019 2 commits
    • epriestley's avatar
      When dirtying repository cluster routing caches after an Almanac edit,... · 881d79c1
      epriestley authored
      When dirtying repository cluster routing caches after an Almanac edit, discover linked bindings from devices
      
      Summary:
      See PHI1030. When you edit an Almanac object, we attempt to discover all the related objects so we can dirty the repository cluster routing cache: if you modify a Device or Service that's part of a clustered repository, we need to blow away our cached view of the layout.
      
      Currently, we don't correctly find linked Bindings when editing a Device, so we may miss Services which have keys that need to be disabled. Instead, discover these linked objects.
      
      See D17000 for the original implementation and more context.
      
      Test Plan:
        - Used `var_dump()` to dump out the discovered objects and dirtied cache keys.
        - Before change: editing a Service dirties repository routing keys (this is correct), but editing a Device does not.
        - After change: editing a Device now correctly dirties repository routing keys.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Differential Revision: https://secure.phabricator.com/D20003
      881d79c1
    • epriestley's avatar
      Provide a richer error when an intracluster request can not be satisfied by the target node · 0db29e62
      epriestley authored
      Summary: See PHI1030. When installs hit this error, provide more details about which node we ended up on and what's going on.
      
      Test Plan:
      ```
      $ git pull
      phabricator-ssh-exec: This repository request (for repository "spellbook") has been incorrectly routed to a cluster host (with device name "local.phacility.net", and hostname "orbital-3.local") which can not serve the request.
      
      The Almanac device address for the correct device may improperly point at this host, or the "device.id" configuration file on this host may be incorrect.
      
      Requests routed within the cluster by Phabricator are always expected to be sent to a node which can serve the request. To prevent loops, this request will not be proxied again.
      
      (This is a read request.)
      fatal: Could not read from remote repository.
      
      Please make sure you have the correct access rights
      and the repository exists.
      ```
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Differential Revision: https://secure.phabricator.com/D20002
      0db29e62
  13. 20 Dec, 2018 2 commits
    • epriestley's avatar
      Remove "getApplicationTransactionObject()" from ApplicationTransactionInterface · 11cf8f05
      epriestley authored
      Summary:
      Depends on D19919. Ref T11351. This method appeared in D8802 (note that "get...Object" was renamed to "get...Transaction" there, so this method was actually "new" even though a method of the same name had existed before).
      
      The goal at the time was to let Harbormaster post build results to Diffs and have them end up on Revisions, but this eventually got a better implementation (see below) where the Harbormaster-specific code can just specify a "publishable object" where build results should go.
      
      The new `get...Object` semantics ultimately broke some stuff, and the actual implementation in Differential was removed in D10911, so this method hasn't really served a purpose since December 2014. I think that broke the Harbormaster thing by accident and we just lived with it for a bit, then Harbormaster got some more work and D17139 introduced "publishable" objects which was a better approach. This was later refined by D19281.
      
      So: the original problem (sending build results to the right place) has a good solution now, this method hasn't done anything for 4 years, and it was probably a bad idea in the first place since it's pretty weird/surprising/fragile.
      
      Note that `Comment` objects still have an unrelated method with the same name. In that case, the method ties the `Comment` storage object to the related `Transaction` storage object.
      
      Test Plan: Grepped for `getApplicationTransactionObject`, verified that all remaining callsites are related to `Comment` objects.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T11351
      
      Differential Revision: https://secure.phabricator.com/D19920
      11cf8f05
    • epriestley's avatar
      Remove obsolete, no-op implementations of "willRenderTimeline()" · 937e88c3
      epriestley authored
      Summary:
      Depends on D19918. Ref T11351. In D19918, I removed all calls to this method. Now, remove all implementations.
      
      All of these implementations just `return $timeline`, only the three sites in D19918 did anything interesting.
      
      Test Plan: Used `grep willRenderTimeline` to find callsites, found none.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T11351
      
      Differential Revision: https://secure.phabricator.com/D19919
      937e88c3
  14. 10 Dec, 2018 2 commits
  15. 06 Dec, 2018 1 commit
  16. 28 Nov, 2018 2 commits
    • epriestley's avatar
      Add a "touched paths" limit to repositories, limiting the maximum number of... · 9bfe5585
      epriestley authored
      Add a "touched paths" limit to repositories, limiting the maximum number of paths any commit may touch
      
      Summary:
      Depends on D19831. Ref T13216. See PHI908. Allegedly, a user copied a large repository into itself and then pushed it. Great backup strategy, but it can create headaches for administrators.
      
      Allow a "maximum paths you can touch with one commit" limit to be configured, to make it harder for users to make this push this kind of commit by accident.
      
      If you actually intended to do this, you can work around this by breaking your commit into pieces (or temporarily removing the limit). This isn't a security/policy sort of option, it's just a guard against silly mistakes.
      
      Test Plan: Set limit to 2, tried to push 3 files, got rejected. Raised limit, pushed changes successfully.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13216
      
      Differential Revision: https://secure.phabricator.com/D19839
      9bfe5585
    • epriestley's avatar
      Make the repository "Filesize Limit" and "Clone/Fetch Timeout" configurable in the UI · c86c5749
      epriestley authored
      Summary: Depends on D19830. Ref T13216. See PHI908. See PHI750. See PHI885. Allow users to configure a filesize limit, and allow them to adjust the clone/fetch timeout.
      
      Test Plan:
      {F6021356}
      
        - Configured a filesize limit and pushed, hit it. Made the limit larger and pushed, change went through.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13216
      
      Differential Revision: https://secure.phabricator.com/D19831
      c86c5749
  17. 16 Nov, 2018 1 commit
    • epriestley's avatar
      Unify intracluster sync and Drydock working copy construction timeouts as a... · cb033673
      epriestley authored
      Unify intracluster sync and Drydock working copy construction timeouts as a repository "copy time limit"
      
      Summary:
      Depends on D19814. Ref T13216. See PHI885. For various eldritch reasons, `git fetch` can hang. Although we'd probably like to fix this with `git fetch --require-sustained-network-transfer-rate=512KB/5s` or similar, that flag doesn't exist and we don't have a reasonable way to build it.
      
      Short of that, move toward formalizing a repository "copy time limit": the longest amount of time anything may spend trying to make a copy of this repository.
      
      This grows out of the existing intracluster sync limit, which is effectively the same thing. Here, apply it to `git clone` and `git fetch` in Drydock working copy construction, too. A future change may make it configurable.
      
      Test Plan:
        - Set the limit to 0.001.
        - Tried to build and lease working copies, got sensible timeout errors (see D19815).
      
      ```
      <Activation Failed> Lease activation failed: [CommandException] Command killed by timeout after running for more than 0.001 seconds.
      COMMAND
      ssh '-o' 'LogLevel=quiet' '-o' 'StrictHostKeyChecking=no' '-o' 'UserKnownHostsFile=/dev/null' '-o' 'BatchMode=yes' -l '********' -p '2222' -i '********' '127.0.0.1' -- '(cd '\''/var/drydock/workingcopy-163/repo/spellbook/'\'' && git clean -d --force && git fetch && git reset --hard)'
      ```
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13216
      
      Differential Revision: https://secure.phabricator.com/D19816
      cb033673
  18. 17 Oct, 2018 1 commit
    • epriestley's avatar
      Try to route cluster writes to nodes which won't need to synchronize first · 51073b97
      epriestley authored
      Summary:
      Ref T13109. Ref T13202. See PHI905. See PHI889. When we receive a write to a repository cluster, we currently send it to a random writable node.
      
      Instead, we can prefer:
      
        - the node currently holding the write lock; or
        - any node which is already up to date.
      
      These should simply be better nodes to take writes in all cases. The write lock is global for the repository, so there's no scaling benefit to spreading writes across different nodes, and these particular nodes will be able to accept the write more quickly.
      
      Test Plan:
        - This is observable by using `fprintf(STDERR, "%s\n", ...)` in the logic, then running `git push`. I'd like to pull this routing logic out of `PhabricatorRepository` at some point, probably into a dedicated `ClusterURIQuery` sort of class, but that is a larger change.
        - Added some `fprintf(...)` stuff around which nodes were being selected.
        - Added a `sleep(10)` after grabbing the write lock.
        - In one window, pushed. Then pushed in a second window.
          - Saw the second window select the lock holder as the write target based on it currently holding the lock.
          - Without a concurrent push, saw pushes select up-to-date nodes based on their up-to-date-ness.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: joshuaspence, timhirsh
      
      Maniphest Tasks: T13202, T13109
      
      Differential Revision: https://secure.phabricator.com/D19734
      51073b97
  19. 11 May, 2018 1 commit
  20. 12 Apr, 2018 2 commits
    • epriestley's avatar
      Allow repository cluster bindings to be marked as not "writable", making them read-only · 6556536d
      epriestley authored
      Summary:
      Depends on D19356. Fixes T10883. Ref T13120.
      
        - Add a "writable" property to the bindings, defaulting to "true" with a nice dropdown.
        - When selecting hosts, allow callers to request a writable host.
        - If the caller wants a writable host, only return hosts if they're writable.
        - In SVN and Mercurial, we sometimes return only writable hosts when we //could// return read-only hosts, but figuring out if these request are read-only or read-write is currently tricky. Since these repositories can't really cluster yet, this shouldn't matter too much today.
      
      Test Plan:
        - Without any config changes, viewed repositories via web UI and pushed/pulled via SSH and HTTP.
        - Made all nodes in the cluster read-only by disabling "writable", pulled and hit the web UI (worked), tried to push via SSH and HTTP (got errors about read-only).
        - Put everything back, pulled and pushed.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13120, T10883
      
      Differential Revision: https://secure.phabricator.com/D19357
      6556536d
    • epriestley's avatar
      Give getAlmanacServiceURI() an "options" parameter to prepare for read-only devices · 7c7e6d55
      epriestley authored
      Summary:
      Depends on D19355. Ref T10883. Ref T13120. Rather than adding a million parameters here, wrap the selector-parameters in an `$options`.
      
      The next change adds a new "writable" option to support forcing selection of writable hosts.
      
      Test Plan: Pulled and pushed via HTTP and SSH, viewed repositories via Diffusion.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13120, T10883
      
      Differential Revision: https://secure.phabricator.com/D19356
      7c7e6d55
  21. 09 Apr, 2018 2 commits
    • epriestley's avatar
      Mostly make blame work with DocumentEngine · 09c6d42b
      epriestley authored
      Summary: Ref T13105. This needs refinement but blame sort of works again, now.
      
      Test Plan: Viewed files in Diffusion and Files; saw blame in Diffusion when viewing in source mode.
      
      Reviewers: mydeveloperday
      
      Reviewed By: mydeveloperday
      
      Maniphest Tasks: T13105
      
      Differential Revision: https://secure.phabricator.com/D19309
      09c6d42b
    • epriestley's avatar
      Move Diffusion browse rendering to DocumentEngine, breaking almost all features · 1fde4a94
      epriestley authored
      Summary:
      Ref T13105. This breaks about 9,000 features but moves Diffusion to DocumentEngine for rendering. See T13105 for a more complete list of all the broken stuff.
      
      But you can't bake a software without breaking all the features every time you make a change, right?
      
      Test Plan: Viewed various files in Diffusion, used DocumentEngine features like highlighting and rendering engine selection.
      
      Reviewers: mydeveloperday
      
      Reviewed By: mydeveloperday
      
      Subscribers: mydeveloperday
      
      Maniphest Tasks: T13105
      
      Differential Revision: https://secure.phabricator.com/D19302
      1fde4a94
  22. 04 Jan, 2018 1 commit
    • epriestley's avatar
      Prevent enormous changes from being pushed to repositoires by default · 53b25db9
      epriestley authored
      Summary:
      Fixes T13031. "Enormous" changes are basically changes which are too large to hold in memory, although the actual definition we use today is "more than 1GB of change text or `git diff` runs for more than 15 minutes".
      
      If an install configures a Herald content rule like "when content matches /XYZ/, do something" and then a user pushes a 30 GB source file, we can't put it into memory to `preg_match()` it. Currently, the way to handle this case is to write a separate Herald rule that rejects enormous changes. However, this isn't obvious and means the default behavior is unsafe.
      
      Make the default behavior safe by rejecting these changes with a message, similar to how we reject "dangerous" changes (which permanently delete or overwrite history) by default.
      
      Also, change a couple of UI strings from "Enormous" to "Very Large" to reduce ambiguity. See <https://discourse.phabricator-community.org/t/herald-enormous-check/822>.
      
      Test Plan: Changed the definition of "enormous" from 1GB to 1 byte. Pushed a change; got rejected. Allowed enormous changes, pushed, got rejected by a Herald rule. Disabled the Herald rule, pushed, got a clean push. Prevented enormous changes again. Grepped for "enormous" elsewhere in the UI.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: joshuaspence
      
      Maniphest Tasks: T13031
      
      Differential Revision: https://secure.phabricator.com/D18850
      53b25db9
  23. 18 Dec, 2017 1 commit
    • epriestley's avatar
      Move the Git LFS gate to dedicated (non-prototype) config · e34b4bbd
      epriestley authored
      Summary: See PHI131. Ref T7789. Although this probably isn't 100% complete, there don't seem to be any actual, known, practical blocking issues remaining (everything is either heresay or not reproducible).
      
      Test Plan: Tried to push LFS locally, got blocked with a helpful message. Enabled setting, tried to push LFS locally, got a successful push.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T7789
      
      Differential Revision: https://secure.phabricator.com/D18825
      e34b4bbd
  24. 09 Oct, 2017 1 commit
    • Dmitri Iouchtchenko's avatar
      Fix spelling · 9bd6a370
      Dmitri Iouchtchenko authored
      Summary: Noticed a couple of typos in the docs, and then things got out of hand.
      
      Test Plan:
        - Stared at the words until my eyes watered and the letters began to swim on the screen.
        - Consulted a dictionary.
      
      Reviewers: #blessed_reviewers, epriestley
      
      Reviewed By: #blessed_reviewers, epriestley
      
      Subscribers: epriestley, yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Differential Revision: https://secure.phabricator.com/D18693
      9bd6a370
  25. 07 Sep, 2017 1 commit
  26. 01 Aug, 2017 1 commit
  27. 11 Jul, 2017 1 commit
    • Chad Little's avatar
      Move Clone Repository to Dialog · a6b550ba
      Chad Little authored
      Summary: This moves the clone details on the Repository Home to a button / dialog. Functionally this is to pull content on the page way up, while giving full space to all the clone options. I think we can build this into some FancyJS if needed, but this seems to clean ui the UI dramatically with little overhead. I don't want to attempt the JS dropdown unless we're sure that's the best path (it exposes the most common URI by default, saving a click).
      
      Test Plan: Tested hg, svn, git repositories and the raw URL page. Test close button.
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: Korvin
      
      Differential Revision: https://secure.phabricator.com/D18203
      a6b550ba
  28. 19 Jun, 2017 1 commit
    • Chad Little's avatar
      Add a graph view page to Diffusion · d0898116
      Chad Little authored
      Summary: Fixes T12840. This adds a parallel "graph" button next to history on home and on the history list page. I'll think more about better placement of how to get to this page with the upcoming redesign that's still sitting in Pholio.
      
      Test Plan: View History, View Graph, Try pager, go to a file, click view history, see no graph button.
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: Korvin
      
      Maniphest Tasks: T12840
      
      Differential Revision: https://secure.phabricator.com/D18131
      d0898116
  29. 12 Jun, 2017 1 commit