sahansk2
commented
3 years ago @benthayer Looks pretty interesting.
I'm not a fan of two of these aliases existing: the one for status, and the one for commit. If the point of git gud having these commands is to simulate the environment as it would be with Git, then having aliases like these trains the user for Git Gud, and not Git. Those two commands, aside, I'm okay with aliases.
Also, it looks like an exception will always be raised (and caught) if the user doesn't use the aliases, which is considered expensive, apparently. Do you think you could refactor that logic?
Lastly, is there a way to better the presentation of the aliases? Right now, they're all clustered at the bottom.
sahan@sahan-Lenovo-YOGA-C930-ubuntu:git-gud$ git gud h
usage: git gud [-h] [--version] <command> ...
A game to teach Git!
optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
Subcommands:
<command>
status Print out the name of the current level
explain Show the explain for the current level
goal Concisely show what needs to be done to complete the level.
reset Reset the current level
reload Alias for reset
test Test to see if you've successfully completed the current level
level Display current level
goal Show a description of the current goal
contributors
Show project contributors webpage
issues Show project issues webpage
help Show help for commands
solution Show solution for the given level
init Init Git Gud and load first level
load Load a specific skill or level
skills List skills
levels List levels in a skill
commit Quickly create and commit a file
The following aliases exist: 'h' -> 'help', 'i' -> 'issues', 's' -> 'status',
'e' -> 'explain', 'g' -> 'goal', 'r' -> 'reset', 't' -> 'test', 'l' -> 'load',
'c' -> 'commit'
@sahansk2 What do you think?