拙作の git-gutter.elを紹介します. 作り始めたのは 2年前ぐらいでしたが, 今年当初から問題となっていた高速化の課題など取り組んだので改めて紹介しようと思います. リポジトリ 今年行った改良点 hook-pointでの処理を同期的に行っていたものを非同期に変更 不要な更新を極力行わないように修正 Git以外の対応(Mercurial, Bazzar) 大きな変更は軽量化です. 重いということがいろいろ問題視されていて, git-gutter-plusという fork版ができたりしていました. 自分でもそのあたりを認識していたんですが, よくわからないし, 我慢すれば使えるということで放置していました. しかし今年はスキルも高まってきたし, そろそろできるだろということで取り組んでなんとか対応出来ました. Linux Kernelソースで使うこともありますが, 不満を感じること
We are going to skip instructing you on how to add your files for commit in this explanation. Let's assume you already know how to do that. If you don't, go read some other tutorials. Pretend that you already have your files staged for commit and enter git commit as many times as you like in the terminal box. git branch name will create a new branch named "name". Creating branches just creates a n
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform Windows 365 開発者
こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
分散バージョン管理システムのGitには様々なサブコマンドがありますが、その中の1つである git filter-branch を使用すると、過去のコミットを完全に無かった事にしてしまうなどの強力なコミット履歴の編集が可能となります。大きなリポジトリの特定のディレクトリ以下の内容をコミット履歴付きで別の小さなリポジトリとして取り出したり、ファイルの中に書かれていた生のパスワードを履歴の中から消去したり、というのはよく紹介される例です。 このエントリでは別の例として、コミットメッセージだけを後からまとめて修正する手順をご紹介しましょう。 元々非公開なプロジェクトとして開発を進めていたものを、公開リポジトリに移動したいとなると、やはり機密情報は完全に取り除いておく必要があります。リポジトリに格納されているファイルそのものの内容の編集方法については上記の例で解説されていますが、それ以外の場合として
git 1.7.5がリリースされました。変更点はいろいろありますが、なかでも今回initとcloneに追加された--separate-git-dirオプションに注目してみます。 git init --separate-git-dir=/path/to/repo git initすると普通はカレントディレクトリの下に.gitディレクトリが作られ、そこにリポジトリ情報が格納されます。ワークスペースとリポジトリが単一ディレクトリ下にあるわけですが、以下のような処理をしてリポジトリを破壊してしまった人も居ることでしょう。 $ find -print0 | xargs -0 sed -i 's/foo/bar/g' .. .git/objects/以下が壊滅 この事故はfind -print0ではなくgit ls-files -zを使うことで回避できますが、find以外にも色々と起こりえますし、そも
Git のコマンド体系は全く歴史に学ばず後世に禍根を残す酷いデザインだが、どういうわけか内部構造は大変素晴らしい。特にファイル構造を一旦キーバリュー式データストアに保存するというのは是非参考にしたいアイデアなので調べてみました。 Git 内部データストアの基本機能は、ファイル名を使わず中身だけを保存する事です。ファイル名が無くて後からどうやって保存した中身を取り出すかというと、保存時に SHA-1 という文字列が発行されるのでそれを鍵に取り出します。それでは試しにやってみます。まず準備として新しい Git レポジトリを作ります。 $ mkdir test $ cd test $ git init Initialized empty Git repository in /Users/takashi/tmp/test/.git/ blob 次に、適当な文字列を保存します。 $ echo '適当
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
FAQTo delete a repo, swipe horizontally on top of the project in project list viewTo change the font size, pinch the pageSource Code only fetches repository that is publicly accessible from the InternetVery large projects are probably not supported, in particular, a pull request should finish within 30 seconds
Description A programmer's toolbox for viewing source code ===================================== Importent notice: To delete a repo, swipe horizontally on top of the project in project list view Support multiple repository formats [only via http] ---------------------------------------------- * Git * Hg * SVN * Archive (zip, tar.gz, etc) * Raw (e.g. jquery.js) Optimized storage format for the iPho
Windowsで利用できるGUIのGitクライアントの1つに「TortoiseGit」がある。TortoiseGitはまだ開発段階のソフトウェアではあるが、2009年6月5日にリリースされたバージョン0.7.2.0では多くの機能が実装され、実用的に動作するようになった。本記事ではこのTortoiseGitを用いて、Windows環境でGitによるバージョン管理を行う方法について解説する。 近年、「Git」という分散バージョン管理システムが注目を浴びている。しかしGitはWindowsサポートが弱く、またGUIで利用できる使いやすいクライアントがなかったため、特にWindowsユーザーには導入や利用へのハードルが高かった。そこに登場したのが、Windowsのエクスプローラに統合され、GUIでGitによるバージョン管理が行えるツール「TortoiseGit」である。TortoiseGitはまだ
Runn is a modern resource and capacity planning platform that gets remote teams on the same page. Runn is best suited for project managers, operations leads, resourcing managers and other people responsible for project delivery. Runn has a modern and easy-to-use interface that provides your team with a shared view of all the people and projects in your organization. Plan new work alongside existin
バージョン管理システムと言うとSubversionやCVSが有名だが、近年急速にユーザーを増やしているバージョン管理システムに「Git」 がある。GitはLinuxカーネルの開発リーダーとして知られるLinus Torvalds氏が中心となって、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムである。2005年に開発が開始されて以来さまざまなプロジェクトでの採用が進み、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、有名な大規模プロジェクトで採用されるに至っている。 本記事では、このGitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法や基本的なGitの使い方について解説する。 分散バージョン管理システムとは？ GitはLinuxカーネル開発で用いられることを前提
メモやちょっとしたスクリプトなどをペーストするとgitのリポジトリとして管理してくれるgistというサービスがあります。そのgistにコマンドラインから投稿するツールがあって、それは前に少し紹介したんですが、それをもうちょっと便利にしたものを作りました。 swdyh's gisty at master ― GitHub http://github.com/swdyh/gisty/tree/master gistコマンドとの違いはこんな感じです。 ポストするときにファイルを指定。ファイル名、拡張子つきでアップされる。 ポスト時に複数ファイルを指定できる。 ポスト後、ブラウザで開く。(Macのみ) ポスト後、ローカルにcloneする。 過去のgistにアップしたのを全部のclone、またはpullする機能 gistyを使うと簡単にファイル名と拡張子つきでポストできて、そのままローカルにclon
(Update: I have a new, related post about the Best Git GUIs for Windows.) I’ve been attracted to, and trying out, various distributed source control tools for the last two years, and have come to the conclusion that the most likely “winner” is Git. Git does a great many things right, good progress is being made in the few areas it is weak, and it has rapidly growing popularity. There are many web
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
