@cristiand391 Thanks for picking this up! This looks great already.

I'm going to suggest some output tweaks that are different from the design spec you were working off of, and ask input from my team to see if any of this resonates with them:

• I'm not sure if we need the --archived filter. Can anyone think of a use-case for it? I don't think we need to necessarily duplicate every filtering option available in the web UI— at least not for now.
• “When doing gh repo list --fork or gh repo list --source, don't list archived repos.” - Even if the web UI does this (TIL!), should we also do it? Since this command will have programmatic use, maybe it's best to avoid encoding some magic behavior. If we anticipate the need for avoiding archived repos, we could expose a flag such as --no-archived?
• Could repo tags such as “Private, archived" be rendered into the 3rd column (instead of the 2nd), not be placed in parentheses (we only do this for repo labels), and be separated by commas? This way, the first 2 columns will be repo name & title, which are in my view the most important information.

I'm not sure if we need the --archived filter. Can anyone think of a use-case for it? I don't think we need to necessarily duplicate every filtering option available in the web UI— at least not for now.

I'm honestly agnostic on this one! If there's no strong push for it, I'm fine to punt on it.

“When doing gh repo list --fork or gh repo list --source, don't list archived repos.” - Even if the web UI does this (TIL!), should we also do it? Since this command will have programmatic use, maybe it's best to avoid encoding some magic behavior. If we anticipate the need for avoiding archived repos, we could expose a flag such as --no-archived?

I don't feel super strongly about this either. But, even for programatic use cases, I can imagine if you archive a repository, it might be a lot of clutter to see them showing up in lists by default? And as a get around, wouldn't passing both --fork and --archived show archived forks for example?

Could repo tags such as “Private, archived" be rendered into the 3rd column (instead of the 2nd), not be placed in parentheses (we only do this for repo labels), and be separated by commas? This way, the first 2 columns will be repo name & title, which are in my view the most important information.

I like this change! 👍

I'm not sure if we need the --archived filter. Can anyone think of a use-case for it? I don't think we need to necessarily duplicate every filtering option available in the web UI— at least not for now.

+1. I definitely don't think this is needed unless we actually see some significant demand for it.

When doing gh repo list --fork or gh repo list --source, don't list archived repos.” - Even if the web UI does this (TIL!), should we also do it? Since this command will have programmatic use, maybe it's best to avoid encoding some magic behavior. If we anticipate the need for avoiding archived repos, we could expose a flag such as --no-archived?

I have no strong opinions about this either. Honestly I don't think it matters that much, and therefore would opt to mirror what dotcom does, especially since that helps reduce clutter as @ampinsk pointed out.

Could repo tags such as “Private, archived" be rendered into the 3rd column (instead of the 2nd), not be placed in parentheses (we only do this for repo labels), and be separated by commas? This way, the first 2 columns will be repo name & title, which are in my view the most important information.

This is 💯

@mislav I've added some tests and pushed some changes to address suggestions.
Regarding to listing archived repos when filtering, should I remove it or add some new flag or something else?

Feature request: filtering by language.
Currently I'm using this tiny script:

set -e

repos() {
  local owner="${1?}"
  shift 1
  gh api graphql --paginate -f owner="$owner" "$@" -f query='
    query($owner: String!, $per_page: Int = 100, $endCursor: String) {
      repositoryOwner(login: $owner) {
        repositories(first: $per_page, after: $endCursor, ownerAffiliations: OWNER) {
          nodes {
            nameWithOwner
            description
            primaryLanguage { name }
            isFork
            pushedAt
          }
          pageInfo {
            hasNextPage
            endCursor
          }
        }
      }
    }
  ' | jq -r '.data.repositoryOwner.repositories.nodes[] | [.nameWithOwner,.pushedAt,.description,.primaryLanguage.name,.isFork] | @tsv' | sort
}

repos "$@"

@data-man That's an excellent suggestion. Added!

Note that for filtering by language, we have to turn to the search API connection (as opposed to the repositories connection). In that case, the results are sorted in updated-desc order rather than in PUSHED_AT order.

Proposals:

-a      --archived          Show only archived repositories
-f      --fork              Show only forks
-n      --no-archived       Omit archived repositories
-s      --source            Show only non-forks

@data-man Thanks, but I do not think that every long flag needs to have a shorthand. In particular, -f and -s don't read really well when on their own, as opposed to -l ruby which is likely self-evident. Therefore, I'd rather that people spell out --fork and --source.

@mislav

It would be nice to show a primary language as well.