Repository navigation
Description
gh alias import
The problem
After creating many gh aliases, change to another computer is hard because I have to add every alias manually. 😢
As we already have gh alias list, the output of this command should be the input of a gh alias import command. 😄
Proposed solution
At least one of those forms should be valid:
gh alias import -f aliases_filecat aliases_file | gh alias importcat aliases_file | xargs gh alias set
I tried something like 3 but the format is not compatible.
I ended up creating a Python script that opens a file with gh alias list output and sets the new aliases:
~/gh_aliases.py
import subprocess
from os import getenv
from pathlib import Path
ALIAS_INDEX = 0
EXPANSION_INDEX = 1
file_content = Path(f"{getenv('HOME')}/gh_aliases").read_text().split("\n")
aliases_and_expansions = [
full_alias.replace("\t", "").strip().split(":")
for full_alias in file_content
if full_alias != ""
]
for alias in aliases_and_expansions:
subprocess.run(["gh", "alias", "set", alias[ALIAS_INDEX], alias[EXPANSION_INDEX]])So the execution is:
- In Computer 1
gh alias list > gh_aliases- copy
gh_aliasesfile to Computer 2 (maybe withgh gist create)
- In Computer 2
- paste
gh_aliasesin the user's home directory - create
gh_aliases.pywith the content above in the user's home directory* - run
gh alias set --shell 'ai' 'python ~/gh_aliases.py'* - run
gh ai
- paste
Steps marked with "*" are needed only once. All other are needed every time the aliases in Computer 1 changes.
Instead of ai I tried to create the alias import alias, but I received the following error: could not create alias: "alias import" is already a gh command. Is this command already in development? I tried to use, but received unknown command "import" for "gh alias". gh version 2.18.0 (2022-10-18)
Something similar to my workaround should be delivered with gh.
Another solution
Another possible solution is tho make the output of gh alias list compatible with gh alias list | xargs gh alias set, so we can simple copy the output to a file and run the import with xargs. The problem here is that this would make the current gh alias list command incompatible with the new versions, unless it uses a custom flag (e.g. gh alias list --export-for-import | xargs gh alias set).
Activity
mislav commentedon Oct 24, 2022
Thanks for the feature request.
We agree that a way to import aliases would be useful. Perhaps the usage can be like so:
The format of aliases could be YAML to properly support multi-line aliases.
Ref. #6497
kevhlee commentedon Jan 30, 2023
Hi @mislav, do you mind if I take this?
Also, I have one question about this feature: What should happen when an alias is already taken? Should the CLI allow the alias to be overwritten? Or should it warn the user and error out?
mislav commentedon Jan 30, 2023
@kevhlee Good question. By default I would suggest that importing aliases should never overwrite existing ones, and that duplicates should be announced on stderr and the operation should continue. But then, I anticipate some people will ask for a feature to overwrite existing aliases (for instance, to sync their changes across machines). To allow that, there could be an extra flag. And if there is an extra flag, that means a dedicated command would be the way to go (instead of overloading
gh alias set).How about:
kevhlee commentedon Jan 31, 2023
That makes sense, @mislav. I also think creating a dedicated command for importing aliases is the right call.
I do have one technical concern regarding the command name.
importis a keyword in Go, so following the pattern set in the code would be awkward (e.g. we cannot have a package namedimport). Perhaps the CLI should have the following instead: