2014-06-14 20:44:38 +02:00
|
|
|
# NOTE: Thinking about adding files created by your operating system, IDE,
|
|
|
|
|
# or text editor here? Don't! Add them to your per-user .gitignore instead.
|
|
|
|
|
|
|
|
|
|
# Diviner
|
2011-05-26 03:51:46 +02:00
|
|
|
/docs/
|
|
|
|
|
/.divinercache/
|
2014-06-14 20:44:38 +02:00
|
|
|
|
|
|
|
|
# libphutil
|
|
|
|
|
/src/.phutil_module_cache
|
Begin modernizing the Arcanist interaction with Conduit
Summary:
Ref T10895.
NOTE: I'm going to land this and other changes to a new `experimental` branch until `arc` is more substantially rebuilt, since everything I touch feels like it requires me to rebuild 30 other things first.
Currently, many `arc` workflows are unnecessarily slow because they call `conduit.connect` on startup. There's no need to do this with the modern way the API works, and we've generally moved away from explicit version testing to more granular capability testing on specific workflows.
Additionally, some workflows like `arc patch` are huge messes (see T11434) because they're trying to run in anonymous mode but it doesn't really work with all the upfront stuff Conduit does now. It's not possible, in the general case, for a workflow to know upfront if it needs Conduit or not.
And:
- `ArcanistWorkflow` has piles of Conduit logic, but should not.
- Pooling Conduit requests isn't very easy.
- There's a lot of general cruft around the workflow.
- We should drop certificate support.
This pulls out Conduit into a separate on-demand class with modern support, future pooling, less cruft, inline handling of login issues, and generally less garbage.
Also adds an `--anonymous` flag, mostly to make testing easier.
Test Plan: Ran `arc browse`, used `--anonymous` and `--trace`, fiddled with credentials, got approximatley the same behavior that mainline `arc` has.
Reviewers: chad, avivey
Reviewed By: avivey
Subscribers: avivey
Maniphest Tasks: T10895
Differential Revision: https://secure.phabricator.com/D16921
2016-11-23 00:55:18 +01:00
|
|
|
/src/.cache
|
2014-06-14 20:44:38 +02:00
|
|
|
|
|
|
|
|
# User extensions
|
2012-08-10 23:58:19 +02:00
|
|
|
/externals/includes/*
|
2014-06-14 20:44:38 +02:00
|
|
|
/src/extensions/*
|
[Wilds] Remove libphutil
Summary:
Ref T13098. Historically, Phabricator was split into three parts:
- Phabricator, the server.
- Arcanist, the client.
- libphutil, libraries shared between the client and server.
One imagined use case for this was that `libphutil` might become a general-purpose library that other projects would use.
However, this didn't really happen, and it seems unlikely to at this point: Phabricator has become a relatively more sophisticated application platform; we didn't end up seeing or encouraging much custom development; what custom development there is basically embraces all of Phabricator since there are huge advantages to doing so; and a general "open source is awful" sort of factor here in the sense that open source users often don't have goals well aligned to our goals.
Turning "arc" into a client platform and building package management solidify us in this direction of being a standalone platform, not a standalone utility library.
Phabricator also depends on `arcanist/`. If it didn't, there would be a small advantage to saying "shared code + client for client, shared code + server for server", but there's no such distinction and it seems unlikely that one will ever exist. Even if it did, I think this has little value.
Nowadays, I think this separation has no advantages for us and one significant cost: it makes installing `arcanist` more difficult for end-users.
This will need some more finesssing (Phabricator will need some changes for compatibility, and a lot of stuff that still says "libphutil" or "phutil" may eventually want to say "arcanist"), and some stuff (like xhpast) is probably straight-up broken right now and needs some tweaking, but I don't anticipate any major issues here. There was never anything particularly magical about libphutil as a separate standalone library.
Test Plan: Ran `arc`, it gets about as far as it did before.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13098
Differential Revision: https://secure.phabricator.com/D19688
2018-09-18 19:37:45 +02:00
|
|
|
|
|
|
|
|
# XHPAST
|
|
|
|
|
/support/xhpast/*.a
|
|
|
|
|
/support/xhpast/*.o
|
|
|
|
|
/support/xhpast/parser.yacc.output
|
|
|
|
|
/support/xhpast/node_names.hpp
|
|
|
|
|
/support/xhpast/xhpast
|
|
|
|
|
/src/parser/xhpast/bin/xhpast
|
|
|
|
|
|
|
|
|
|
## NOTE: Don't .gitignore these files! Even though they're build artifacts, we
|
|
|
|
|
## want to check them in so users can build xhpast without flex/bison.
|
|
|
|
|
# /support/xhpast/parser.yacc.cpp
|
|
|
|
|
# /support/xhpast/parser.yacc.hpp
|
|
|
|
|
# /support/xhpast/scanner.lex.cpp
|
|
|
|
|
# /support/xhpast/scanner.lex.hpp
|
|
|
|
|
|
|
|
|
|
# This is an OS X build artifact.
|
|
|
|
|
/support/xhpast/xhpast.dSYM
|
|
|
|
|
|
|
|
|
|
# This file overrides "default.pem" if present.
|
|
|
|
|
/resources/ssl/custom.pem
|
|
|
|
|
|
[Wilds] Update "arc shell-complete" for toolsets
Summary:
Ref T13098. Major changes:
`arc shell-complete` now installs itself to your `~/.profile`. Running `arc shell-complete` again will update the hook and update the completion rules.
Completion rules work for all toolsets, so you can install once and then autocomplete in `arc`, `phage`, etc.
This code supports other shells in theory, and I developed most of it with ZSH support next to the Bash support. However, while actually testing ZSH support, I couldn't get it to even slightly work and found myself falling down a very, very deep rabbit hole of ZSH being entirely written in bash script and `${0:a:h}` being a legitimate script construction. The existing ZSH support comes from one guy in 2012 and also does not work for me on `master`, so I ultimately removed it. Open to restoring it but I wasn't able to figure it out in 10 minutes of Googling and I'm not convinced it's worth 11 minutes of Googling.
I left a few rough edges here with notes on how to improve/fix them, but the basics all work.
Test Plan:
- Ran `arc shell-complete` under various stages of `~/.profile`, couldn't get it to do anything bad.
- Ran `arc lib<tab>`, `arc shell-complete --curr<tab>`, etc. Got sensible suggestions and completions.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13098
Differential Revision: https://secure.phabricator.com/D19700
2018-09-21 22:09:20 +02:00
|
|
|
# Generated shell completion rules.
|
|
|
|
|
/support/shell/rules/*
|
