Git Novice Episode 2 - give more detail about text editors

[k-tatgenhorst]

The lessons are well taught, but I feel one area lacking detail is about the choice of editor.

How to set the editor is of course mentioned, but then additional information is listed for VIM which leads a novice to think this is an implied preference choice for the course. I feel that text above the selection mentioning the fact that many linux/unix users have editor preferences and accumulated skills which foster their efficiency should be mentioned. Additionally, the student might be given the suggestion to search outside of class for details on incorporating their choice of editor into their git workflow.

I do not believe this would add to the required length of time for the lesson, only that it would reinforce that editor selection is a personal choice.

Thank you, Karl Tatgenhorst

[michaelberks]

I actually recommend taking the opposite approach, and removing all references to setting Git's default editor from episode 2.

My reasoning:

1. There's no example in the remainder of the lesson where Git's editor is used
2. The only time in normal workflows the editor gets used is when asked to comment on a merge conflict. This is a fairly rare occurrence, particularly in the likely use cases of git novices. Note this is taking account that:
   • commit messages are taught using the "-m" option and setting a one line message (best practice for small, regular, local commits) and note post-edited once set
   • the only time longer commit messages are recommended are eg squashing commits into pull-requests, which are beyond the scope of this tutorial and more normally done directly in GitHub's (or GitLab etc) web-interface
3. Because it's used rarely, setting the default as a config doesn't seem particularly important. eg I've used Git for years, including in some fairly complex GitFlow settings, and had never thought to set this config until I taught this lesson.
4. Git's default behaviour if the config is unset seems preferable to recommending vim anyway
   • If the user has set a default editor for their shell Git will use that (presumably what the user in this case would prefer)
   • If no shell default is found, Git will fall back to using vi, which is close enough to vim for the editing tasks you're likely to do in Git
5. One of the principals of carpentries lessons is "get to the most useful stuff as soon as possible". I'd argue in this case this means spending as little time as necessary in setup steps of episode 2.
6. The whole lesson is really hard to teach in the given timescale, therefore any material not required in the context of the lesson or in likely novice use cases following the lesson is helpful to remove (especially when other things get added, eg the change of default branch from master to main).

I'm sure others may disagree, but as I need to make a lesson PR as part of my carpentries instructor checkout process, I have made a PR with the editor section removed. I understand totally if this PR gets rejected.

[kekoziar]

Text editor information is included because if someone executes git commit with no -m and message, the text editor which is associated with git will open, prompting a commit message. The default text editor is vm, which is difficult, even for those experienced on the command line.

The text editor information and vm callout are in the lesson to address this issue which often happens at least once during a workshop.

[froukje]

I understand the argument that it may be confusing, that if git commit is executed without the -m option and some editor opens. However, we should think, what is more likely to lead to a confusion about the editor.

1. case: Delete the explanation about the editor. If in this case the learner uses git commit without -m, she/he will ask for help, and you can explain what happened.
2. case: Leave it as it is; You have to explain to the whole group how to set your prefered editor. This may help to avoid later confusion, however it costs valuable time, which I think could be used for more useful things about git. Especially, when the learners are not used to use editors at all.

I agree with the argumentation above, that this part should be left out. However, I have to say, that I never tought this lesson. So maybe people with more practice experience have better arguments for leaving it or deleting it. Just for myself, I can say that it confused me, when I was reading and preparing the lesson and I felt this could lead to confusion, although I understand that it is in there exactly to avoid confusion. Looking back, for me as a learner, I learned this as a much later stage. It would be interesting to hear more experiences from people who actually tought this lesson.

[kekoziar]

The comments have veered from the original issue, which is "one area lacking detail is about the choice of editor" into opinions on whether any information is needed on editors at all.

To address the original issue: from my experience, describing the different types of editors and IDEs, and when you would use them and why would 10-30 minutes, depending on the level of discussion. Another concern regarding discussing choices of editors is it is out of scope of the lesson.

I'm going to close this issue. For those who want to discuss removing editor information from the lesson, there is a different issue.