ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
ツイッターで以下のようなツイートを見かけたので: Mercurial 推進派としては何か情報発信しておきたいところですが、よくよく考えてみると、そもそも私自身が、送ったものと受けたものを合わせても、両手の指で足りる程度しか pull request を使った事が無いのでした(笑)。 ＃ 後述するように、Mercurial 本体の開発はメーリングリストベースなのです…… しかし、pull request そのものの話は不得手でも、Git と Mercurial での『ブランチ』の違い等なら、とりあえず自分の守備範疇なので、『Mercurial で pull request』したい Git ユーザ向けに、以前書いたMercurial におけるブランチの概念に関する一連のエントリの要約的なものと、現時点で私が思い付く『pull request 時に注意すべき点』をまとめてみました。 pull r
最近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
このエントリはMercurial Advent Calendar 2011 - PARTAKEの25日目です。 3月からMercurialを使い始めたので12月で9ヶ月目になります。一年の振り返りという事で、Mercurial導入の軌跡について簡単にまとめたいと思います。*1 Mercurialとの出会い Mercurialと出会う前はSubversionとちょっとだけGitを触っていました。とくにSubversionは仕事でかなりがっつりブランチの運用*2を行っていました。 嫌になるほどSubversionを使うプロジェクトでは次の問題が発生していました。 Subversionでのブランチマネジメントはマージ担当者の負荷が高すぎる リポジトリが巨大になりすぎてsvn stするだけでも20秒 リポジトリが巨大になりすぎてsvn upが終わらない 部分svn upし出す人が増え、整合性に関す
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
Subversion・Git・Mercurialの比較のために過去の記事や関連資料をリンクしておく。 【比較】 SVN / Git / Hg 比較表 ? TortoiseGit Japan 【Subversion】 Subversion によるバージョン管理 svnbook.ja.pdf Subversionを見直せ: プログラマの思索 Subversion/運用方法 - ピノキヲ IT Wiki 【Git】 Pro Git 日本語版: プログラマの思索 A successful Git branching model: プログラマの思索 git-flow による構成管理とRedmineの関係: プログラマの思索 【Mercurial】 Mercurialの資料: プログラマの思索 hgbook 日本語版のHTML公開: プログラマの思索 CVS→SVN→Git・Mercurialへ至る歴
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
http://partake.in/events/95ab571f-c477-43dd-8d96-396d3b670b6f:title=の成果発表です。 先日あるmercurialリポジトリのミラーリポジトリをgithubに作成したところ、開発がgithubに移ってしまうという(mercurial使い的には)ショッキングな出来事がありました。mercurial使いはいろいろ肩身が狭いですね。 それもこれも、「mercuiralを使いながらgithubのpull requestを取り込む方法」についてのノウハウが共有されていないことに問題があります。今後、二度と悲劇を繰り返さないために考察してみました。 想定する構成 考察した結果です。 bitbucket-and-github urlは次の通り central repository https://bitbucket.org/troter/
As you can see, Git makes less of an effort to organize its CLI in a way that Subverison users will be used to. While you can work around this by retraining your fingers to type the new commands, it’s yet one more roadblock to switching systems. Worse, it simply isn’t necessary, as Mercurial’s Subversion-user-friendly but still powerful and elegant interface proves. Safer history with mercurial Me
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
SCMBootCamp in Tokyo 開催しました。KPT公開。 - うさぎ組にて手ぶらLTをしたので資料はないが、内容を軽くまとめておく。 GitとMercurialの比較 Git Mercurial リポジトリ commit objectのグラフと、branchのHEAD,tagなどの参照で出来ている。 commit objectのグラフだけで出来ている。 歴史改変サポート デフォルトであり。 デフォルトではなし。extensionが必要。 歴史改変 新しいcommit objectグラフを作成し、参照を古いHEADから新しいHEADに移す。表面上要らない歴史の削除として使われるresetはHEADの移動のみを行う。 新しいcommit objectグラフを作成し、古いcommit objectグラフをリポジトリから除去する。要らない歴史の削除として使われるstrip(MQExte
This entry was posted by Jun Mukai on Wednesday, 22 June, 2011 git commitにある–amendというフラグをご存知だろうか。 gitでは、commitは手元のレポジトリに保存される。多人数で開発するときの中央レポジトリに反映させるには、commitしたものをpushする必要がある。……で、大抵の多人数で開発するプロジェクトの場合、commitした変更を(gerritとかの手段によって)レビューしたりしつつ、すべてが整ってから、pushするというのが一般的な流れかと思う。 だけど人間というのはうかつなことをするものだから、commitした直後に下らない間違いを犯しがちなわけだ。例えば、編集したのにChangeLogを追加してないとか。ファイル足したのにビルドファイルの変更を加え忘れたとか。そういうやつ。そういうしょうもない
……というタイトルの文章を誰か書くべきだと思う。 Gitに初めて触れる人は、(分散)バージョン管理というのはこういうものだ、という認識ができているのではないか、と思った。でもGitはそれなりに特殊なスタイルのバージョン管理システムである。 バージョン管理システムというのは一義にはソフトウェア管理ツールだから(文章の版を管理するのにも使えると思うけど)、あるシステムは何らかの典型的なワークフローを前提としている。GitはLinusがLinuxの開発のために開発されたツールなので、Linuxの開発で採用されているポリシー、考え方、ワークフローが暗黙のうちに組み込まれている。そのまま他のツールに移行しようとしてもなかなかうまく行きはしないものだ。他のツールはたいてい、他の考え方を持っているものだからだ。 Gitに特有なのがブランチの使い方だ。Gitではかなり気軽にブランチを作る。ちょっとした、一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
