Closed NicMcPhee closed 3 years ago
Why switch everything from -
to *
?
Why switch everything from
-
to*
?
I (personally) prefer *
to -
for lists and Markdown lint wants all the list item markers to be the same throughout a file (which is sorta reasonable, I guess). If I don't have them all be the same, then my VS Code Markdown extension clutters up my world with a bazillion alerts. Since I was going through the whole README anyway, it wasn't a big deal to fix all those as I went.
As I mentioned in Slack and in the last commit:
I'm seriously considering modifying the end game to use pull requests instead of hand merging. GitHub's support for PRs has gotten fancier and niftier, including warnings when your branch is behind
main
and giving you a push-button way to mergemain
into your PR branch.We definitely want them to be using pull requests and code reviews through the semester, so maybe we should just start with that.
That will probably slow things down, but I'm thinking that this is going to become a two lab-session event in a purely on-line COVID world this semester anyway.
Thoughts on that?
@NicMcPhee Do you think we should have them use token authentication in this lab? It will be required by GitHub starting in August: https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
We probably should introduce token authentication here.
@floogulinc Do you think we should split this into two distinct labs, possibly run on adjacent lab sessions (one on Tuesday and one on Thursday)? The write-up has gotten really long, and adding token authentication and PRs is going to make it longer.
Maybe do the first part (editing text files with little change of merge conflicts) on the first day, and then the second part (editing the code and dealing with PRs and merge conflicts) on the second day.
It's going to screw with the calendar, but with COVID and everything on-line the calendar is going to have to change/be flexible anyway.
Actually, two labs wouldn't be a good idea because then we'd have two repos and lose what we'd done in one when we start the other. So maybe split the write-up into two Markdown documents, with the first linking (at the end) to the second? Or maybe we just want one really long document. I'm not sure.
@floogulinc I hadn't actually gotten into the personal access token thing yet, and the one part that looks a little intimidating is the scopes thing. The "simple" thing would be to give myself "all the scopes" with my token, but I'm guessing that's not "best practice". On the other hand, having and managing a bazillion scopes seems like a Big Mess Waiting To Happen. How are you handling this yourself?
@floogulinc Adding personal access tokens, pull requests, etc., to this would be substantial changes in their own right. I'm kind of thinking those should be in separate issues/PRs. Does that make sense to you? If so, I think we could call this good and merge it in, and then I could think about doing the other pieces separately.
Commit 2bb64d3 closes #55
I agree with @floogulinc that the current merge conflicts file really isn't "right" and doesn't reflect the kind of workflow we're expecting these days. Unfortunately, I don't think I have time to fix that now. The question then is whether to leave it in as is, or take it out altogether.
Thanks a ton to both @helloworld12321 and @floogulinc for all the excellent copy editing. If we never added new (broken) text, this thing would just get closer to perfect every semester! 😜
I created a new issue #71 to capture need to eventually update MERGE_CONFLICTS.md
to better reflect the desired pull-request-based workflow. That's not happening for this week, though, although folks are more than welcome to work on it in the meantime so it's ready when @kklamberty teaches the class in the Fall. 😀
Fix various issues in the README, like spelling mistakes, and add the BetterCodeHub badge.