Git のローカルリポジトリを更新して Homebrew を最新に - CHROMA
Vim でタグ機能を使おうと思って、ctags を Homebrew でインストールしようとすると次のエラーが出た。 $ brew install ctags /usr/local/bin/brew: /usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory /usr/local/bin/brew: line 21: /usr/local/Library/brew.rb: Undefined error: 0 「homebrewユーザーがYosemiteにアプグレしたらbrewコマンドが使えなくなった問題解決法 - 現代版徒然草 (生まれてきたら負け)」という記事を見つけ
さくらインターネットの VPS に入れた Debian wheezy で gitlab 動かすメモ - progd
gitlab の 5.2-stable を入れた。 公式のインストールマニュアル 通りにいかなかった部分を記述する。 /usr/bin/python2 というシンボリックリンクを作る マニュアルにちゃんと記載されているのだが、 python のバージョンが最初から 2 だったので見落としてしまっていた。 redis のバージョンを 2.0.0 以上にする apt で入るバージョンは 1.2.6 のため、 gitlab のチェックコマンドで警告となる。 apt で入れたものを削除し、ソースをビルドしてインストールする。 % sudo apt-get remove redis-server % wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz % tar xvf redis-2.6.13.tar.gz % cd redis-2
Gitでリモートリポジトリを巻き戻す - tmtms のメモ
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
GitのCommit中のAuthor名およびCommitter名を変える - idesaku blog
ローカルで持っているGitリポジトリをGitHubにpushしてしまいたいなぁ、と思ったのだが、pushする直前にAuthorおよびCommitterとして自分の本名を使っていることに気づいた。そういえば、Gitを使い始めたころはuser.nameに正直に本名を入れていたなぁ…。 そのままでも大した問題はないのだが、ネット上ではidesakuで通すことにしているので、こいつらを修正した。その際、あまり使わないコマンドを使ったので、作業ログなど残してみる。 さて、どうすればよいか。すぐに思いついたのは、git-rebaseを使うことである。 ところで、Gitは全てのコミットにAuthorとCommitterの二つの名前を記録している。これは、オープンソース分野でよくある「パッチを書いた人(Author)と、それをリポジトリにコミットした人(Committer)が違う」ケースに対応するための措
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない 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 submoduleの更新 - rochefort's blog
2017.8.31 追記 この記事は間違っています。正しくは下記でした。 git submoduleの更新方法を勘違いしていた 昔書いた記事を参考にしてくださった方がいて、 でも「git submodule updateで更新できないよ」と。 gitのsubmoduleだけを最新版にしたい場合のコマンドメモ - Reinvention of the Wheel 私自身もgit submodule updateで更新できると思ってました。 というか、一度も更新処理試してなかった。 結論から言うと これでOKでした。foreach便利。 $ git submodule foreach 'git pull origin master' $ git submodule update ですが、no branch になってしまってるsubmoduleがあったので、pullするのはこっちの方がいいかもし
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
VCS において Git が革新的な点 - kなんとかの日記
はっきりいって、Git の CUI は使いづらくてわかりにくい。サブコマンド名やオプションが開発者目線で決められており、ユーザからどう見えるかという視点が欠けている。その点、Subversion はよく考えられて洗練されていたし、それを受け継いだ Mercurial も使いやすい。Linus は Subversion をこき下ろす前に Git のコマンド体系を整理すべき。 ただ、Mercurial などと比べて Git が革新的にすごい点がひとつある。それは、バージョン管理システムに Garbage Collection (GC) の概念を持ち込んだことだ。みんなあまり注目してないと思うけど、こいつはほんとうに kool な機能だ。 GC はもちろんプログラミング言語の分野での概念だけど、そのプログラミング言語の世界では、GC が一般的に使えるようになることでプログラミングスタイルが大きく
バッドノウハウからグッドラッパーへ
「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。 目次 はじめに 有益なものを生み出さなければ「奥が深い」とも呼ばれない バッドノウハウをグッドラッパーで隠そう 本当によくないシステムとは よびかけ 補足：Perlとバッドノウハウ いろんな方からのコメント 反応リンク 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに 高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。 有益なものを生み出さなければ「奥が深い」とも呼ばれない もしも「奥が深い」システムが何
git-助けてというすごく便利なエイリアスを作った - 鳩舎
こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！
git/空のディレクトリが消えているんですけど - TOBY SOFT wiki
はじめに † 空のディレクトリをコミットすると上手くいっているように見えて、 cloneとかしてきたりすると、消えてなくなってたりする件について。 どんな時に消えるか？というのがイマイチわからんけど。（←メカニズムの詳細希望） cvsの仕様を引きずっていてこの仕様は欠点だと思います！！(Subversion(svn)は大丈夫です) gitではファイル単位での管理ぽくて、仕様っぽい… ↑ 解決方法 † gitで空のディレクトリを追加するには、空のディレクトリをなくす、よくみかける例では「空の.gitkeepファイルを置く」 ということになっているようです。 ※ 私見ですが、git以外も使うかもしれないし、極力依存っぽいファイルは置きたくないこともあります。その場合はディレクトリの説明を書いた readme.txt を置く等でもいいのではないかと。 ↑ 解決例 † 一般的な.gitkeepを追
git submodule - みずぴー日記
http://d.hatena.ne.jp/woremacx/20080308/1204986198のように、gitで外部レポジトリを扱えるようにする方法。 外部レポジトリの追加 git submodule addすると、外部レポジトリをサブモジュールとして取り込めるようになります。 # cloneする $ git clone git://example.com/repos/private/ $ cd private # git://example.com/repos/external/を追加する $ git submodule add git://example.com/repos/external/ # commitしておく $ git commit -m "Add submodule" $ git push 外部レポジトリ内での作業 外部レポジトリで作業したときは、そこでコミットする
github/gitignore at master - GitHub
A collection of .gitignore templates This is GitHub’s collection of .gitignore file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files. For more information about how .gitignore files work, and how to use them, the following resources are a great place to start: The Ignoring Files chapter of the Pr
Kanon LAB: Top
Kanon LABへようこそ Kanonは、プロジェクト管理のための総合ソリューションです。チケット(Trac)、バージョン管理(Git,Subversion,Mercurial,Bazaar)、CI(Jenkins)の3つの機能を統合して提供しています。 名前の由来 カノンとは、キリスト教の聖書教典のことで、クラシック音楽のカノン (同じ旋律が繰り返し演奏される輪唱)のことでもあります。クラシック音楽のカノンの 中でも有名なパッヘルベルのカノンは、本来弦楽器のために書かれたものですが、 ピアノ独創やポップ、ロックなど、様々な分野でそのメロディはモチーフとして使われ ています。Kanonは みなさんのプロジェクトの教典になるように プロジェクト毎にアレンジして使えるように カノンの用にメロディを変化させながら何度も詠唱できるように という意味をこめて名づけました。 インストール方法 # h
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
pathogen.vimを使って、git submodule下で管理しているvimプラグインの更新 - sugilogのブログ
追記：2011/11/01：PathogenからVundleへ、そしてNeoBundleに移行しました。 http://d.hatena.ne.jp/sugilog/20111101/1320158226 pathogen.vimを使って、vimプラグインを管理しています。 http://d.hatena.ne.jp/sugilog/20110322/1300766495 でもアップデートができない、なんてことも。 ぐぐってみると、以下のようなことをしてる人がいる。 git submodule foreach 'git pull origin master'submodule全てに対してのmasterをpullしてくる。 とりあえず、origin masterをpullしてきてもいいのだけど、これって本当に管理方法としてあっているのだろうか？
Mac で git 等を利用する際に UTF-8-MAC 問題を解決する方法。 - D.
Mac で主に git などを利用すると、日本語の濁音ファイル名がおかしくなる問題がある。通称 UTF-8-MAC 問題という。詳細は以下を参照のこと。 UTF-8-MAC http://macwiki.sourceforge.jp/wiki/index.php/UTF-8-MAC 対策 いろいろ解決方法は考えられるのだが、ここでお手軽な方法を紹介する。 まず SSH で接続可能な Linux サーバーを適当に用意する。さくら VPS でも Amazon EC2 でも自宅サーバーでも何でも良い。 次に Macfusion をインストールする。これは Mac で利用できる sshfs クライアントである。 http://www23.atwiki.jp/selflearn/pages/55.html あとは、この Macfusion で Linux サーバーのファイルシステムをマウントする。こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to fix broken submodule config in git?
[git 1.6.0.2] submoduleを使おう！その1：add, status - satoko's blog - s21g