git stash はコミットとしてデータ保存してるんだということを知って、調べると色々分かって面白かったという話。 きっかけはこのツイート git cat-file -p refs/stash するとわかるけど、タダのcommitなんだね— エロリツイート (@wand_ta) 2019年11月27日 refs ステージングされた変更とローカルの変更がある状態で stash する コミットが二つできてる。WIP on ...というマージコミットと index on ...というコミット。 WIP on ...にはローカル変更が入った作業ツリーの状態が、index on...にはインデックスの状態が保存されている。 ほんとだ。ローカルの作業ツリーに対するコミットオブジェクトと、その親にインデックスの内容に対するコミットオブジェクトが作られてて、その親が変更元のHEADという構造なんですね。

みんな知ってるものだと思ったけど、あまり周りで知ってる人がいなかったのでブログに書いた。 こういう釣りタイトルっぽいブログ、一度書いてみたかった。 参考 Checking out pull requests locally - User Documentation 参考というか、そのままだけど。 方法 Pull Requestの ID を BRANCHNAME にfetchします。 *1 $ git fetch origin pull/ID/head:BRANCHNAME ブランチをcheckoutします。 git checkout BRANCHNAME これだけです。forkした人のリポジトリを remote add する必要はないです。 おまけ マージ後のsha1 ちなみに、Pull Requestのマージ前だと、 pull/ID/merge を使うこともできます。 $ git fet

git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って

特にプロトタイプ的なコードを書いている時、将来的にはオプションなどで変更できるようにする予定のモノをコードに直書きで埋め込んだりするよね。簡単なものでは1行だったり、複雑なものだったらモックのクラスだったり。 今回のユースケースは「もうこのモックは必要ないな」と思って削除して、しばらくしてからまだ消しちゃダメだったと気づいたケース。 下記のコードのCODEってところを削除する。 sIDENTIFIER = "[^-+#: ]+" IDENTIFIER = re.compile(sIDENTIFIER) ENHANCER = re.compile("\+\s*(%s)" % sIDENTIFIER) SUPPRESSOR = re.compile("-\s*(%s)" % sIDENTIFIER) BODY = re.compile(":\s*(%s)" % sIDENTIFIER) COD

heroku みたいな git push で自動デプロイする方法として、よく post-recceive フックで git pull する方法が載っているけど、 自分の場合、それがうまくいかなかったことがあったのでメモ。 よくある post-receive フックの内容は以下の通り。 #!/bin/sh ( cd /path/to/repository git --git-dir=.git pull origin master ) 普通の使い方をしている限り、この方法で問題なく動作する。 が、うっかり git push -f してしまうといろいろとややこしいことになる。*1 というのも、git pull は結局 git fetch + git merge でしかないので、(本当はなかったことにしたい) 以前の HEAD と新たな HEAD をいい感じにマージしてしまうからこんなことになる。

直前のコミットをやり直したいときは、git commit --amend を使うと可能だ。そして、さらに昔のコミットをやり直す(書き換える)ときは、git rebase -i を使う。 git rebase -i を使うと、引数にとったコミット以降のコミット系列に対して、コミットの書き換え、削除、統合を行うことができる。 次の課題をこなすことを目標としながら、git rebase -i の動作を追っていこう。 課題「最新のものから古いほうへ3つ分のコミット(HEAD, HEAD~1, HEAD~2)のログメッセージを書き換えたい」 git rebase -i の起動 まず、変更したいコミットで一番古いものより一つ古いものを引数にして、git rebase -i を実行する。この場合は HEAD~3 である。 $ git rebase -i HEAD~3 すると、エディタが rebase コ

Note: The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch. However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch. About linked

社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。

追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自　己　責　任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─　一人で使ってるよ ｜　　　｜ ｜　　　├─　手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜　　　｜

Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi

.gitmodulesファイルから該当する行を削除 [submodule "path/to/hoge"] path = path/to/hoge url = git://github.com/hoge/hoge.git .git/configファイルから該当する行を削除 [submodule "path/to/hoge"] url = git://github.com/hoge/hoge.git で % git rm --cached path/to/hoge % git commit[git 1.6.0.2] submoduleを使おう！その2 - satoko's blog - s21g

色々やったけどこれで出来た。 参考 https://largo.homelinux.org/blog/?q=node/18 環境 サーバ: CentOS 5.3 クライアント: Mac インストール # yum -y instal git-core WebDAVの設定 /mnt/drbd/www/gitをwebdavで公開する htpasswdは/mnt/drbd/www/.htpasswdにあるのが前提 apacheでwebdavの環境構築済みであるのが前提 # vim /etc/httpd/conf.d/git.conf Alias /git /mnt/drbd/www/git <Location "/git"> DAV on SSLRequireSSL AuthType Basic AuthName "Git" AuthUserFile /mnt/drbd/www/.htpasswd

Git に挑戦して悪戦苦闘の末に WebDAV 経由で使えるようになったのでメモっとく。 メインリポジトリを置くサーバは CentOS 5.4 に git-1.5.2.1-1.el5.rf クライアントは Win7 + msysGit git version 1.6.5.1.1367.gcd48 Apache の WebDAV 設定 /var/www/gitrepos/ 以下にリポジトリを置くことにして、外からは http://＊＊＊/git/リポジトリ名 でアクセスするようにする。 設定は git.conf に書いて、再起動 # emacs /etc/httpd/conf.d/git.conf Alias /git/ /var/www/gitrepos/ <Location /git/> DAV on AuthType Basic AuthName "Git" AuthUserFile

WebDAVでpushできるGitリポジトリを作ったのでメモ。 以下は、 ロカールにあるGitリポジトリ「hoge」を、 WebDAVでpushできるGitリポジトリとして「http://foo.com/git/hoge.git」で公開したい! 場合の作業手順です。 環境 使用した環境は次の通り。 クライアント OS: WindowsXP Git: Cygwin版Git v 1.5.5.1 公開先サーバー(foo.com) OS: CentOS 4 Git: v 1.5.2.1 Apache: 2.0.52 概要 apacheにWebDAVの設定をする。 リポジトリ「hoge」の裸(bare)のクローンを作る。 作成したクローンをサーバーに送付 クローンを公開リポジトリに配置し、公開設定をする。 クライアントからcloneしてみる。 1.apacheにWebDAVの設定をする。 公開サーバ