When will git be a mandatory part of the course? #112

Closed ErikBjare closed 4 years ago

Me and @RXminuS discussed a few weeks ago the insanity (in our opinion) of students not learning VCS until their 2nd year (when I studied it was CVS and SVN, hopefully things have finally caught up by now).

Both me and Rik were of the opinion that Git should be mandatory for first year students, and happened to stumble upon the topic of cheating/lab review. We stumbled upon the issue of people putting up solutions to their labs publicly on GitHub etc, if it weren't for the issue of people sharing/stealing solutions we thought it would be great if everyone did, even if just as an exercise.

That lead us to the point I've been trying to explain the backstory of: What if everyone uploaded their solutions to the labs to a GitLab server maintained by the CS department at LTH? We'd smash two flies in one go: All solutions could be compared and audited to prevent cheating, and everyone would have to learn git. Whether they learn the CLI or some GUI doesn't really matter, what matters is being able to use it. However, the course would likely have to provide educational material for at least one way of using it: I'm in favor of the CLI but I can imagine a lot of people thinking a GUI would be more pragmatic and easier for students to learn the basics. An introduction to the CLI and then a recommendation to use a GUI might be the best approach.

The cheating-discovery process is arguably difficult, but it need not be perfect. People who consider cheating will realise that it's easy to get caught since the solution is on the record. The tool doesn't even have to be created right now, the fact that it could be created in the future should deter people enough.

Anyway, just a thought. Let me know what you think @bjornregnell @majstenmark @gustavcedersjo.

Yeah completely agree! I really think that instilling a good collaboration workflow for students from day 1 will hugely improve the quality (and usefulness) of programmers that we put out.

It makes it much more transparent as well who did what during group work, it becomes much easier for people to peer review other people's code (which I think would be a great learning experience, especially when new to programming) and of course most importantly...it's how companies work! Bonus points if we can get them inspired to start contributing to other projects & learning that way.

Using git it's also not that big a step of setting up a build server next to it so that it's automatically verified to pass integration/unit tests which would make grading/approving a lot easier. Even better, if the actual lab / course material would be available in Git it would be so easy to fix mistakes/suggest changes & get students engaged in developing the course.

I would argue for focus on CLI as well and making a simple visual "course" that showcases how a team works together using something like Git(Hub) Flow. I think the benefit of a GUI is that you it's much easier to visually understand what you're doing but I don't think it's wise for people to have to rely on those visual aids.

I'll consider this - maybe the project at the end of the course could be handed in via git.cs.lth.se Another option is to require that at least one of the team labs are done using git.cs.lth.se or as a closed repo on bitbucket. I'll investigate pros and cons of this and other solutions. Or perhaps other, less packed ;), courses the first year should take on git intro...

@bjornregnell Actually I think that having it as a single assignment or separate project rather defeats the point, because then it becomes this separate thing from coding which depending on if people "get" it either sticks or not...either way they don't get to experience version control as part of software development.

I think it would be much better to keep it simple but consistent...maybe only teach them git pull...git commit...git push on the master branch if the course load is significant already; but do it right from day 1 and then have optional mini assignments to have people interested explore the power of git a bit more. I think if there's a structured and consistent way for students to build, save, submit and collaborate on their work it would be much more enjoyable. Especially since labs sometimes build on past assignments and the amount of times I've seen students have 8 different copies of the same codebase is just heartbreaking.

And again the beauty of a commit tree is that you can see someone did the assignment...if you just suddenly see a bunch of code appear out of nowhere you know they've copied someone else. So even if only master branches were public you could just make people squash their commits when merging and then have them use whatever git repo they want for development (github, gitlab (my favourite) or bitbucket (my least favourite actually)) and then they submit their solutions on a private stage remote that shows all the commits to the teachers.

Sorry, know that these are really opinionated comments, but it's because I think it's important and close to my heart :-)

Well, given a very pressed course development schedule until this August, with lots of things remaining, I'm not prepared to include git globally in 2016; but 2017 is another fresh year (and the subject of this issue indicates it to be before "ever" :)) There are also other things higher up on the tooling prep todo list; e.g. enabling IDE-agnostic builds; I'm discussing with sysadmin to include intelliJ and sbt in the tooliing along with Eclipse on our school linux boxes. Etc. But I agree that it would be najs having stundents' version trees exposed to teachers...

