3 ms·

I tried unsuccessfully to find the repo and issue tracker for try.github.io at https://github.com/codeschool?query=git https://github.com/codeschool?query=git a

by lloydde 12y ago

I tried unsuccessfully to find the repo and issue tracker for try.github.io at https://github.com/codeschool?query=git https://github.com/codeschool?query=git and https://github.com/github?query=git https://github.com/github?query=git . 1) I don't think providing the message (-m) on the command line is a good habit for beginners. 2) https://try.github.io/levels/1/challenges/7 https://try.github.io/levels/1/challenges/7 is a wild card operation followed by a `commit -m`. Prior to the commit there should be another `status` or interactive commit (no -m), see (1) above.

olivierlacan 12y ago
The current version of Try Git isn't open-sourced. You can contact us (Code School) directly to report any issues: http://www.codeschool.com/support http://www.codeschool.com/support 1) That's true. Although sending beginners into a less/vi commit interface that is even more bewildering than the basic shell is not a good way to concisely introduce people to a new tool. The hardest part of teaching is what you chose not to teach. 2) We purposefully used the GUI file browser (My Octocat Repository) at the bottom to avoid having to systematically do `git status` in order to check the state of the repo.
- ibrahima 12y ago
  Hmm, yeah, I always felt that was weird as a default since most beginners probably don't know vi/vim. Now I have to wonder why the default doesn't just take input on stdin for the commit message. Well, I guess you lose the ability to edit previous lines so maybe that's it. I guess nano as a default would probably be reasonable.
- lloydde 12y ago
  > 2) We purposefully used the GUI file browser Adding this artificial element furthers concisely introducing people to a new tool? If you are going to teach a CLI then stay in the command line. Also, you didn't solve the problem as the GUI file browser doesn't show the status of the files either.
- JoshTheGeek 12y ago
  nano is less confusing than vim, though that is another bad habit to form. I used it for a very long time, but switching to vim has been amazing. I think that -m is probably best for teaching a beginner, though.
brodney 12y ago
> 1) I don't think providing the message (-m) on the command line is a good habit for beginners. Why? I started that way and still do it today. Is it considered a bad practice?
- olivierlacan 12y ago
  Because it doesn't put you in the right mindset. A commit message should be formatted like an email to your past self, or your future collaborators. It should have a very descriptive and concise title (the first line of the message) written in the present tense and after a line break you should (when necessary) write an email style explanation of the reasoning behind the commit. If you fixed something, is there context that should be useful for someone discovering this commit in a vacuum. Are there any related commits? If you added something, why? There is so much useful information that can be encoded in a commit message and discovered when someone does a `git blame` for example. Caleb Thompson wrote a nice concise post on this: http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message http://robots.thoughtbot.com/5-useful-tips-for-a-better-comm...
  - pimlottc 12y ago
    I'll agree that being in interactive editor is a more conducive setting for this kind of message, but you can provide both a title and longer description via command line by specifying the -m option twice, e.g. git commit -m "fixed the widget factory" -m "It seems like we keep getting wooden shoes stuck in the machine, so I added a ShoeClearingDaemon process to check periodically and restart the machine if necessary."
lloydde 12y ago
3) Confused use of the term "repository" - "1.2 The repository is a hidden directory where Git operates." OK - "1.3 I created a file called octocat.txt in the octobox repository" WAT - GUI labeled "My Octobox Repository" HMM

by lloydde 12y ago

olivierlacan 12y ago

The current version of Try Git isn't open-sourced. You can contact us (Code School) directly to report any issues: http://www.codeschool.com/support http://www.codeschool.com/support 1) That's true. Although sending beginners into a less/vi commit interface that is even more bewildering than the basic shell is not a good way to concisely introduce people to a new tool. The hardest part of teaching is what you chose not to teach. 2) We purposefully used the GUI file browser (My Octocat Repository) at the bottom to avoid having to systematically do `git status` in order to check the state of the repo.

ibrahima 12y ago
Hmm, yeah, I always felt that was weird as a default since most beginners probably don't know vi/vim. Now I have to wonder why the default doesn't just take input on stdin for the commit message. Well, I guess you lose the ability to edit previous lines so maybe that's it. I guess nano as a default would probably be reasonable.
lloydde 12y ago
> 2) We purposefully used the GUI file browser Adding this artificial element furthers concisely introducing people to a new tool? If you are going to teach a CLI then stay in the command line. Also, you didn't solve the problem as the GUI file browser doesn't show the status of the files either.
JoshTheGeek 12y ago
nano is less confusing than vim, though that is another bad habit to form. I used it for a very long time, but switching to vim has been amazing. I think that -m is probably best for teaching a beginner, though.

brodney 12y ago

> 1) I don't think providing the message (-m) on the command line is a good habit for beginners. Why? I started that way and still do it today. Is it considered a bad practice?

olivierlacan 12y ago
Because it doesn't put you in the right mindset. A commit message should be formatted like an email to your past self, or your future collaborators. It should have a very descriptive and concise title (the first line of the message) written in the present tense and after a line break you should (when necessary) write an email style explanation of the reasoning behind the commit. If you fixed something, is there context that should be useful for someone discovering this commit in a vacuum. Are there any related commits? If you added something, why? There is so much useful information that can be encoded in a commit message and discovered when someone does a `git blame` for example. Caleb Thompson wrote a nice concise post on this: http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message http://robots.thoughtbot.com/5-useful-tips-for-a-better-comm...
- pimlottc 12y ago
  I'll agree that being in interactive editor is a more conducive setting for this kind of message, but you can provide both a title and longer description via command line by specifying the -m option twice, e.g. git commit -m "fixed the widget factory" -m "It seems like we keep getting wooden shoes stuck in the machine, so I added a ShoeClearingDaemon process to check periodically and restart the machine if necessary."

lloydde 12y ago

3) Confused use of the term "repository" - "1.2 The repository is a hidden directory where Git operates." OK - "1.3 I created a file called octocat.txt in the octobox repository" WAT - GUI labeled "My Octobox Repository" HMM