Change Details

See PHI416. Is lint [cache] "granularity" now completely unused? See PHI410. An install would like some things which probably start with better `arc cascade` support (T3875) in the upstream before they get real upstream support. See PHI102. An install would like the output from `arc unit` to be generally better. See PHI84. See T12996. An install would like better performance from `arc diff`. See PHI45. An install would like `arc land` in Mercurial to do a better job of cleaning up commits with the `evolve` extension enabled. See T11429. Much of this is still relevant. A major plan is T5055 (package management). See PHI481. This is a multifaceted request which largely overlaps with other existing requests (better tools for distributing extensions, customizing workflows, etc). See PHI582. `arc diff` currently prompts users to mark diffs with more than 4MB of text changes as "binary". Although we probably can not remove this limit entirely (if you add a 20GB text SQL dump to a repository, we can't reasonably ship it over normal JSON Conduit calls or show it in the web UI) it could be much higher than it currently is. More importantly, the UI and workflows should clearly distinguish between "enormous file" and "binary file". See PHI64. See T784. Changeset annotations, principally `@generated`, should become more flexible. See PHI644. See T3271. At least one install would find this "Waiting on Editor" prompt useful. See PHI644. The delay between `arc diff` and the `$EDITOR` prompt for update messages is potentially long enough to get up from your desk in large repositories. It would be nice to push more interactive prompts to the top and/or provide flags to reduce prompts. See PHI694. An install would like support for custom configuration properties in configuration-driven unit engines, similar to the existing support in configuration-driven lint engines. See PHI709. An install would like `arc` to retry network operations, e.g. after losing WiFi connectivity at a coffee shop. Although this is difficult in the general case because it's hard to prevent double writes and recover from successful writes where we lost the acknowledgement, we could likely retry `*.search` calls automatically. See PHI858. The current algorithm for removing instructional comments can remove too much in the case of: ``` Subscribers: #projectname ``` `arc` or `phage` should be more helpful. `arc --help` should work like `arc help`. `arc quack` should be more helpful (not `arc quack` specifically, but `arc <some invalid command>`). Perhaps `arc quack` should also be more useful, this is a pretty good command. Some configuration options, like `repository.callsign` and `http.basicauth.user`, only make meaningful sense to provide below a particular scope. For example, `arc set-config http.basicauth.user ...` should likely tell the user to run `arc set-config --local http.basicauth.user ...` instead. --- // Followup // See PHI705. An install would explicitly like `arc set-config ...` to be modular. See PHI403. An install would like to provide some `arc`-adjacent workflows through a different named binary, e.g. `thaumaturgist undiff`. In the upstream, we already effectively do this with `phage`. I think this is generally reasonable and should be formalized/supported. --- // Resolved // Once `--config x=y` is actually read, we should be explicit about when `x=true` means `true` and when it means `"true"`. There's //some// support for this already. This may happen naturally as a result of general `config` rewrites.

See PHI416. Is lint [cache] "granularity" now completely unused? See PHI410. An install would like some things which probably start with better `arc cascade` support (T3875) in the upstream before they get real upstream support. See PHI102. An install would like the output from `arc unit` to be generally better. See PHI84. See T12996. An install would like better performance from `arc diff`. See PHI45. An install would like `arc land` in Mercurial to do a better job of cleaning up commits with the `evolve` extension enabled. See T11429. Much of this is still relevant. A major plan is T5055 (package management). See PHI481. This is a multifaceted request which largely overlaps with other existing requests (better tools for distributing extensions, customizing workflows, etc). See PHI582. `arc diff` currently prompts users to mark diffs with more than 4MB of text changes as "binary". Although we probably can not remove this limit entirely (if you add a 20GB text SQL dump to a repository, we can't reasonably ship it over normal JSON Conduit calls or show it in the web UI) it could be much higher than it currently is. More importantly, the UI and workflows should clearly distinguish between "enormous file" and "binary file". See PHI64. See T784. Changeset annotations, principally `@generated`, should become more flexible. See PHI644. See T3271. At least one install would find this "Waiting on Editor" prompt useful. See PHI644. The delay between `arc diff` and the `$EDITOR` prompt for update messages is potentially long enough to get up from your desk in large repositories. It would be nice to push more interactive prompts to the top and/or provide flags to reduce prompts. See PHI694. An install would like support for custom configuration properties in configuration-driven unit engines, similar to the existing support in configuration-driven lint engines. See PHI709. An install would like `arc` to retry network operations, e.g. after losing WiFi connectivity at a coffee shop. Although this is difficult in the general case because it's hard to prevent double writes and recover from successful writes where we lost the acknowledgement, we could likely retry `*.search` calls automatically. See PHI858. The current algorithm for removing instructional comments can remove too much in the case of: ``` Subscribers: #projectname ``` `arc` or `phage` should be more helpful. `arc --help` should work like `arc help`. `arc quack` should be more helpful (not `arc quack` specifically, but `arc <some invalid command>`). Perhaps `arc quack` should also be more useful, this is a pretty good command. Some configuration options, like `repository.callsign` and `http.basicauth.user`, only make meaningful sense to provide below a particular scope. For example, `arc set-config http.basicauth.user ...` should likely tell the user to run `arc set-config --local http.basicauth.user ...` instead. From D19697, some code could be cleaned up by moving the "pure JSON list" test to a `phutil_is_natural_list()` function or similar. From D19697, there's some sketchy line unwrapping magic around workflow help in Workflow. --- // Followup // See PHI705. An install would explicitly like `arc set-config ...` to be modular. See PHI403. An install would like to provide some `arc`-adjacent workflows through a different named binary, e.g. `thaumaturgist undiff`. In the upstream, we already effectively do this with `phage`. I think this is generally reasonable and should be formalized/supported. --- // Resolved // Once `--config x=y` is actually read, we should be explicit about when `x=true` means `true` and when it means `"true"`. There's //some// support for this already. This may happen naturally as a result of general `config` rewrites.

See PHI416. Is lint [cache] "granularity" now completely unused? See PHI410. An install would like some things which probably start with better `arc cascade` support (T3875) in the upstream before they get real upstream support. See PHI102. An install would like the output from `arc unit` to be generally better. See PHI84. See T12996. An install would like better performance from `arc diff`. See PHI45. An install would like `arc land` in Mercurial to do a better job of cleaning up commits with the `evolve` extension enabled. See T11429. Much of this is still relevant. A major plan is T5055 (package management). See PHI481. This is a multifaceted request which largely overlaps with other existing requests (better tools for distributing extensions, customizing workflows, etc). See PHI582. `arc diff` currently prompts users to mark diffs with more than 4MB of text changes as "binary". Although we probably can not remove this limit entirely (if you add a 20GB text SQL dump to a repository, we can't reasonably ship it over normal JSON Conduit calls or show it in the web UI) it could be much higher than it currently is. More importantly, the UI and workflows should clearly distinguish between "enormous file" and "binary file". See PHI64. See T784. Changeset annotations, principally `@generated`, should become more flexible. See PHI644. See T3271. At least one install would find this "Waiting on Editor" prompt useful. See PHI644. The delay between `arc diff` and the `$EDITOR` prompt for update messages is potentially long enough to get up from your desk in large repositories. It would be nice to push more interactive prompts to the top and/or provide flags to reduce prompts. See PHI694. An install would like support for custom configuration properties in configuration-driven unit engines, similar to the existing support in configuration-driven lint engines. See PHI709. An install would like `arc` to retry network operations, e.g. after losing WiFi connectivity at a coffee shop. Although this is difficult in the general case because it's hard to prevent double writes and recover from successful writes where we lost the acknowledgement, we could likely retry `*.search` calls automatically. See PHI858. The current algorithm for removing instructional comments can remove too much in the case of: ``` Subscribers: #projectname ``` `arc` or `phage` should be more helpful. `arc --help` should work like `arc help`. `arc quack` should be more helpful (not `arc quack` specifically, but `arc <some invalid command>`). Perhaps `arc quack` should also be more useful, this is a pretty good command. Some configuration options, like `repository.callsign` and `http.basicauth.user`, only make meaningful sense to provide below a particular scope. For example, `arc set-config http.basicauth.user ...` should likely tell the user to run `arc set-config --local http.basicauth.user ...` instead. From D19697, some code could be cleaned up by moving the "pure JSON list" test to a `phutil_is_natural_list()` function or similar. From D19697, there's some sketchy line unwrapping magic around workflow help in Workflow. --- // Followup // See PHI705. An install would explicitly like `arc set-config ...` to be modular. See PHI403. An install would like to provide some `arc`-adjacent workflows through a different named binary, e.g. `thaumaturgist undiff`. In the upstream, we already effectively do this with `phage`. I think this is generally reasonable and should be formalized/supported. --- // Resolved // Once `--config x=y` is actually read, we should be explicit about when `x=true` means `true` and when it means `"true"`. There's //some// support for this already. This may happen naturally as a result of general `config` rewrites.