Glad to see your input here Rik, I notice I missed a lot of tangents in our conversation when reading your comments.

@bjornregnell Okay, I can totally understand that you are pressed for time, but would you mind if I drafted up a guide for basic git use? I'd hope it could be included in the compendium the students would receive and you could tell them the truth: you wanted to add it as mandatory but the course was already packed so it's optional for now.

I hope it will be included a lot sooner than right before "ever" (a misformulation on my part, I was hoping for next year). Even if it ends up being taught in a different course (which I wouldn't think appropriate) hopefully the guide in the compendium could be improved and reused in the next course so that the phenomenon of open source courseware could continue and spread into other CS courses.

About the planned guide: I would be recommending the student to use a private Gitlab repo, not a big fan of Bitbucket. GitLab CE being open-source and allowing private repos on GitLab "Cloud" while having a better UI (IMO) really makes the decision easy.

I'd make it short and simple only keeping to the essentials of init/clone -> pull -> commit -> push. I'd then reference external material for those who wish to dig deeper.

On Jul 16, 2016 14:13, "Bjorn Regnell" notifications@github.com wrote:

Well, given a very pressed course development schedule until this August, with lots of things remaining, I'm not prepared to include git globally in 2016; but 2017 is another fresh year (and the subject of this issue indicates it to be before "ever" :)) There are also other things higher up on the tooling prep todo list; e.g. enabling IDE-agnostic builds; I'm discussing with sysadmin to include intelliJ and sbt in the tooliing along with Eclipse on our school linux boxes. Etc. But I agree that it would be najs having stundents' version trees exposed to teachers...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lunduniversity/introprog/issues/112#issuecomment-233127588, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVxulIlfB00iY8zSLw06A7FoNk-G1y_ks5qWMrZgaJpZM4JKez6 .

I agree, knowing how to use git would have been golden during the team labs, since the different parts depend on each other. No more GDrive or sending files back and forth in facebook chat groups!

On the other hand, I think you need to experience the manual labour before you really can understand why git works like it does... So its not bad IMHO to experience the pain of manual version management ;)

On 2016-07-28 22:55, Henrik wrote:

I agree, knowing how to use git would have been golden during the team labs, since the different parts depend on each other. No more GDrive or sending files back and forth in facebook chat groups!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/lunduniversity/introprog/issues/112#issuecomment-236022441, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADb1mRdDQW5rVPY4J9bMjcoG_61nGT1jks5qaRdNgaJpZM4JKez6.

@bjornregnell That's like saying we want students to have their first programming course in INTERCAL so they appreciate Scala more...

I think you need to teach it right from day one, and then if they arrive at Volvo or TetraPak with people emailing source-code they will have no respect for the status quo and immediately change it for the better.

I have been teaching configuration mgmt and version control for several years in project courses and I know that many students need a hands on experience and that software version control can be easier to understand if you at least once have considered what is involved in a manual merge of code from several people and the difference between sequencing and parallelizing work etc.

Volvo or TetraPak does not email code these days I hope :) but you are of course right that what we do at LTH can have good impact on the work practices in industry when our engineers graduate and get a job.

I am very positive towards introducing a modern tool chain but we can't introduce every goodie from day one, esp. as we have a wide span of student capabilities and motivation. And currently, there are many many things to do complete before Aug 29 - I will find the time to write about git and during the course I'll inform about its benefits when the work in teams, but I'll not require (at least not this first year) that every team uses it.

But thanks for the suggestion; I'll start working on an INTERCAL exercise that we might be able to fit in already in the first week :)

Hahaha, I think part of my drive to get this into the courses stems from the fact that big companies like Volvo & TetraPak actually DO have developers email source & binaries around. I nearly had a heart attack...as @zicvic can describe :-P

I agree that no every goodie can be introduced from day one...build systems, issues, merges, CI, CD..they're all beautiful little diamonds to be explored throughout the wondrous adventure these students set out on. However if we make the first thing they have to do to run the first lab is

