2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 Git を使ってファイルを編集した場合、それをいったんインデックスに追加(add)してその後コミットってのが基本的な流れになる。なんかいろいろやってると、ちゃんと add したのかどうかわかんなくなることがある。 そういうときは status コマンド使えばいいんだけど、以前エントリ書いた zsh の vcs_info の機能を使うといい感じにプロンプトに表示できるようになるので紹介する。 zshrc の書き方 こんな風に zshrc に書いておけば OK。 autoload -Uz add-zsh-hook autoload -Uz colors color
お知らせ ('12/4/10) 「msysGit」「Git for Windows」v1.7.10が公開、UTF-8のファイル名に対応('12/4/10 窓の杜) ようやく本家 Git for Windows が UTF-8ファイル名に対応しました。このページで公開していた UTF-8 ファイル名対応 Git for Windows はこれでお役御免となります。一応、資料としてページはここに残しておきますが、今後は本家 Git for Windows をお使いください。 なお、本家にはここで公開しているパッチは取り込まれていません。本家のパッチは Karsteen Blees 氏によるものです。 やっている内容はここに記載した方針と少し違い、POSIX API レベルで差し替えるのではなく、mingw.c 内にある ANSI API 呼び出しを Unicode API に変更しているようで
昨年後半ぐらいから、じわじわとsubversionから Git へと乗り換えつつあります。早いし、リポジトリにアクセス出来ないような状態でも、ドンドンcommit出来るのが最高です。 一方、Mac で OmniOutliner を非常によく使ってるんですが、こいつは、パッケージ形式(フォルダが一つのファイルのように見える）である上に、本体のアウトラインが圧縮されたXMLになっているのです。こいつをSCMで管理しようと思うと、diffが取れなくて困るわけです。 それで、最近、Gitのメンテナの濱野さんの入門Gitを読んだのですが、 そこに書いてある、特定のファイルに対して、テキスト変換してからdiffする方法を用いる方法を使えば、差分を見られるなと気づきました。 具体的には、.git/configにdiff時のテキスト変換ルールを書き、.gitattribute で、そのテキスト変換ルールを
git-rerereってなんかレレレのおじさんみたいですが(Reuse recorded resolution of conflicted merges だそうな)、同じような衝突を何度も起こす状況で使うととっても便利なようで、調べつつ、メモ。 Linusが言っている「無駄なマージコミットやめて」を実現するには、rebaseがあればいいよね、と思ってたんだけど、既に公開しているようなブランチとなると、rebaseするわけにもいきません。 でも途中でちょっとだけ本線とマージしてテストしてみたくなったり、マージした後でやり直して再度マージしてみたくなったりも、しがちです。 そうなるとキツいのが、分かりきってるようなコンフリクトの解消。同じようなマージを繰り返すと、同じように衝突してるところを何度も手で直す作業を繰り返しやるハメになって、泣きそうになります。かといってマージを限界まで我慢して一発
I started to use Git seriously 5 months ago when I sign up for my Github account on September 1st 2009. Before that I was a very happy subversion user. One of the things that I really like about Git is the speed. I decided to use Git from the command line to learn and understand the commands really well. I occasionally used the GUI to perform some tasks that seemed easier to do that way. G
ちょろっと渡邉さんのエントリに補足を。 実用Git 吉藤 英明 (監訳) ちなみに、本には直接関係ありませんが、この本の翻訳もGitを使って進められました。 共訳させていただいた「実用Git」が発売になります 原稿はGitで管理しようと言う話は最初から訳者3人の間で出ていたのですが、原稿を管理するとなると当然read権限も含めたパーミッションの管理が必要でした。3人がgit-daemonを立ててお互いにpullしようかとも思ったのですが、git-daemonを使うと匿名で誰でも読めるリポジトリとなってしまいます。HTTP経由だとWEBサーバによってアクセスコントロールはできますが、速度に不安が残ります。ということでsshがベストなんでしょうが、gitのためだけに3人分のアカウントを作るのはちょっと気が引けました。 そこで、今回使ったのがgitosisです。gitosisについては入門git
githubにpushしてからcommitが間違っていたことに気付きました。以下のようにすると取り消すことができます。 【注意】commitだけでなく変更も失われます。ローカルのソースツリーは残された最後のcommitに戻されます。変更を保存したい場合は使わないでください。コミットログの修正には git commit --amend を使用してください。 git rebase -i HEAD~2 ← エディタが開くので二行目を削除して保存する git push origin +master以下を参考にしました。 How can I remove a commit on github? id:okmount:20091021 古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 githubだけ githubだけを取り消すには別の方法もあります。ローカルは同期
バージョン管理ツールGitの基礎練習です。 Windows XPのコマンドプロンプトでGitの基本的なコマンドを動かしていきます。 Gitを学び始めるきっかけにどうぞ。 （筆者もまだGitを使いこなしているわけではありません。 誤りのご報告、改善提案などは大歓迎です。フィードバックからよろしくお願いします） 目次 はじめに ダウンロードとインストール ファイルをGitの管理下に置きましょう 新しいファイルを追加します 新しいディレクトリを追加します 編集からコミットまでの流れはこんな風に進みます ブランチを使ってみましょう ここまでの作業ログを見ましょう この文書に書かなかったこと 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに Windows XPのコマンドプロンプトで、 バージョン管理ツールGitの基本的なコマンドを動かしてみましょう。 この文書の通りに実行すると、 基本的
Ruby 10年前にRubyといえば7月の誕生石のことか 5.5ポイント活字のことでした でも今はGoogleを30頁めくっても 妻に誕生石をプレゼントすることはできません 宝石店のSEO対策は 日本人の作った言語セットの前では無力なのです この点PerlのLarryさんは巧妙にやりました Pearlは今も6月の誕生石の地位を守っています ここにLarryの奥さんは6月生まれであり Matzの奥さんは7月生まれでないとの仮説が成り立ちます Sinatra なぜWebフレームワークの名前を Sinatraとしたのか皆目検討も付きません シナトラハットがトレードマークですから そうなんでしょうがそれにしても... Railsとは違うMyWayを行くという意味でしょうか それとも裏社会との繋がりを暗示しているのでしょうか まさか「支那虎」ですか？ ー名は体を表すー といいますが これほどに体をイ
(hgの部分をgitに置き換えてもOK) bzrとhgを比較するベンチマークだと、特にcloneにおいてbzrが遅い。 bzrとhgにおける、リポジトリとブランチの扱いの違いについて まず、bzrは色々な使い方に対応できるようにしようとしてリポジトリとブランチと作業ツリーを分離して設計している。 bzrの .bzr というディレクトリは、作業ツリー、ブランチ、リポジトリを含む場合もあれば含まない場合もある。 bzr init-repo --no-tree foo # foo/ はリポジトリ bzr init foo/bar # foo/bar/ はブランチ bzr co --lightweight foo/bar baz # baz/ は作業ツリーさて、bzrのリポジトリ、ブランチ、作業ツリーとは何者か。 リポジトリというのは、リビジョンを格納するものだ。リビジョンとはあるディレクトリツリ
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
We’re getting things ready Loading your experience… This won’t take long.
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
git function prompt-git-head-name() { local git_dir="$(git rev-parse --git-dir 2>/dev/null)" if [ -z "$git_dir" ]; then return 1 fi local head_name='' local additional_info='' if [ -d "$git_dir/rebase-apply" ]; then if [ -f "$git_dir/rebase-apply/rebasing" ]; then additional_info="REBASE" elif [ -f "$git_dir/rebase-apply/applying" ]; then additional_info="AM" else additional_info="AM/REBASE" fi he
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
