I try to tie together Bash, Python/R and Git by at the very beginning of the
very first day typing:
git clone https://github.com/jduckles/<somedatarepo>
This brings down all of the data that will be used for Bash/Python/R lessons. I
explain this as a bit like pulling down a zip file and exploding it into a
directory all in one command (something many people are familiar with) and that
they don't need to worry too much about Git right now. This ensures that they
1) have a functioning wifi connection, 2) have a working copy of Git and 3) can
access the Bash shell.
Then we go on our merry way forgetting about it until we get to the Git lesson
(late in the next day usually). I will then point out to them that the Git repo
they cloned the day before has been watching what they're up to in terms of
creating and/or modifying files. We run git status on it and they see all the
things they've created, files from redirection exercises, ipynb files, etc.
This hits home how you can use a special folder called a Git repository to
watch what changes you're making. At this point I will launch into the planets
exercise to show them how they can make their own "special folders" which track
what they're doing.
This in combination with the planets exercise gives them a broader sense of
what Git is useful for.
Recently I tried a collaboration exercise using just the GitHub interface and
that went very well. I have users Fork a repo, edit a file on that fork (A
markdown template to fill in with trivia about a country in the world) and
submit a PR back to my "upstream". Once we've done this we can talk about how
we'd do it with an "upstream" (my repo) a "origin" (their fork) and "local"
copy from the command line with less confusion.
Regards,
---
Jonah Duckles
Software Carpentry, Executive Director
http://software-carpentry.org
From: Shauna Gordon-McKeon <[email protected]>
Reply: Shauna Gordon-McKeon <[email protected]>
Date: May 20, 2016 at 9:52:37 AM
To: Ashwin Trikuta Srinath <[email protected]>
CC: Software Carpentry Discussion <[email protected]>
Subject: Re: [Discuss] Teaching Git Using GitHub Pages
When I taught newcomers to use git at Open Source Comes to Campus workshops, we
did something similar to what Bruno Grande does, and had a lot of success with
it. Some of these concerns occurred to us, this is how we dealt with them:
On Fri, May 20, 2016 at 7:44 AM, Ashwin Trikuta Srinath <[email protected]>
wrote:
I would also be -1 to building a blog at a Software Carpentry workshop.
There's too much extraneous cognitive load involved.
We did not use a Jekyll blog, but rather a very simple HTML template to
minimize cognitive load. We helped students create something more complicated
later, during the freeform section at the end of the day, if they were
interested.
If you have students create this in a github repository matching their name,
they don't even have to use a gh-pages branch, so it really is minimal
additional load.
Git/GitHub in the context of scientific computing is exciting, because it
solves real problems
like data loss, reproducibility, and maintaining correctness. Maybe some
learners go on to
discover these things by themselves after our Git session, but I do feel it's a
bit irresponsible
of us not to lead them to it.
This seems like the strongest objection to me, but perhaps the two things could
be combined - sharing data via github pages.
(1) Not everyone is comfortable with writing something at perhaps just a
few minutes notice and then putting it into the web-wide public. Personally,
I'd do it reluctantly, make a very strong mental note to myself to take
down the thing after the lesson, and dislike the lesson for having to
remember that. And if I managed to forget, I'd not only blame myself, but
apportion some blame on the lesson as well.
We addressed this by giving students a template to work off of and suggesting
they customize it with their name but making sure they knew it was okay to do
something silly and pseudonymous. A blog lesson doesn't need to include real,
serious blog posts. Alternatively, if it's a public data-sharing site, you can
use clearly labelled example data so that students don't feel like the exercise
is reflecting on them.
a) blogs are typically personal, so it's difficult to motivate a
scenario where contributions from team members result in a conflict
b) blog posts are typically written with a time stamp and then not
revised, so it's difficult to set up a plausible scenario for
showing diffs and checking out earlier versions.
These are good reasons for a hybrid lesson. We induced conflicts by having
students make changes to the templates and push them back to master, but we
were trying to demonstrate a typical open source fork-clone-change-pull-request
work process, which is a bit different from what you're trying to do.
(Although I will say, as someone who has kept a blog for years, that there are
plenty of plausible scenarios in which I'd want to update a blog post!)
Anyway, I'm not necessarily arguing for changing the SWC lesson - it sounds
like there are some pretty good reasons not to. Just wanted to share how a
blog-style into to git lesson worked for us.
- Shauna
Best regards, Jan
> Best,
>
> Lex
> _______________________________________________
> Discuss mailing list
> [email protected]
> http://lists.software-carpentry.org/listinfo/discuss
--
+- Jan T. Kim -------------------------------------------------------+
| email: [email protected] |
| WWW: http://www.jtkim.dreamhosters.com/ |
*-----=< hierarchical systems are for files, not for humans >=-----*
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
