Re: [PATCH 0/2] WIP: doc: add new git tutorial
- From
D. Ben Knoble <ben.knoble@gmail.com>
- Date
- Oct 7, 2026, 19:26 UTC
- Message-ID
- <CALnO6CDBFri-MYXEg0TGF7-Oc49hf48qEQCQLYpdXKMkJzbYhw@mail.gmail.com>
- In-Reply-To
- <pull.2248.git.1791315422.gitgitgadget@gmail.com>
On Tue, Oct 6, 2026 at 3:40 PM Julia Evans via GitGitGadget <gitgitgadget@gmail.com> wrote:
Show 23 quoted lines
> > 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? > =================================================================
Show 14 quoted lines
> 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 > ========================================
Show 10 quoted lines
> 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 <host> IdentifyFile <key>" 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