-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dump a list of tutorials and commands they first introduce #1186
Conversation
b8b6995
to
7f8c774
Compare
Simplify #1186 by offloading some refactoring. See [this comment](#1186 (comment)).
a72b519
to
71444bc
Compare
71444bc
to
f9a7e91
Compare
@kostmo , apropos of nothing, I am wondering why you often force-push completely new commits to PRs instead of just pushing additional commits on top of the existing ones. In my experience it makes PRs somewhat harder to review, because (a) I cannot easily see what has been updated, e.g. when there are additional changes after I reviewed the initial PR, and (b) it is slightly annoying if I pulled the branch locally to test it; when I go to update it to test a later version of the PR I cannot just pull, I have to delete the local branch and re-pull the entire thing. One good reason might be to make a nicer, more logical commit history; but since we squash PRs into a single commit when merging anyway, this doesn't make much difference. But there might be other benefits I am not thinking of. |
Thanks for bringing this up; I hadn't sufficiently considered the review difficulties. For what it's worth, have you tried the "Compare" button next to the "force-pushed" GitHub log entries? There are a couple of situations where I might want to force push:
But in general, I will try to avoid gratuitously squashing after the point a reviewer has taken the first look at a PR. Even though merging a PR will squash the commits, I sometimes like to preserve individual commits for historical interest that one can go back to the PR to view. I can wait to do that until reviewers are done. |
43c2f92
to
353ce68
Compare
Also, preserve SrcLoc just in case
353ce68
to
c45ba7e
Compare
2f9f732
to
3e2bac4
Compare
I... hadn't noticed that before! Thanks, that definitely helps.
Yes, those all make sense.
Agreed, I have sometimes gone back to look at individual commits in a PR, e.g. when tracking down the specific change that introduced a bug via |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good, I think. What do you still have in mind before it is ready?
I think it's ready for now, @byorgey. In the future maybe we could augment the output to measure "tutorial coverage" of all of the extant commands. |
Perhaps, though (in my mind at least) the goal is not to cover all commands in the tutorial; some commands you should just learn about by playing the game --- crafting new devices, reading their descriptions, and so on. |
May be able to reduce likelihood of #1086 by having a autogenerated table of the commands and the tutorials they are introduced in.
This work is related to #1106 in that robot commands should be given distinct markup (backticks).
Demo
Updated: See rendered output.
New tests
Note that the test for
crash.yaml
is currently failing because theGive
command (and some others) are utilized in this tutorial without having been mentioned in the description or in earlier tutorials.Additionally, the "bug" described in this comment should be caught by these tests (i.e. fail the tests) since the embedded
solution
code in the YAML file utilizes thegive
command. That is, if it currently weren't for this issue.