From: D. Ben Knoble Date: Wed, 07 Oct 2026 19:26:15 GMT Subject: Re: [PATCH 0/2] WIP: doc: add new git tutorial Message-ID: In-Reply-To: On Tue, Oct 6, 2026 at 3:40 PM Julia Evans via GitGitGadget wrote: > > This is the first draft of a tutorial which introduces Git in two parts: > > Part 1: Create an empty repo & make 2 commits (git init, git add, git > commit, git status, git diff) Part 2: Push the repo to a remote host like > GitHub or GitLab (git remote add, git push) > > So far we've gotten 112 comments from 22 beta testers who have tried to > learn Git for the first using this tutorial. Most of them were able to > finish it successfully. I'd like to avoid getting into the details of every > single thing in the tutorial at this stage (we're still planning to do a > second round of feedback with the beta testers, and the beginning especially > will likely change) > > There are 2 questions I'd like feedback on since they both could affect the > structure of the tutorial. I don't think either of these is a dealbreaker, > since folks generally were able to finish the tutorial despite all these > issues and said that they enjoyed it and learned a lot. But it would be > great if there were an easy way to make the process less messy. > > > question 1: create the repo on the command line, or in the forge? > ================================================================= > c. Just try to get users to try to figure the right way in the > GitLab/GitHub/etc UI to actually create an empty repository that it's > possible to just push to. This is really hard because the UIs constantly > change. > > > current solution 1 > ================== > > Right now we're working on Option C since it seems least bad > > > question 2: How to handle authentication > ======================================== > current solution 2 > ================== > > Right now we're solving these by: > > 1. Using SSH > 2. Explaining how to set up SSH in the easiest way possible (with > disclaimers to check your security team's policy if applicable since the > "easiest way" may not be the best) > 3. Giving some instructions for how to translate an HTTPS URL to an SSH URL Disclaimer, I haven't read the patches yet. Both of these approaches sound like the right one to me. Assuming we're suggesting up-to-date key algorithms for SSH, I think that should be fine. (Memory says ECDSA and ED22519, I think? I'm not sure about the differences, but my regularly-used keys are the latter and my newest is the former.) I happen to use a somewhat convoluted "new key for each host" policy for myself, which ends up with lots of "Host IdentifyFile " in ~/.ssh/config and "Include"d files. I think separate keys per host is a good idea, but I certainly wouldn't want to foist that mess on new users. OTOH, even leaving an admonition "you probably want to set up one key per host later, so consider this just a starting point" is how such starting points become prolific use practice ;) So, idk on that front. Probably it's over-complicated to do that here, and point to better guides (or worry about making one externally if none exist), leaving the admonition in. Thanks for letting me think aloud, Ben