Jan,
For the Bash and Python sections we work inside this data directory, once we
move to the Git lesson, we move back to the home directory and create
everything from scratch. mkdir planets; cd planets; git init . etc.
Regards,
---
Jonah Duckles
Software Carpentry, Executive Director
http://software-carpentry.org
From: Jan Kim <[email protected]>
Reply: Jan Kim <[email protected]>
Date: May 20, 2016 at 12:20:25 PM
To: [email protected] <[email protected]>
Subject: Re: [Discuss] Teaching Git Using GitHub Pages
Dear All,
On Fri, May 20, 2016 at 03:32:03PM +0000, Jonah Duckles wrote:
> 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.
... and 4) that they're in the directory that now contains the top level
"exploded" material, so `cd <somedatarepo>` will work at this stage.
Where people use GUI based zip tools, the unzipped material may end up
anywhere, or nowhere at all.
I've previously achieved this by asking people to do something like
wget http://some.where.net/~jtk/coursematerials.tar.gz
tar -zxvf coursematerials.tgz
cd coursematerials
which does save much trouble compared to letting everyone doing the
download and unpacking the way they're used to.
One question / snag that occurs to me is: Do you also use this for
provisioning any initial git materials, and how do you guard against
creating a repo-in-repo situation in this case (as discussed / warned
against at the bottom of
http://swcarpentry.github.io/git-novice/03-create.html )?
Best regards, Jan
> 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
--
+- 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
