git-svnを使っていて、git svn dommitするときに、 掲題のようなエラーメッセージが出た場合、リモートリポジトリとローカルリポジトリのトラッキングブランチの同期が取れていない事が原因かもしれません。

例えば、SVNリポジトリ上で削除されているブランチが、ローカルのgitリポジトリに残ってしまっている場合、以下のようにリモートトラッキングブランチを削除する事で問題を解決できる可能性があります。

   1  % git branch -D -r <branch name>

しばらく前にインストールしていた git-1.6.0.4 には無かった機能なのですが、最近のGit (1.6.4.4で確認) には git svn branch というSVNリポジトリのブランチを作成する機能がついているようです。

   1  % git svn branch <branch name>

これで指定したbranchがリモートで作成されます。 あとは、こんな感じでリモートトラッキングブランチをチェックアウトすればOK.

   1  % git checkout -b <branch name> <branch name> --track

便利ですね。

[追記] 最後の方、ちょっと不明瞭だったので修正しました。

---

amend使ったこと無かったのでメモ。

前提

   1  # edit comment.rb    
   2  # edit product.rb  
   3  git commit -am "wrong commit"

(上記のファイルを修正、product.rbを間違ってコミット)

そして、下記の順で変更・修正します：

間違ってコミットしたファイルをコミットから外す

   1  git reset HEAD~1 app/models/product.rb

(変更は維持されたまま、コミットから外されます：unstageという)
(こうすると、# Changed but not updated:のところに出てくる)

コミットメッセージの修正

   1  git commit --amend

(メッセージを修正できる) (＋上でcommitから外したファイルを確定する)

amend時にコミットメッセージを再利用する

via http://www.jukie.net/~bart/blog/git-amend

@onoさんにこの記事を教えて頂いたのですが、筆者の方はコミットメッセージを再利用するgit ammendコマンドを作っておくという技を使っておられるようです：

   1  git config --global alias.amend 'commit --amend -C HEAD'
   2  
   3  #今後(メッセージはそのままで)コミットを修正したい時は下記でOK：
   4  git amend

さらに流れ的には、

1. コミットしてから、
2. さらにファイルを編集、
3. それをgit addでファイルを追加、
4. git commit --amendで3で追加したのを直前のコミットに加える

というワークフローを使って運用。超こまめにコミットして作業したいときに便利そうです！

数字だけのタグだとうまくcoが出来なかった覚えがあるので、renameしました。あと、commitハッシュはフルでなくても、最初の5桁くらいで大丈夫だと思います。

タグで使っているcommitハッシュを取得

   1  % git rev-parse 1.1
   2  97f4c33e9a35255b8f8506ffa90ab70605ccf74f

タグのつけ直し

先程入手したcommitハッシュを使って

   1  git tag -a -f v1.1 97f4c33e9a35255b8f8506ffa90ab70605ccf74f

完了と思ったら、つけ直しではなく同じcommitハッシュに別のタグをつけるようになっていまようです。なので、不要なタグを削除します

タグの削除

   1  % git tag -d 1.1
   2  Deleted tag '1.1'

gitリポジトリに間違って追加してしまったファイル等を完全に消去する方法を紹介します。

   1  % git filter-branch -f --index-filter 'git update-index --remove "filename"' HEAD
   2  % git push --force

ディレクトリを削除したい場合は、ディレクトリの中身のファイルを１つずつ全て削除します。

ポイント

• 上記のコマンドはワーキングディレクトリのROOTで実行する必要があります。
• "filename"はワーキングディレクトリのROOTからの相対パスで記述します。
• "-f" オプションはつけておいた方が良いです。

gitを使ってリモートリポジトリからfetch&mergeする場合、 git pullを使う事ができます。 git pullは

   1  % git pull origin master

のようにリモート名とブランチ名（正確にはrefspec）を指定して使うのですが、以下のような設定を行うと、これを省略できます。

.git/config

   1  [branch "master"]
   2    remote = origin
   3    merge = master

Today I collided with an issue regarding a git repository. If a subdirectory of your repository has .git as a member, it shadows the subdirectory. So thus you can't sense its member even if you would type git status and check .gitignore.

今日はgitリポジトリに関する見つけにくい問題に遭遇しました。 リポジトリのサブディレクトリの中に.gitディレクトリがある場合、そのサブディレクトリ以下が隠されてしまい、git statusや.gitignoreを見ても存在が見えなくなってしまいます。

gitを使っていてローカルでつけたタグを、リモートにpushする場合は、

   1  % git push --tags

逆に、リモートのタグ情報をローカルに持ってくる場合は

   1  % git pull --tags

これでok

via http://news.ycombinator.com

http://www.viget.com/extend/backup-your-database-in-git/

production環境のDBをダンプして、gitのリポジトリに格納してしまおうという提案。

実際にSpeakerRateというサイトのデータはそれでバックアップしているそうデス。驚きです。crailgslistレベルのトラフィックだとうまくいかないかもしれないけれど、small to mediumサイズのwebアプリなら大丈夫だろうとのこと。

submoduleネタをゲットしたのでメモ。

@githubのtwt：

GitHub gem builder will now pull in submodules prior to the build.
4:05 AM Apr 9th from web
http://twitter.com/github/status/1478454260

てことは配布しているgemではsubmoduleをpullしてくれるってことでしょうか！！
いいですね！

しかしtarball builderはsubmodule未対応

@github is there any plan to have the tarball builder do the same thing?
http://twitter.com/larrywright/status/1478514289

@larrywright not at the moment. We use git-archive which, for some unknown reason, doesn't support submodules.
http://twitter.com/github/status/1478579621