Remove couple of references to callsigns:
- arc which now prints repository name
- getShouldAmend() can now use new format of commit name
a quick git-grep looks like the remaining references are all about repository.callsign config.
Ref T4245
Details
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Maniphest Tasks
- T4245: Make repository URIs slightly prettier
- Commits
- rARCf89f3de65805: (stable) Promote 2016 Week 12
rARC3d7ac867f538: Make callsigns optional in arcanist
- arc which on a repository with no callsign
- trigger requireCleanWorkingCopy(), see both "Do you want to amend this change" and "Do you want to create a new commit" prompts.
- fire this diff with new code.
Diff Detail
Diff Detail
- Repository
- rARC Arcanist
- Branch
- master
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 11154 Build 13829: Run Core Tests Build 13828: arc lint + arc unit
Event Timeline
| src/workflow/ArcanistWorkflow.php | ||
|---|---|---|
| 2029 | This is technically a backward compatibility break (the older looksoon method didn't have this parameter), but probably fine since looksoon is optional anyway. | |
| src/workflow/ArcanistWorkflow.php | ||
|---|---|---|
| 1699–1700 | Could we restore the protected getRepositoryCallsign() method? Without it, there doesn't appear to be a way for (custom) workflows to access the callsign value (because getRepositoryInformation() is private). The callsign is used by the [[ /conduit/method/owners.query/ | owners.query ]] conduit method, for example. (I know about [[ /conduit/method/owners.search/ | owners.search ]], which doesn't use the callsign, but that is still an unstable API.) | |
Comment Actions
Despite the status, owners.search is probably more stable than owners.query at this point. Is there any technical reason you can't switch to owners.search?
The deprecated/unstable statuses don't do a great job of describing the actual state of the world right now, although there's some value in not having 15 statuses. But the internal state is something like this:
- owners.query: Deprecated, just not marked as deprecated yet.
- *.search: Mostly stable, but possibly still subject to minor changes because the underlying infrastructure is so sweeping and not yet adopted everywhere. These changes are unlikely to break backward compatibility unless your API wrapper fails explicitly when new fields appear in the response, but it's possible that, say, the format for some common attachment like subscribers or something is goofy. If you use part of the API and it actually works properly, it's probably safe, I just didn't want to over-promise these as fully stable since I don't want to commit to a broken subscribers on 30 different *.search methods or whatever if it turns out I did something dumb or overlooked something.
I can properly mark owners.query deprecated, at least.
Comment Actions
I don't think there's anything blocking that transition, although I haven't attempted it yet. I'll give that a look later today.
Are there any other non-deprecated conduit APIs with callsign parameters? The main thing I wanted to flag here is this change breaks (or at least hurts) compatibility with them.
Comment Actions
I also made the "unstable" warnings a little better-aligned with reality in D15769 (less scary presentation, less absolute language).
Because callsigns are already optional, any method which relies on them was endangered previously by T4245: it's possible to create repositories today that methods like owners.query can not interact with. From inspection of conduit.query, I think this list of methods is:
- diffusion.getrecentcommitsbypath (possibly has zero callers in existence anywhere, not apparently called in the upstream)
- owners.query (here; obsoleted by owners.search)
- repository.create (planned obsoletion by diffusion.repository.create)
- repository.query (optional, planned obsoletion by diffusion.repository.search)
- differential.query (minor, planned eventual obsoletion by differential.revision.search).