A was the initial commit, but now you want B to be the initial commit. git commits are whole trees, not diffs even if they are normally described and viewed in terms of the diff that they introduce.

This recipe works even if there are multiple commits between A and B, and B and C.

# Go back to the last commit that we want
# to form the initial commit (detach HEAD)
git checkout <sha1_for_B>
# reset the branch pointer to the initial commit,
# but leaving the index and working tree intact.
git reset --soft <sha1_for_A>
# amend the initial tree using the tree from 'B'
git commit --amend
# temporarily tag this new initial commit
# (or you could remember the new commit sha1 manually)
git tag tmp
# go back to the original branch (assume master for this example)
git checkout master
# Replay all the commits after B onto the new initial commit
git rebase --onto tmp <sha1_for_B>
# remove the temporary tag
git tag -d tmp

In the case of interactive rebase, you have to do it before A so that the list will be:

pick A
pick B
pick C

to become:

pick A
squash B
pick C

If A is the initial commit, you have to have a different initial commit before A. Git thinks in differences, it will work on the difference between (A and B) and (B and C). Hence the squash not working in your example.

In the case that you have hundreds or thousands of commits, using kostmo's answer of

git rebase -i --root

can be impractical and slow, just due to the large number of commits that the rebase script has to process twice, once to generate the interactive rebase editor list (where you select what action to take for each commit), and once to actually execute the re-application of commits.

Here is an alternative solution that will avoid the time cost of generating the interactive rebase editor list by not using an interactive rebase in the first place. In this way, it's similar to Charles Bailey's solution. You simply create an orphan branch from the second commit, and then rebase all the descendant commits on top of it:

Because the old and new initial commits have no common ancestor you may get some unnecessary conflicts as git tries to apply the whole history of master onto a, even though they have a tree in common. By using the --onto option to git rebase you can tell git the correct place to start applying.
–
Charles BaileyJan 12 '09 at 18:53