4 ms·
I tried to use this approach last semester in a course I taught and found out that it isn't easy to get used to an SCM the first time, so regular and good stude
by lfborjas 16y ago
I tried to use this approach last semester in a course I taught and found out that it isn't easy to get used to an SCM the first time, so regular and good students end up doing huge and late commits, moreover, one of the worse performing students learnt -ironically- to alter the git log to seem more diligent than he actually was (lots of commits and files changed), and with stuff like git rebase, a more clever cheater could never actually get caught. So an approach strongly reliant on the SCM kinda weakens in practice(though, as you point out, it could be used as a _secondary indicator_ or guarantee of work). And in theory, as other commenters say, taken to extremes, one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach.
Nevertheless, it is feasible to set up stuff like post-commit hooks (I actually used 'em to monitor the turn ins to an exam) to maybe submit the code to an automated plagiarism detector like [moss](http://theory.stanford.edu/~aiken/moss/ http://theory.stanford.edu/~aiken/moss/), that would be cool, maybe I'll try that out next semester.
- spacemanaki 16y agoYeah, there are definitely a lot of things I didn't think of which would make this somewhat ineffective. > one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach. This seems to describe exactly the problem with the exams I had, which tested more the ability to memorize a solution and regurgitate it in a test setting. This is of course anecdotal, but I've heard of similar exams in other schools. So I think there's a lot of room for improvement there.