I learned to program years ago in high school. Git was one of the things that I just never got. I remember used git as a "staging" platform and struggling so hard to resolve all the problems that kept coming up (I'm sure they were actually relatively simple to anyone who knows git, like a merge conflict or detached head or something) so much I eventually wrote a script to use rsync to copy and paste files that had changed since I last "pushed" to prod. Now that I understand how it works inside and out, I can appreciate how amazing git is, but I don't think it's the kind of thing that should (or even could) be taught to teenagers. I hope github keeps this mainly focused on web IDE with automatic grading and turn-in instead of trying to get kids to learn Git
> I don't think it's the kind of thing that should (or even could) be taught to teenagers.
This makes no sense. It all depends on the goals of the teaching. However, it's probably more meaningful for more people to be exposed to the capabilities of version control so they avoid creating one-off home grown solutions.
There was a time when the joke was that only teenagers knew how to set the time on the VCR.
This is true, but I'm referring to the "copy your files and rename them with a date" or "FINALrev.FromJoe-20200105-Updated-NEW-27" in the filename, not the bad implementations of tools (the GP comment didn't talk about implementing git, just about how git works).
I’ve yet to inflict git on my pupils, but I think that:
(a) there’s definitely a route into learning how it works without getting confused. For example, use of analogy to explain the staging area and the commit process, then drawing on the analogy at the end of the process to reference the git jargon.
(b) I haven’t done the full research but I feel that there’s a good ecosystem of porcelain for git, even though the era of plumbing+porcelain is far behind us. I’d appreciate any hints in the right direction on this front. If your answer is “hg” then so be it hah.
Sublime merge is much better than most GUIs in that it doesn't try to paper over the git concepts. It's just a UI for executing the standard commands.
I think the key features of a CLI porcelain, other than simply renaming some commands (e.g. `git branch new` rather than `git checkout -b`) would be:
- Making staging optional. Committing with no staged files would be equivalent to `git commit -A`. If you do stage files, then it would only commit staged files.
- Auto-stashing. Such that you could switch between branches, and your in-progress changes would disappear and magically pop back when you switched back to that branch. It would be as if there was an additional "working commit" that was associated with a branch without actually being part of it.
For moving past referring to a cheat sheet, I've found https://learngitbranching.js.org to be a great help with learning on how to work with a tree.
FWIW, `git branch newbranchname` does create a new branch. Run `git checkout newbranchname` after to switch to the newly created branch. Or run `git commit -b newbranchname` to do both at once.
The staging thing has to do with git's origin as being used for kernel development. Each patch is (ideally) meticulously constructed, and stands on its own. In order for that to be possible, git has the staging area in order to assemble pieces of a commit until it's perfect (aka `git add -i`). That large areas of software development doesn't have (and doesn't need) that level of attention to detail to each individual commit, is a function that most project don't look like Linux kernel development. For better or worse, Mercurial/hg does not have a staging area.
Unfortunately, I know git too well to reason if auto-stashing would help, rather than hurt (beginning) users. Personally I'll often commit my in-progress work (dumping plenty of mental state into the commit message to make it easier to pick up when I get back to it) and then then edit that WIP commit before submitting the PR. Your tools are there to support you, and one of git's strength is that it'll support pretty much any workflow due to all the low level plumbing available. Unfortunately, the cost of that flexibility it's learning curve.
Gitless seems to check your boxes. I haven’t tried it myself as nowadays I end up doing most of my git operations through VSCode keybindings. But it has always seemed interesting and I’ve considered bringing it into Code as an alternative git interface.
This is an aspect of the mechanism that I would like to change. That it isn't easy to pop your stashes once you have more than one going is precisely the problem! It'd probably need to be a separate kind of ref.
I think stashes are tagged with the branch name somehow? When I do a `git stash push && git stash list`, I get something like `stash@{0}: WIP on {branch}: {hash} {commit message...}`.
The message you get is an automatic message filled by Git when you don't provide one with the -m option.
Stashes are kind of sort of like branches themselves [1], but they are usually seen as a list, from which you can (cherry-?) pick arbitrary stashes with the apply or pop command, just name it [2]
> I don't think it's the kind of thing that should (or even could) be taught to teenagers. I hope github keeps this mainly focused on web IDE with automatic grading and turn-in instead of trying to get kids to learn Git
Why?
Git is pretty fun. Learning that it's not magic but just references and pointers to different objects was very valuable.
Although I probably don't understand enough to implement efficient merging but I can make a simple git clone (I am currently trying).
Git is a good way to introduce kids about hashes and basic crypto stuff, graphs (DAG) and other data structures, collaboration, etc.
Git is a powerful tool, but it's certainly not simple. It's unfortunate that a lot of programming courses add it in as a "here's a five-minute intro to git" sort of thing. As you have experienced, that really doesn't work.
Probably a better way would be to start without git and to have a chance to experience the agony that that entails. Thus motivated, one can appreciate that the hours (!) it will take to get going with git are actually worth the price.
Or, alternatively, you may decide to just stop with the phase of
> It's unfortunate that a lot of programming courses add it in as a "here's a five-minute intro to git" sort of thing. As you have experienced, that really doesn't work.
That is indeed true. Only memorizing the git commands can get you going, but is often not enough. Eventually you'll mess something up and end up throwing more commands at it until you either fix it or give up and reclone the repo.
There are likely other sources available, but what helped me get a good understanding of how git works was Paolo Perotta's "How git works" Pluralsight course.
> but I don't think it's the kind of thing that should (or even could) be taught to teenagers.
Disagree with you here. I think even elementary kids should be taught git and if done right, they'd be able to pick it up quickly.
I think books/manuals/references are the wrong way to teach git though. They should be shown how git works and shown what git is. Text material should be supplementary.
There are youtube videos that walks you through setting up repos, cloning, adding to staging, committing, pulling/pushing, etc. Also, youtube videos that explain the internal structure of git and its objects.
Being shown what a repo, head, master/branches, cloning, etc are and having these ideas explained is far better than being given a sheet of paper with a list of commands/instructions to clone, push/pull, commit, etc. Which sadly is what a lot of incompetent and lazy teachers do.
Git is not for kids, it should be learned only by people that will need to code regularly in the future.
But, if do need to learn git, it's not hard at all.
The problem is that most people teaching git suck at it.
Git has been poorly explained since the begining of time, and because it has a terrible UI, plenty of gotchas and untold prerequisite, you can't really fiddle with it and learn it by yourself without putting a lot of efforts.
It's a shame, because it really is a simple system to use... provided you understand it, which a lot of teachers don't.
I use a toy for 5 years old, that let you construct a 3D structure with magnets, to represent the history, and I stick colored post its on it to represent references.
Important points:
- git log and checkout must be explained in details, as they are a huge source of confusion.
- don't use the famous graphs with revert arrows, they confuse the heck of students
- explain push/pull/clone as late as you can. Most of the course should be on a local repo.
- help them setup diff tools for their particular env. It's harder than you think given the diversity of them.
- you will often have to explain ssh and key management as well. It's not git, but git is close to useless without it. For windows users, you may have to spend an hour of terminal tutorial, putty or not. Use cmder or windows terminal, not cmd.exe.
- do give them a cheat sheet, but only incrementally once they understand the concepts behind them, otherwise they will copy/paste blindly.
- teach them to have a clean working copy before some key operations, and show them why.
- make a big final exercice where they all work on the same code base and push/pull/merge from each others. Twice. Once where you help them. Once to check they can do it now without your help.
- rebase, squash and cherry pick are optional. Do them only if you have plenty of time at the end, and that the rest is well understood.
It's great to see that GitHub is working with repl.it. When GitHub Codespaces was announced earlier this month, there were some musings that it would hurt repl.it adoption. It seems that there are lots of choices available.
I just tried repl.it. I don't like it, but am impressed you have access to a shell (ubuntu, bash).
I tried to delete Main.java, and it won't let you. Fine, so I just erase the whole text file. Then, I place two separate folders w/ src code in them. Code compiles fine, but still prints out "Hello, world!".
Buggy. If you use Main.java, you can still have several packages and it all works, but I don't like that. What I might do is erase Main.java, then you're forced to manually run your program from their bash shell ($ java MyClass). And then it works fine.
I also don't like they're on openJDK 11. All the nice stuff is in 12-14 (text blocks, switch expressions).
Hey, we don't let you delete Main.java because Repl.it is all about having sensible defaults, loading really quick, and not being overly fussy and configurable and allow for everything under the sun.
However, we do have some configuration hooks -- the run command is bound to an entrypoint (in this case Main.java). If you want to configure it, you can do so: https://docs.repl.it/repls/dot-replit
Finally, we're a bit conservative with language versions but will probably upgrade Java soon :)
Are there online dev environments out there that treat shell as the first-class citizen? Where the initial screen is just a command prompt a la Linux without a desktop environment or Windows 3.1 era MS-DOS?
Only a matter of time until MS took aim at my former gitlab + google classroom school. Going to be interesting watching what the frogs do to react.
Git needs a generational ux improvement to see it in early education but I'm interested to see what (if any) pro education/developer tools trickle down that far.
I used to teach kids to code and REPL.it's multiplayer mode was the best tool! It was a little buggy sometimes, but in general collaborative coding tools are excellent for teaching.
The thing to understand is that ten years of conservative government have ravaged education and any respect for intellectual integrity. School is about setting arbitrary exams to prove that any failure of the student is entirely their own. That's why the university system is inundated with milquetoast students who behave as strategically as possible when doing any work.
You had ample guidance in the UK not to use a dead language like VB.net. In my experience the only teachers choosing it for the lazy route of the mountain of lesson material that already existed from vb.net in the 90's/early 00's.
Stop wasting your students time and learn literally anything else.
