本の虫: GCCのgit移行が難航中
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
ブラウザ上で完結するGit組み込みエディタ作っている - mizchi's blog
PWA-Editor(仮) デザインとかは適当なんだけど、コンセプト的にどこまで実装可能かの検証を一通り終えた。頑張れば本格的なものが作れそう、という手応えがある。 IndexedDB バックエンドに fs 動かして ismorphic-git を動かしている。 UIは全然足りないが、 ポテンシャル的には GitHub に push できることも検証済み。ServiceWorker でオフラインで動くようになっている。 デプロイ先は https://nervous-kilby-73c9b0.netlify.com/ 開発中のものなので、予告なく互換が壊れることがある。 動機 Chromebook 買ったんだけど、やはり開発機として使うには厳しい気持ちがあった。主にまっとうなエディタがないのが辛い。cloud9 とか試したけど、辛かった。 フロントエンドのツール周りはJSで完結して PWA
[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita
ツイッタフォローしてやで(ﾎﾞｿｯ https://twitter.com/JotaroUT いろいろ使ってみたけどGitUp、やめられませんでした。 Macbookをスタバで開いてはプロジェクトをgitで管理する機会の多いであろう諸兄・諸姉のために、独断でイケてるなと思ったgitのGUIクライアントについて紹介したい。その名もGitUp。 GitUp : http://gitup.co/ GitUpとは GitUpはmacOS用に開発されたgitのGUIクライアントである。 公式ホームページに、 Work quickly, safely, and without headaches. とあるように、確かに使っている間は頭痛がしない気がする。大きな特徴としては、謳い文句の通り、 早い。 ざっくりした使い方 コミットを参照する。 ここでは、openFrameworks (https://op
![[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/70f87d0f5f8c94361eae4a13ff8d302d0d6fcd99/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.1.1%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGODYwNDAlMkZwcm9maWxlLWltYWdlcyUyRjE0NzM3MDM2MTY_aXhsaWI9cmItNC4xLjEmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmJnPUZGRkZGRiZmbT1wbmczMiZzPTg3Yzc2MWE1ZGQ4YjRjOTIwZDcwM2U1YzEwMmI2Njky%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D06e44e777be4f4ae91dfcfaee2551e1f%3Fixlib%3Drb-4.1.1%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTk2MCZoPTMyNCZ0eHQ9JTVCbWFjT1MlRTUlOTAlOTElRTMlODElOTElNUQlMjBnaXQlRTMlODElQUUlRTMlODIlQUYlRTMlODMlQTklRTMlODIlQTQlRTMlODIlQTIlRTMlODMlQjMlRTMlODMlODglRTMlODElQUZHaXRVcCVFMyU4MSU4QyVFMyU4MSU4NCVFMyU4MSU4NCVFMyU4MSU5RSVFMyU4MCU4MiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPWFhODljZmZhNTg5NjI0MzJlNTM2MjAzMDVlNjI2YTVh%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTgzOCZoPTU4JnR4dD0lNDBKb3Rhcm9TJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9NTYzYTVkOTc4MTMzNWQwNGZkMjhiYjAwOTcxN2U4ZTA%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D5d4971b476558cc81baea899a8d73dc4)
Git Has A New Wire Protocol Yielding Much Greater Performance - Phoronix
Git Has A New Wire Protocol Yielding Much Greater Performance Written by Michael Larabel in Free Software on 18 May 2018 at 01:37 PM EDT. 19 Comments The Git Protocol Version 2 was announced today by Google as a major update to the distributed revision control system's wire protocol. Git protocol version 2 is much more efficient and yields significant performance benefits. The new Git wire protoco
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
他人のコミットをgit merge --squashするべきでないのではという話 - Qiita
最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまったことが一部界隈で話題になっていました。この件にはマージを行った人に悪意はなかったようなのですが、gitの理解不足により生じてしまった案件だとすると悲しい話なので一応メモ 何が起きたか コミッターが複数の内容が含まれたPRを送った 管理者はその中の一部の内容だけをマージするために、管理者はgit merge --squashを実施し、コミットを改変した上でmergeを実施した ←これが問題 コードの内容はコミッターのものなのに、Authorだけ管理者にすげ変わってしまいコミッターのモチベを損ねた そもそもsquashするとどうなるの ここに分かりやすくまとまっています。 アジャイルSEを目指すブログ 図で分かるgit-mergeの--f
GitHub - olivierverdier/zsh-git-prompt: Informative git prompt for zsh
The prompt may look like the following: (master↑3|✚1): on branch master, ahead of remote by 3 commits, 1 file changed but not staged (status|●2): on branch status, 2 files staged (master|✚7…): on branch master, 7 files changed, some files untracked (master|✖2✚3): on branch master, 2 conflicts, 3 files changed (experimental↓2↑3|✔): on branch experimental; your branch has diverged by 3 commits, remo
DBスキーマのMigrationを行うのに便利なGitDDLのご紹介 - Qiita
どうもこんばんわ、日々お世話になったり、便利だと感じたOSSを紹介していく、OSS紹介 Advent Calenderの21日目の記事です。 GitDDLとは あるDBスキーマから別のDBスキーマに変更を行う際(=migration)を行う時に使うCPANモジュール Railsなどのmigrationとは違ったアプローチで行う 中に使われている魔法のようなモジュールSQL::Translator::Diffの紹介もします DB migrationとは MySQLなどのRDBMSを用いたアプリケーションを運用していくと、「新しくテーブルを追加したい」「カラムを増やしたい」「インデックスを足したい」などの場面に遭遇することがあります。テーブルを追加するだけであれば、新しくCREATE文を発行するだけで良いのですが、カラムを増やしたいだとかインデックスを足したいとなると、ALTER文を打たなけれ
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 ソフトウェアの開発プロセスにおいて、「Jenkins」はビルドやテスト、デプロイなどを自動化してくれるツールとしてよく知られています。 そのJenkinsの派生プロジェクトとして、「Jenkins X」が発表されました。Jenkins Xは、Git、Docker、Kubernetesの環境を前提とすることで、Jenkinsの設定、運用などを大幅に自動化し、より簡単な導入と運用を実現するものです。 Jenkins Xは、Git/Docker/Kubernetes環境に特化 オリジナルのJenkinsは汎用的なビルドやテストの自動化ツールとして、さまざまな環境やツールと連係できるように作られています。そのため柔軟なコンフィグレーションが可能になっていますが、一方でそれが導入や
アプリケーションのバージョンに Git の情報を出してみよう！
はじめに 今回は gitrev パッケージと optparse-simple パッケージを使ってアプリケーションに Git の情報を含めてみようと思います！ 利用者の多いアプリケーションだと、バグ報告時にどのコミットでビルドしたものなのか知りたい場合に便利です。 表示されるバージョン情報はこんな感じになります。 # gitrev の例 $ ./Main.hs Main.hs: [panic master@3a0bd17fdfb8a3e334292a560280e8e0791e941c (Tue Mar 20 02:00:17 2018 +0900) (1 commits in HEAD)] # optparse-simple の例 $ stack exec -- example-version-exe Version 0.1.0.0, Git revision 341e785b02c4c5
意外と知らない？ Gitコマンド 100本ノック - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 みなさん、Git使ってますか？ もしくは、使いこなしていますか？ 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git 100本ノック Gitに馴染む 1. メールアドレスをGitのグロー
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
gitでrename&modifyしたファイルのログを追跡できるようにしたい場合 - Qiita
この記事のサマリ gitでバージョン管理しているファイルをリネームしたい場合に、リネーム前のログもたどれるようにしておきたい場合は、 ①「git mv」でリネームして「git commit」でコミットを発行 ②その後、対象ファイルを修正してコミット といった手順を取ると ③「git log --follow」でリネーム前のログも辿れるというお話です。 注意：①と②を同時にやってしまうと、どうもうまくログをたどれないらしいというお話も含みます。 シチュエーション git管理して、すでにコミットログが溜まってそれなりに歴史のあるファイルがあったとします。 そのファイルをある時、ファイル名の変更と内容の修正が必要に迫られたようなシーンを想定しています。歴史のあるファイルなので、特に昔のログは追いかけるようにしておきたいですよね。 具体的な例では、 railsの勉強とgitの勉強のために、サンプル
Gitでファイルの実行権限を変更する - Qiita
WindowsとLinuxをまたがって、スクリプトファイルを編集する場合のTips。 Linux系の場合、ファイルシステム上でファイル実行権限を変更する(chmod）と、Gitが「ファイルが変更された」と認識する。 そのため通常の変更と同じく、git add 、git commitでファイルアクセス権をリポジトリに反映できる。 Windowsでアクセス権を変更したい場合は、下記のようなGitコマンドを使う。 実行権限を付与するとき $ git update-index --add --chmod=+x [filename] 実行権限を外すとき $ git update-index --add --chmod=-x [filename] なお、config設定で「ファイル権限設定を無視する」というオプションがあるため、注意。 $ git config -l |grep filemode
gitMask - Develop Anonymously
Code Privacy. Just because you support OSS, doesn't mean you want your name forever associated with every project you ever touch Last login: Sat Aug 5 2017 23:34:14 on ttys000 ➜ ~ git clone https://github.com/AnalogJ/gitmask.git ➜ ~ git checkout -b feat_branch ➜ ~ echo "update readme" >> README.md ➜ ~ git commit -am "Commits will be squashed and messages overwritten" ➜ ~ git remote add gitmask htt
git sparse checkout で clone せずに一部のサブディレクトリだけを pull/checkout する
Git は大変便利なのですが、 clone では基本的にすべてのディレクトリが同期されます。 不要なものを削除すればそれはそれで変更として追跡されてしまうので、一部のディレクトリだけを取得したい場合は sparse-checkout というテクニックを使います。 一旦 clone しない sparse checkout Git 特定のフォルダのみcloneする - Qiita 先人の情報によれば「とりあえず普通に clone する」という例が多いのですが、ファイル数が多い場合など、すべてを clone したくない場合もあります。 そのような場合は下記のようにして sparse checkout を有効にします。 空の Git リポジトリとして初期化 sparsecheckout を有効にする リモートリポジトリの URL を origin として登録 チェックアウトする対象のディレクトリを
こんなGitの教え方をするエンジニアはデザイナーからモテるぞ！ - Qiita
いかがでしょう！ この通り、デザイナーからモテモテです！ ■真面目な話… タイトルはふざけていますが、真面目な話をすると4年前の私がこんな教え方をしてもらえていたら、本当にGitに怯えることもなかったと思います。 なぜ、あのころ理解ができなかったのか。 あの時どうしてもらえていたら、エンジニアもデザイナーもお互い幸せになれたのか。 Gitを使い始める時にデザイナーとして知りたかったことや知らなくても困らなかったことを一生懸命まとめました。 情熱を込めすぎたせいで、1万字を超えるエントリーになってしまっています。 順番も意識したので、上から順に読み進めていただけると、うれしいです。 ■あらすじ 【その1】「図解」を活用し、「簡単」って嘘をつかないエンジニアはモテる 【その2】Gitで幸せになる世界を共有してくれるエンジニアは素敵だ 【その3】環境構築をサポートしてくれたエンジニアはものすごく
git rebase -iの時に役立つプラグイン - Qiita
はじめに 以前、と言っても結構前ですが、タイトルにあるようなgit rebase -iの時に役に立つVimプラグインというのを作ったので、それを紹介したいと思います。 動機 僕の所属している開発チームでは、バージョン管理システムにgitを使用しています。 gitは広く知られている通り、分散バージョン管理システムと呼ばれているものの一つです。その特徴と言っていいのかわからないですが、gitを利用すると、手元でのソースコードの変更を、細かい単位でローカルのリポジトリにどんどんコミットしておき、それを適当なタイミングでコミット履歴を改変して内容を整理してから、チームで共有しているリポジトリに状態を同期させるようなことができます。 git rebaseとは、そのようにコミット履歴を改変するときに使用するコマンドです。 git rebaseコマンド、特に-iというオプションを付けたものは、コミットの
propellor: deploying properties to hosts with haskell
Propellor is a configuration management system using Haskell and Git. Each system has a list of properties, which Propellor ensures are satisfied. Linux and FreeBSD are supported. Propellor is configured via a git repository, which typically lives in ~/.propellor/ on your development machine. Propellor clones the repository to each host it manages, in a secure way. See components for details. Prop
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - christian-marie/git-vogue: Make your Haskell git repositories fashionable.