hg から git に変換する - uzullaがブログ
最近14年つかっていたdocomoからMNPでauにうつりました。 長年つかっていたのでdocomoに愛着もあったのですが、いかんせんネットの情報を鵜呑みにする情強をきどるには、docomoはつらすぎ感がすごく…。 情しか理由のない選択に意味はあるのか？と悩んだ末に、まあauにしました。 本題 hgをgitに移行する話。 単純に最新をcheckoutして、そのままcommitするとログもブランチも消し飛ぶのでつらい（当たり前） とはいえ、世の中にはちゃんとツールがある git clone git://repo.or.cz/fast-export.gitmkdir -p /path/to/new_git_repo cd /path/to/new_git_repo git init /path/to/fast-export/hg-fast-export.sh -r /path/to/old_h
いろいろ - hg and git
hg と git のコマンド相違点 似てるようで違う hg と git の違いのメモ。 基本 working directory : バージョン管理対象のファイルを置くディレクトリ。バージョン管理対象にしないオブジェクトファイル等を一緒に置いても良い。 repository : working directory の一番上にある、.hg (hg の場合) または .git (git の場合) ディレクトリの中身。バージョン管理に関する情報、履歴等が置かれる。 あるところにあるリポジトリを追いかけるだけの使い方 たとえば www.kernel.org の Linus のリポジトリを追いかけるとか、そんな使い方の場合。一番シンプルな例。 最初の取得 (リポジトリを取得し作業ディレクトリに最新の内容を展開する) hg clone url [dir] git clone url [dir] 最新リ
Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 | Webシステム開発／教育ソリューションのタイムインターメディア
Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
Git 対 Subversion：長引く争い | readwrite.jp
ソフトウェア業界においてGitが支配的な存在ではなかった時代がかつて存在した、といつか言われる日が来るかもしれない。 2010年にはSubversionが、ソフトウェアの共同開発には欠かせないツールであるバージョン管理システムの60％以上を占めていた。Forresterによれば、この時期Gitのシェアはわずか2.7%であった。Redmonkのアナリストであるステファン・オグレディが集めたデータによると、今日ではGitのシェアは28%まで増加し、Subversionの地位を脅かしている。 Subversionのような集中型のシステムよりもGitのような分散型の方が優れているにも関わらず、マーケットがGitを受け入れるのにこんなに時間がかかっている理由は何だろうか？ これからは分散型が主流になるバージョン管理システム（VCS）は、ソフトウェア開発の変更点を記録してプロジェクトを管理するための基
bzrは死につつある。Emacsは移行しなければならない
bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave
Visual Studio にて設定すべき .gitignore / .hgignore - secretbase.log
.gitignore や .hgignore で管理対象から無視することができるのはご存知ですよね。 Visual Studio にて無視するファイル一覧をMSDNで探したけど無かったので stackoverflow で調べたらあったのでメモ。あと、教えてもらった方法も追記。 stackoverflow の回答例 github / .gitignore を用いる方法 無視ファイルの設定 .gitignore の場合 gitの場合は、 .gitignore をおいておきます。 .hgignore .hgignore *1 に下記内容を記載してください。Mercurialの場合の無視ファイルは、デフォルトは正規表現で記述するので、glob文法（SHELL形式のパターンマッチングとかのやつ）にするため一行目 *2に syntax:glob と 記載します。 syntax:glob *.obj *
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内
Visual Studio + Subversionの開発でバージョン管理すべきでないファイル何か - 小さい頃はエラ呼吸
はじめに Visual Studio(C++)で開発して、Subversionでソースコードのバージョン管理をしているプロジェクトで、Subversionで管理すべきでないファイルについて調べてみました。 Microsoft Visual Studio Professional 2013 DVDposted with amazlet at 14.02.04マイクロソフト (2013-11-29) 売り上げランキング: 298 Amazon.co.jpで詳細を見る Subversionで管理すべきでないファイル Subversionで管理すべきでないファイルは、基本的にVisual Studioが吐き出す一時ファイルや環境の情報などを格納したオプションファイルです。 いろいろなサイトで調べてみた結果、以下の拡張子のファイルはバージョン管理対象から外して問題ないと思います。 .opt ローカル
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
操作体系から見る、GitとMercurialの8つの違い
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています
こんにちはこんにちは。一昨日、さくら VPS に Git をインストールするエントリーを書きましたが、実はバージョン管理は etckeeper にもお世話になっています。 etckeeper というのは、Git 等のバージョン管理ツールを用いて、/etc 以下をほぼ自動的に管理してくれる有り難いツールです。下記のタイミングで自動的にコミットしてくれます。手動で任意のタイミングでコミットすることもできます。 -yum コマンド実行の前後 -日付が新しくなったとき << 以下、さくら VPS（CentOS 5.5 -64bit）で etckeeper を使えるようになるまでの手順をまとめてみましたので、よろしければ参考にしてください。 *目次 Git のインストール etckeeper のダウンロード etckeeper の設定ファイルの編集 etckeeper のインストール etckeep
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: 分散バージョン管理システムの詳細なガイド