Using TortoiseGit (I'm trying to avoid command line usage) how does one delete all commits that accended from a certain commit, and "get back in the past" (example usage: continued doing something, figured I didn't like where it was going, and decided to go "back" disregarding all in between).
In short I wish to go 5 commits "back", and delete them afterwards.
From the command line, you could use the revert or reset command. TortoiseGit should have similar commands, perhaps you can access them by looking at the commit log?
(I haven't used TortoiseGit so I can't check it)
I've never used Tortoise anything (unless you count the electronica group), but I'll give you this info in case you don't find a way to do it with the GUI or you end up deciding to go CLI after all.
As @Tuxified mentions, you can accomplish this with git reset --hard <COMMIT>. You need to specify a commit, which can be done in any of an intimidating panoply of possible ways; the most common have forms like HEAD~4, which specifies a commit 4 commits before the head of the current branch, and deadbeef42, which specifies a commit whose SHA1 starts with 0xdeadbeef42. If you're running linux or OSX, you can get the full details on commit specifiers via man git-rev-parse, under "SPECIFYING REVISIONS".
You can also rename the current branch (git branch -m new_branch_name) and then create a new branch with its head at the place you want to revert to. The advantage is that if you end up wanting to use all or some of the stuff you did there, you can still readily access it; and if you typo the commit, you're saved from a big holycrap moment. Plus git branches are super lightweight so the only real downside is that there will be another branch listed. To make the new master branch you would use git branch master <COMMIT>, and then you check it out. So the net effect here is the same as the first option, except that you still have your old changes saved in the branch new_branch_name. You can even merge those changes back in later, after new commits to master, if you feel like it.
Note that either of these techniques are considered "rewriting history" and will cause issues if you're sharing your repo with others. If you're being smart and pushing to a backup repo in cloud city or another pc, you will have to fix things on that end before you can push to it again.
This is probably way more info than you need right now, but if you end up using git a lot you'll probably want to learn this stuff at some point. Sorry I don't know how to use Tortoise...