The biggest problem I have with branches in git is that there does not seem to be a simple way to delete a branch in a version controlled way.
For me, the whole point of version control is to be able to go back and look at what I did earlier. The idea of doing destructive deletes of branches is madness. However, if you don't, you end up in the situation I have now, where my project has over a hundred branches, most of them minor changes or attempts at things that didn't pan out.
The overhead this causes (including, just scrolling through the list of branches) now makes me less eager to branch in new projects I work on. In svn, I would just do 'svn rm branches/stupid-idea' and it would be gone, but still exist in the history if I ever wanted it.
You can always replace the branches with tags (git tag failed-branch-mybranch mybranch && git branch -D mybranch). That way, you still will have access to the unmerged commits later, but your list of branches is clean. Your tags will bloat up, but I personally don't go through my tags nearly as often as my branches.
You don't necessarily want to publish all branches to your main project repository, just long-running ones or those that many people hack on. For most branches, especially experiments, use a branch in a personal repository instead. You can merge from that repository to the main repository if the experiment works out, and otherwise leave it around as an experimental repository and/or archive it. Look at git.kernel.org for an example: linux/kernel/git/torvalds/linux.git only has a "master" branch, but numerous other repositories exist for experiments and development.
That said, I'd also love to see a mechanism for version-control of historical branches. Perhaps something like a reflog with expiration turned off.
You can namespace your branches. Once you're done with one, you can rename it to merged/essential-dingbats-feature or discarded/dingbats-are-in-fact-useless.
For me, the whole point of version control is to be able to go back and look at what I did earlier. The idea of doing destructive deletes of branches is madness. However, if you don't, you end up in the situation I have now, where my project has over a hundred branches, most of them minor changes or attempts at things that didn't pan out.
The overhead this causes (including, just scrolling through the list of branches) now makes me less eager to branch in new projects I work on. In svn, I would just do 'svn rm branches/stupid-idea' and it would be gone, but still exist in the history if I ever wanted it.