* Use plural linking verb
While it looks like you could use "there's" informally, grammatically, it should be "are" since "commits" is plural.
<https://dictionary.cambridge.org/us/grammar/british-grammar/there-is-there-s-and-there-are>
* Omit "the"
I created a remote called "github" and got this prompt:
> Would you like to push commits from the current branch to the "github"?
Normally, the default name "origin" doesn't sound bad in that prompt,
but using the name "github" made the prompt sound like something wasn't
right to my American English-speaking ears.
Here are a few options. Yes, I know English grammar sucks, to put it
mildly. But, hopefully, the following options and explanations make
sense.
Get rid of "the". This is the option I went with. "github" acts as a
proper noun, so no determiner is needed. If you substitute your own
name for "github" in the original prompt above, you get the same effect:
> Would you like to push commits from the current branch to "github"?
Add the implicit word "remote". "github" now acts as an adjective and
"the" refers to "remote":
> Would you like to push commits from the current branch to the "github" remote?
Or, combine the two. This last option relies on the fact that
instructions and manuals often omit definite articles because most
articles are definite. See the [zero-marking][2] article on Wikipedia.
The original prompt already does this by omitting "the" before the word
"commits":
> Would you like to push commits from the current branch to "github" remote?
Reference:
[1]: http://writing.umn.edu/sws/quickhelp/grammar/articlesproper.html
[2]: https://en.wikipedia.org/wiki/Zero-marking_in_English
I always get tripped up whenever trying to list my codespaces, adding
`ls` as an alias to `list` feels natural enough.
Co-authored-by: Mislav Marohnić <mislav@github.com>
While a gh command is writing stdout to a pager, the user may choose to
close the pager program before the pager has read all the data on its
standard input. In that case, the parent gh process will receive an
EPIPE error, which would bubble up its error handling and cause it to
print something like:
write |1: broken pipe
Since this was caused by an explicit user action of closing the pager,
and since the user probably doesn't want to see this uninformative
error, this informs our global error handling of this error and causes
it to be ignored.
Add pager functionality to the following commands:
- gist list
- pr checks
- release list
- run list
- run view
- secret list
- workflow list
- workflow view
Additionally, normalize error handling when starting the pager has
failed: only print a non-fatal notice to stderr instead of aborting the
whole command.
This helps avoid the errors when a new commit from upstream is not yet
available in the fork, resulting in a HTTP 404 when trying to update the
ref in the fork.
If the merge-upstream API is unavailable (404) or errors out (409/422),
the functionality falls back to the previous functionality of manually
updating refs. This ensures that `--force` still has effect.
