How can I debug git/git-shell related problems?
How can I have some debug information regarding git/git-shell? I had a problem, that user1 could clone a repository without problem, while user2 could clone only an empty one. I had set GIT_TRACE=1, but nothing useful was told. Finally, after a long trial and error, it turned out that it was a permission problem on a file. An appropriate error message could short-circuit this problem.
Git Subtree: Alternative to Git Submodule | Atlassian Git Tutorial
Products Featured Developers Product Managers IT professionals
submoduleとsubtree-mergingの使い分け - Qiita
gitで外部リポジトリを取り込んで利用するには、submodule(サブモジュール) とsubtree merging(サブツリーマージ)の2手法があります。 私の観測範囲内では、サブモジュールはよく利用されていますが、サブツリーマージは目にしません。 そこで、サブツリーマージを試してみての使い分けや思ったことをつらつらと。 大雑把な要点を最初に書いておく 外部リポジトリを外のものとして取り込むならサブモジュール 外部リポジトリを取り込みつつ、中のものとして手を加えていくならサブツリーマージ git初心者にはサブモジュール(異論ありそう) サブツリーマージ使ってみた github.com/marutanm/dotfiles 中身としては、よくある環境設定ファイル一覧です。 前提として、 tmux.conf(gistにおいていた) vim設定(githubにおいていた) zsh設定(gith
git rebaseを使うときのルール | Yakst
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
git rebase -i はやっぱりイケてる件【git】【rebase 】【iオプション】 - DRYな備忘録
はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ
gitのコミットの歴史を改変する(git rebase) 1 / 2 · けんごのお屋敷
git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し
git subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
Git Submodule の代替: Git Subtree | Atlassian Japan 公式ブログ | アトラシアン株式会社
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか？ 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
develop ブランチなんてオワコン
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
任意のリビジョンのファイルを別名で保存する方法(Git) - Qiita
gitでgit checkout <commit> -- <file>で任意のリビジョンに戻せることは知っていたのですが、「別名で保存したい時ってどうやってやるんだろう？」と前から思っていました。(ググっても欲する情報にヒットしない...) で、やっとわかったので折角なのでアウトプットしておきます。 git cat-file blob <commit>:<file> これで標準出力に出力されますので、ファイルにリダイレクトすればOK！ 例 git cat-file blob git cat-file blob e4426a7:.vimrc > vimrc_e4426a7 まぁしかし、これ結構使いそうなのに入門書とかに載ってないよねぇー不思議。 大抵はgit diffを使うっていうのはあるけど... 追記 git show <commit>:<file> これでもできた。(thanks to
LINE Serverの開発とリリースプロセス « LINE Engineers' Blog
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
既に削除したリモートブランチを一覧から削除したい - rela1470のブログ
社内でちゃんとgitを使っていると､すごくbranchの増減があり、 fetchしたタイミングによってbranchの存在情報がバンバン入っていきます。 しかし、その開発branchが削除されても、 git branch -a で削除されているはずのbranchが表示されてしまう場合があります。 これは.git/objectsフォルダにゴミオブジェクトが残っているからです。 実際はどこにもリンクしていないオブジェクトですので、まとめて削除してしまいましょう。 どこにもリンクしていないオブジェクトを全て削除する命令が「prune」です。 こんな風に使います。 git fetch --prune pruneしても通常は全く問題がないはず（どこにもリンクしていないオブジェクトを消しているだけなので）ですので、自分ではfetchする際には必ずpruneオプションをつけています。 実際、自社の開発フェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git pretty — justin hileman dot info
Git man page generator
入門書には載ってない Git & GitHub Tips
NetBSD Problem Report #48844: git rebase is broken because dot commands are broken in sh(1)
https://github.com/hail2u/github-cheat-sheet/blob/master/README.ja.md
http://www.twinbit.it/en/blog/storing-sensitive-data-git-repository-using-git-crypt
GitHub - AGWA/git-crypt: Transparent file encryption in git
消したはずのリモートブランチがローカルで表示されるので削除する - Qiita