git fork
git clone https://github.com/YOUR-USERNAME/EDAXXX
do the assignment
git commit -a -m "assignment 1"
git push

then some interested students will start exploring themselves. They don't have to understand it, they just follow line by line what is written...that's just how you download the code and submit it (instead of e-mailing). Then later in the course you can showecase some funny horror stories (I agree that it's good to see how it can not work as well) and gradually introduce some git concepts to remedy them. You don't have to make those features mandatory... (they can just keep committing like they did from day 1) but there's always the option & incentive to explore.

Unfortunately I have to admit that engineers at VOLVO do email source code. The following conversation actually did happen; "-Where can I find the code base to start working?, -Xx has it on his computer, he will email it to you on Monday..."

I agree with @RXminuS that it should be thought from day one. I had Thore Husfeldt in one corse and to quote him "One thing that makes us different from other faculties here at Computer Science is that we never rebuild the wheel, we use what's already built and build from there". One of the biggest challenges CS has at the moment (in my opinion) is that the technology that is used in the industrie is forever changing, just 6 months later and then everyone is using something else to do the same thing you did 6 months earlier. That is way faster then any University could ever change their course program. Imagine the possibility for interested students to contribute to the code base for the courses and make them keep up with the industrie. Just a thought.

I think the quote from Tore very much speaks the whole idea and pinpoints the biggest problem (and possibility!)

Most students in CS learn git eventually but other students (F etc..) does not. This was very clear att Volvo... Working with versioning really should be mandatory. My opinion.

I have to admit that engineers at VOLVO do email source code

Amazing, but this is in line with my experience of the (software) industry; we have a rather mature part of industry that has identified itself as a software industry, and then we have parts of industry that is totally dependent on software for their differentiation, but has not yet identified itself as a software industry. The former category attracts and employs cs engineers, while the latter is often re-trained engineers from other fields. There will for the foreseeable future be a lack of cs engineers so cs engineers have to help other engineers to re-train themselves as they get promoted to leadership positions in their companies.

I am totally for, in the long run, to include version control, open source development principles, continuous integration, test first, etc. in our introductory course chain, but this year we make so many changes to the first course that we already are taking quite some risks. Creating mature teaching material that is consistent with the other parts, including git theory, exercises, labs etc amounts to weeks of full-time work on course development+testing and that has to wait until coming course instances, but we can still start with parts of this on non-compulsory assignments already 2016.

There is this appendix with a skeleton:
https://github.com/lunduniversity/introprog/blob/master/compendium/postchapters/version-mgmt.tex Contributions welcome!

An appendix on version control is now available for review. I want to keep it tight, short and for the absolute beginner. An no extensive re-writing of what’s already on the net but rather point to the best resources .... Any feedback welcome!

BTW the file is moved to https://github.com/lunduniversity/introprog/blob/master/compendium/postchapters/version-control.tex

@bjornregnell @ErikBjare Seeing that git has not been added to the course contents in the last two years, has it been considered to include git into the famous "DoD" course (EDAA60) instead? Either by replacing an existing section (may I propose MatLab? :wink:), or by extending the course (requires larger administrative efforts). Thoughts?

@wanecek DoD is a good idea to consider. I'll keep this in mind when we plan for further developments.

@ErikBjare When re-reading the flow of comment I realized that I didn't really catch up on your offer to contribute to a git guide. Sorry for missing that... If you are still interested in this, and have ideas on what to add to the existing https://github.com/lunduniversity/introprog/blob/master/compendium/postchapters/version-control.tex perhaps you could here in comments outline some bullets on what might be missing? Another question is where to use git in the course exercises/labs. Perhaps the workspace with given code should be in its own git repo that students can clone.

We will now finally include a mnadatory lab in the "sister" course EDAA60 Datorer och datoranvändning. :+1:
@wanecek @rogerhenriksson is working on this and it will be implemented this fall.

That's great news, I'm sure the next generation of D-students will benefit a lot from it! Thanks for keeping us in the loop :)

lunduniversity / introprog

When will git be a mandatory part of the course? #112