change edit to nano

[marwahaha]

I don't think edit comes installed by default on Mac. (It's not on mine...)

On the other hand, nano should be there by default. It's also the recommended text editor for Software Carpentry.

If you all prefer edit, perhaps we can include instructions on how to install edit if it's not available.

[katrinleinweber]

Agreed. edit is not on my macOS either.

[katrinleinweber]

Dear @evanwill, since you introduced edit -w, what's your opinion on this PR?

[evanwill]

@katrinleinweber I would switch to nano as well.
This set up was based on Software Carpentry from a several years ago. Earlier versions of MacOS didn't always have nano installed by default, so that was why we had separate "safe" suggestions for each (edit was part of TextWrangler, which I don't think is installed by default any more...). And since that time Git-for-Windows added nano, and users should choose it as default during installation.

There isn't much detail in these prep instructions, because the Software Carpentry version of prep is centralized for the whole two day workshop, so prep for individual lessons is minimal and doesn't explain things like installing Git-for-Windows. It seems like Library Carpentry lessons are more stand alone so we might want to add more detail, so we might want to make a few more changes, and make sure everyone is using nano. Here is the prep instructions that I use in my local workshops as an example.

[katrinleinweber]

Cool, thanks for explaining :-) Could I interest you in contributing some of your updates to this lesson back in separate PRs?

And a big thanks to @marwahaha as well for updating the lesson!

[katrinleinweber]

Since this is pretty much the 1st PR for the new maintainer team, I'm not sure how we should proceed. Majority vote? 4-eye principle?

I guess if nobody objects within the next few days, I'll merge this.

[libcce]

For major revisions, you want to allow a number of reviewers time to respond. But for something like this, two or three reviewers is probably sufficient. I agree with the changes by the way. @EvaSeidlmayer needs to approve the request I sent her to be a collaborator. Otherwise, everyone else should be receiving these messages.

[libcce]

By the way, thanks @marwahaha !

[evanwill]

I made a more complete update with full install details in PR #42

[dheles]

The word "editor" has been changed to "or" in the first sentence changed by this PR.

#42 now offers instructions for nano on all platforms. If we are going to recommend using text-only editors, I think the text there (which further amends this one) is cleaner.

However, TBH, I favor instructing learners to install and use a graphical editor like Atom from the start. I think encouraging folks who in many cases had only ever used a console in the lesson prior to do all their git editing in a text-based editor is not a great idea. It really adds to the impression that git is complicated and confusing. This is especially true for librarians and non-IT staff who really just want to learn how to write and share python scripts (the majority of the community I expect to serve).

This position is probably overkill for a PR review, but I figured while we were on the topic, I'd put it out there. I'm ok with moving this PR and #42 through for now.

[katrinleinweber]

There is an LC-based Git lesson with GitHub Desktop, which I have used once. I think it's useful if the learner group doesn't do Shell. If they do, sticking to it for Git seems better to me.

Regarding "editor" has been changed to "or" in the first sentence: Indeed! Thanks for catching. Fixed now :-)

[evanwill]

@dheles in my local git workshops I ask people to install a good text editor and use it to edit files, and discuss plain text vs binary. However, I encourage them to set nano as git core.editor because the main use will be saving auto generated merge messages when auto merging after a pull. I find that most people find it confusing to have Atom suddenly open up after typing git pull in the terminal (besides being overkill to wait for a fully featured code editor to start up just to save an auto generated message).

[katrinleinweber]

In my experience, the "overkill" part is mostly due to Atom's slow startup speed. I'd argue that both accepting that and/or using a faster editor, will generally bring about the larger benefit of focusing on learning only a single tool.