git push error

% git push origin master
を実行したら

 ! [rejected]        master -> master (non-fast-forward)

error: failed to push some refs to (...略) 
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'non-fast-forward'
section of 'git push --help' for details.

となってしまった。思い当たることとしては OS を再インストールして git repository へのパスを変えてしまったことと git のバージョンをあげたこと。

% git push --help
を
/non-fast-forward
next していたら次のような文章があった。

       There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even
       when you are pushing into a repository nobody else pushes into. After you push commit A yourself (in the first picture in this
       section), replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed A
       out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A (and started
       building on top of it), you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a
       case where you do mean to lose history.

辞書をひきつつ 2 回読んでみたけどもなぜこうなってしまったのか？や、どうすればいいのか？は読み解けない。

Google にて "non-fast forward"
を検索してみたところ
http://blog.digital-squad.net/article/132085683.html
に

こういうときは --forceオプションをつけてやることで強制的にpushできる。
git push origin master --force

とありまして --force をつけて試してみるとあっさり git push に成功しました。とても助かりました。
一時は ssh-keygen で鍵を作りなおさなくちゃいけないのかと思った。

さて、落ち着いてから上の英文を読みなおすと

you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a
       case where you do mean to lose history.

... "git push --force" はあなたが歴史を失うケースに備えての予備のメソッド?
間違えて読んでる可能性大だけど歴史を失うとはどういうことだろ。
OS 再インストールしてパスが変わってるから何かが失われたってことなのかな。何が？

% git log
ちゃんと動いてる。最初からのlog もみえてる。はて？

+++ 教訓 +++

% git push midore@github.com:midore/mblogger.git

などしても

...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

エラーになる。だからといって ~/.ssh/ の中の鍵のパーミションが関係してる？とか考えない。

remote 先を明示したい時は

% git push git@github.com:midore/mblogger.git

~/.gitconfig や ~/.ssh/ にゆるぎない自信があれば

% git push origin master

で OK.

[後日談]
入門Git(秀和システム) を読みましてこの時何がおこっていたか？を考えてみました。
p81 に non fast forward エラーについて解説がありました。

私の場合OS を入れ替える前にバックアップをとり、OS を新規インストールした後にこのバックアップから
local git repository を読み込んだわけだけどもバックアップした直後で新規インストールする直前に
github.com/midore/mdiary に対してgit push　しちゃっていたのかもしれません(驚)
だとすればこの挙動はものすごく納得がいきます。
バックアップとった後に git push した記憶がない自分が怖い...

私がうっかり git push していたのならば上記の対処は正しいやり方じゃなかったようです。
% git pull
を使い
(pull 先は add remote した先を指し、clone したproject の場合は自動的にclone 元になるそうだ)
github.com においてあるリポジトリの最新コミットと手元のリポジトリのコミットをマージさせるべきでした。
git pull してみればどこで conflict していたか明らかになったはずなのでした。
（ただしgit push した記憶がない状態で pull する勇気をもてたかは不明）
conflict メッセージがでていたのならそのファイルを編集した上でcommit するべきだったのかもしれません。