I setup password caching, but it's odd in that I thought that I'd already done that. From an e-mail to github, it seems that they changed things a bit:
Hello Thufir,
What you are seeing is that all newly created repos are now using Smart HTTP instead of SSH by default. We have a help article here that explains how to change it here: https://help.github.com/articles/why-is-git-always-asking-for-my-password
We also have a blog post about it here: https://github.com/blog/1104-credential-caching-for-wrist-friendly-git-usage
The oddity which I see is that I seem to recall following those exact directions some time ago, for caching the password.
Also, isn't there a better approach, with a public key perhaps? I'm not quite sure where my password is cached, but I know that it's not such a great idea. (I'm on Linux so cannot use the suggested .exe in the e-mail.)
You can use SSH to connect to Github. They have an SSH key guide in case you haven't added your public key to your Github account yet, and then all you have to do is use the SSH repo URL instead of the HTTPS repo URL to clone your repository.
You can find the SSH url by clicking the button next to where the repo URL is listed. If you've already cloned the HTTPS repository you can add a new remote pointing at the SSH URL and use that for push/pulling password-free!
You'll have to be more specific about what you mean about a "better approach", because depending on how you interpret that, you're going to get different answers. Try refining your questions a bit more so they are more specific and concrete.
A deeper look at what you are talking about led to me to discover git-credential-store, which seems to indicate that the passwords are stored in plaintext.
As I understand it, you'd be relying on the security model of the OS to ensure that the file isn't accessed or changed by unauthorized parties. None of this information appears to be hashed with a salt. In short, the security of your account would be highly dependant on the security of the machine where you are storing the cache.
As for why HTTP support is a big focus for git in the future is well-explained here.
As a summary though, HTTP is standard and has high adoption, it supports both secure and insecure exchanges combined with the fact that port 80 is open on most boxes and firewalls anyways, makes using HTTP a relative no-brainer.