トップページ⇒tech
1001コメント321KB

Git 9

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2014/04/12(土) 13:22:20.98ID:s4x1CSLN
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
0090デフォルトの名無しさん2014/04/18(金) 10:51:55.78ID:TiuM1iK+
ローカルのみで使おうと思ってたのですがリモートにも上げた方がよさそうですね
0091デフォルトの名無しさん2014/04/18(金) 11:00:45.77ID:KSddQ8SJ
Dropboxにリポジトリを作るやり方はここの先輩方はやってますか？
0092デフォルトの名無しさん2014/04/18(金) 11:01:59.07ID:V7HQhmWQ
>>41にそういう奴がいるな
0093デフォルトの名無しさん2014/04/19(土) 12:55:58.24ID:7PgX0mPg
>>84
gitkはgit log(というかgit rev-list)と同じ範囲指定が可能だから、
--allで表示が多すぎるなら表示範囲を適切に限定してやればよい。
特定のtopic(ここではmasterから分岐したとする)とmasterにだけ注目すればいいんなら
gitk master..topic (masterから分岐後のtopicのコミットのみ表示)
gitk master...topic (masterから分岐後のtopicのコミットとmasterにマージされたブランチを表示)
とか。範囲指定は複数回可能なので関係する範囲を好きなだけ指定すればよい。
0094デフォルトの名無しさん2014/04/20(日) 20:26:37.01ID:mILxVbg/
>>91
.zshrcとか.vimrcとかをつっこんだリポジトリはDropboxにbareで載せてる。
0095デフォルトの名無しさん2014/04/21(月) 13:00:54.05ID:ZKyIOHr8
gitignoreで
/*
/.*
このふたつを指定しているのをたまに見かけますが
はじめに/*ですべてのファイルを除外しているので/.*を書く意味は無いと思うんですが何故書くのですか？
0096デフォルトの名無しさん2014/04/21(月) 14:22:29.42ID:dtgq5rdV
ドットで始まるファイルは * のワイルドカードにひっかからない仕様になってる。
シェル由来だね。
0097デフォルトの名無しさん2014/04/21(月) 16:06:02.61ID:mYIG7FH4
なにそれバグだろ
クソだなgitって
0098デフォルトの名無しさん2014/04/21(月) 20:57:12.01ID:1sDt+ic8
無知発見
0099デフォルトの名無しさん2014/04/21(月) 21:13:29.40ID:fKV6ATCG
餌を与えないでください
0100デフォルトの名無しさん2014/04/21(月) 21:48:05.88ID:yaM3rCK5
gitは糞だからsubversionを使え
0101デフォルトの名無しさん2014/04/21(月) 22:43:41.18ID:KhXBvEFh
やだGitじゃないと

VSS、これ最悪でした。
チェックアウトされたままコンパイル通らない状態で担当者休み。どーすんの？
でもMSじゃないと駄目、OSSなんか信用できないとかで泣く泣く使う現場多数。

それに比べるとSubVersionかなりマシだけどオフラインな状態でコミットできない。
ちょっと痛い。
0102デフォルトの名無しさん2014/04/21(月) 23:08:04.07ID:/9iyZBJ2
バージョン管理はgitしか使ったことがない
SVNは何がなんやらサッパリわからないから使えない
0103デフォルトの名無しさん2014/04/21(月) 23:28:39.44ID:wk0llTNx
>>101
× SubVersion
○ Subversion
0104デフォルトの名無しさん2014/04/21(月) 23:37:15.06ID:vVBjDa2G
オフラインの状態でコミットできないとか言ってるけど
コミットしたところでローカルにあるだけだからオンラインで他の奴がお前のリポジトリに
アクセスできなきゃ何もかわらんだろアホか
0105デフォルトの名無しさん2014/04/21(月) 23:51:33.94ID:KhXBvEFh
例えばあなたが飛行機で移動中に１０項目ぐらいの作業して
帰社してコミットする時にコメントに１０項目だらだら書くの？

やーだー
0106デフォルトの名無しさん2014/04/22(火) 00:01:10.97ID:4JSOLbvH
移動中に仕事するようなワーカホリックになりたくないわ正直
0107デフォルトの名無しさん2014/04/22(火) 00:05:36.52ID:DheOpfOv
一例として挙げただけなのに。想像力無いなあ。
0108デフォルトの名無しさん2014/04/22(火) 00:32:53.01ID:ysn+k/fU
セキュリティ的なこと考えるとオフラインでソースにアクセスってあんまりないんだよね
0109デフォルトの名無しさん2014/04/22(火) 00:48:34.17ID:9W1A4/eN
>>97
いわゆるシェルは.(ドット)で始まるファイルは隠しファイルとしている
隠しファイルは ls *.conf とかで表示されない (.hoge.conf とか)
そんな時に rm *.conf して普段表示されてないファイルが消えるのは困る
だから * だけでは隠しファイルにマッチしないようになっている
ちなみに git が内部でどう処理してんのかは知らん
0110デフォルトの名無しさん2014/04/22(火) 13:52:48.51ID:+yEK9mtt
ふつーにfnmatchでは
0111デフォルトの名無しさん2014/04/23(水) 05:15:19.40ID:7ZWtOh9Z
commit A
commit B
commit C
commit D
commit E
commit F

と順番に作業して
あとから B から D をまとめて

commit A
commit b(B-D)
commit E
commit F

としたいときはどうすれば・・・
0112デフォルトの名無しさん2014/04/23(水) 05:24:18.61ID:kDpoyMyg
よう知らんけど

↓のsquashというやつで出来るんじゃないの？

Git - 歴史の書き換え
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88#コミットのまとめ

> # s, squash = use commit, but meld into previous commit
0113デフォルトの名無しさん2014/04/23(水) 07:20:48.07ID:fIp3qZsI
>>111
rebase -i
0114デフォルトの名無しさん2014/04/23(水) 09:40:59.20ID:T4x0zu0j
２．０って来月でる？
0115デフォルトの名無しさん2014/04/23(水) 20:35:59.48ID:7vo5B08Z
>>111と反対に、一つのコミットであるbを
B-Dに分割したい時どうしてる？
俺はrebase -i
0116デフォルトの名無しさん2014/04/23(水) 22:04:37.40ID:59LgjvrD
rebase -i はいろいろ便利だよな
ただ慣れないと指定にちょっと戸惑う
>>111みたいにB以下をいじりたい場合だと rebase -i A ってしなくちゃいけないんだよな
それと、まとめたり順番入れ替えるだけなら操作は簡単だけど、バラす場合はちょっと操作がややこしい
0117デフォルトの名無しさん2014/04/24(木) 00:12:45.07ID:6IEmJN8m
git rebase -i　のコミットの表示順とgit logの表示順が逆なのは何故なんだぜ？
逆に表示するオプションあるけどグラフ表示とは併用できませんし。
0118デフォルトの名無しさん2014/04/24(木) 01:22:42.87ID:cdLHxk0K
logは新しい順に表示しないと不便だと思うし(見たいのは最新の辺のことが多いよね)
rebase -iの指示書は、前のコミットにまとめるとかの指定することを考えると古い順に並んでたほうがわかり易い気がする
まあ、自分は慣れてしまったからかもしれないが
0119デフォルトの名無しさん2014/04/24(木) 01:29:19.68ID:SDYiDObT
>>116
rebase -i B^
0120デフォルトの名無しさん2014/04/24(木) 05:27:42.49ID:6xlhO1bi
rebase -i ^_^b
0121デフォルトの名無しさん2014/04/24(木) 13:18:49.88ID:QakcezKL
最新のコミットだけプッシュする方法と
最新のタグをつけたコミットだけプッシュする方法
２つおしえてください
0122デフォルトの名無しさん2014/04/24(木) 13:19:34.50ID:QakcezKL
なぜかというとコミットログからニートがバレるのでコミットログを全部プッシュしたくないからです
0123デフォルトの名無しさん2014/04/24(木) 13:22:26.51ID:V8z90YIW
>>121
sqush
0124デフォルトの名無しさん2014/04/24(木) 13:47:51.32ID:JOpp0cve
githubのコミットログからニートを検索するツールはよ
0125デフォルトの名無しさん2014/04/24(木) 19:02:31.15ID:yOTIc0ZO
その前に日本人を探すツールが必要だ
0126デフォルトの名無しさん2014/04/24(木) 21:18:41.68ID:hPYav21o
>>122
git filter-branch --env-filter 'GIT_COMMITTER_DATE="Thu, 01 Jan 1970 09:00:00 +0900
"; GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE' --all
0127デフォルトの名無しさん2014/04/24(木) 22:02:19.45ID:6xlhO1bi
コミットログに日時変えればいいだけじゃん。
0128デフォルトの名無しさん2014/04/24(木) 22:18:20.71ID:0H30XzcZ
git init
git checkout -b test
>Switched to a new branch 'test'
git branch
>何も表示されない
git checkout test
>error: pathspec 'test' did not match any file(s) known to git.
なんもコミットされてないとこうなるんですがどうしてこうなるんですか？
0129デフォルトの名無しさん2014/04/24(木) 22:21:42.53ID:hPYav21o
>>128
その状態だと、HEADはrefs/heads/test向けのsymbolic-refになっているが、
そもそも指すべきコミットがないのでrefs/heads/testは存在しない。
よってbranchも何も表示しないし、checkoutもできない。
0130デフォルトの名無しさん2014/04/24(木) 22:23:42.17ID:0H30XzcZ
仕様なんですか
一番最初のコミットが汚れるのがいやですね
0131デフォルトの名無しさん2014/04/24(木) 22:25:13.61ID:6xlhO1bi
rebaseすればいいじゃんｗ

俺は、とりあえず空コミットを作る。
かもしれないし、作らないかもしれない。
0132デフォルトの名無しさん2014/04/24(木) 22:26:57.87ID:hPYav21o
>>130
つまりコミット無し状態でブランチを複数作りたいということ？
0133デフォルトの名無しさん2014/04/24(木) 22:31:15.84ID:0H30XzcZ
漢がrebaseなんて許せないタチなんですよ
コミットなし状態からブランチを分けて開発したいんです
基本的にmasterは汚したくないのです
0134デフォルトの名無しさん2014/04/24(木) 22:33:01.48ID:6xlhO1bi
subversionがだめな理由が
rebaseできないからなんだけど？

それぐらい、というかそれ以上に
よく使う機能だぞ。

汚くしないためにrebaseがある。
0135デフォルトの名無しさん2014/04/24(木) 22:37:44.72ID:hPYav21o
>>133
129で言ったようにHEADが存在しないrefを参照していればgit initした状態と同じなのだから、
二個目のブランチを作るときにgit checkout -bではなく
git symbolic-ref HEAD refs/heads/branch_name してから開発を進めればいいじゃない
0136デフォルトの名無しさん2014/04/24(木) 23:47:09.80ID:T/Y/fuz3
>>133
そこまで潔癖ならマージもしないだろうからブランチじゃなくてリポジトリを分けたら？
0137デフォルトの名無しさん2014/04/25(金) 00:27:14.58ID:kupFdBxu
master汚したくないっていうのが出来たとして、
1つ目のcommitがあって、それがtestブランチだとする。
が、masterはこのcommitから辿れる親コミットも指してないし、どれも指していない。
fast forward mergeできない状態だけどいいの？
どうせmasterはなにかしらコミットした段階で一番汚されてなくたってそのコミットを指してしまうのだから、コミットしてからチェックアウトしてもいいじゃん。
0138デフォルトの名無しさん2014/04/25(金) 03:08:01.24ID:XQM8U6nM
mergeする予定無いのにブランチ切りたいとか意味不明すぎる
0139デフォルトの名無しさん2014/04/25(金) 04:07:01.58ID:zu0sgmwa
空コミットじゃあかんのか？
つか空の.gitignoreくらい作ってからでも汚れとは思わんぞ
0140デフォルトの名無しさん2014/04/25(金) 04:20:32.33ID:jzYptMLV
気に入らない部分があってもgitを使わざるをえない人は大変だね
個人の趣味でやってるならVCSは好きなのを使えるのにね
0141デフォルトの名無しさん2014/04/25(金) 04:23:50.66ID:4klH39dY
気に入らない部分が、git以外には多すぎる。
0142デフォルトの名無しさん2014/04/25(金) 05:28:33.42ID:cdj1D6xv
だねー
俺はローカル全部svnだわ
0143デフォルトの名無しさん2014/04/25(金) 08:52:14.28ID:xiFjVo8G
３つ前のコミットに戻ってブランチを分岐したい場合ってどうすればいいのでしょうか
３つ前に巻き戻してからブランチするのでしょうか
最後の２つのコミットも念のために残したいのでブランチにしたいのです

具体的には
最後の２つのコミットの変更が破棄になったけど
念のために残したい
という状況です
0144デフォルトの名無しさん2014/04/25(金) 11:14:49.10ID:4klH39dY
三つ前のコミットIDから
ブランチ作ればいいじゃん。
0145デフォルトの名無しさん2014/04/26(土) 02:05:43.27ID:pkQNyj+N
>>134
rebaseはブランチ取り込むときにontoと組み合わせて使うことの方がおおいなぁ。
コミットログの都合もあるから履歴整理にはほとんど使ってない人がここに。
0146デフォルトの名無しさん2014/04/26(土) 02:08:06.72ID:/GEUo84h
なんでブランチ取り込む時にontoなんだ？
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。
0147デフォルトの名無しさん2014/04/26(土) 02:26:05.50ID:pkQNyj+N
やり方がわるいんかな？
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。
0148デフォルトの名無しさん2014/04/26(土) 02:39:25.28ID:7YL+swb1
>>147
だからなんでFFにするんだよ
0149デフォルトの名無しさん2014/04/26(土) 02:41:39.49ID:/GEUo84h
onto使ったら必ずほぼ確実にFFできないだろ？
なんか無駄に複雑なことしている気がするな。
0150デフォルトの名無しさん2014/04/26(土) 13:53:59.32ID:Vv5x70uz
ホームディレクトリ以下の設定ファイルだとか、個人で使ってる自作ツールはSubversionで管理してる
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい
0151デフォルトの名無しさん2014/04/26(土) 13:58:18.76ID:/GEUo84h
>>150
いや、ディレクトリがわかれるだろ？

subvertionを使うと、

* ファイルがあるディレクトリ
* リポジトリ

と二つにディレクトリがわかれるだろ？

それだけで使いづらいじゃん。
0152デフォルトの名無しさん2014/04/26(土) 14:05:48.63ID:Z8XCebgD
?
0153デフォルトの名無しさん2014/04/26(土) 14:20:33.69ID:dMJ+hsKf
>>151
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。
0154デフォルトの名無しさん2014/04/26(土) 14:56:15.48ID:1yS20LQ1
リポジトリを1つだけだとさ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ
0155デフォルトの名無しさん2014/04/26(土) 15:03:43.34ID:/GEUo84h
なぜリポジトリを一つにまとめるのか？

リポジトリを作るのが面倒であるということである。
0156デフォルトの名無しさん2014/04/26(土) 18:03:12.98ID:Vv5x70uz
リポジトリをたくさん作るとその数だけcheckoutしてpull/updateしてcommitしないといけない
自分一人で使うだけでそんな面倒なことしない
0157デフォルトの名無しさん2014/04/26(土) 18:26:46.44ID:ztOmzoR+
subversionだと、このようにpullやupdateや
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。

gitだと気軽なのにね。
0158デフォルトの名無しさん2014/04/26(土) 18:27:44.99ID:bHDNIx6I
cvs使ってた10年以上前は、私もひとつのリポジトリでやってたことがありました。(*ﾉωﾉ)
0159デフォルトの名無しさん2014/04/26(土) 18:30:43.24ID:Vv5x70uz
一人でしか使わないんだからコンフリクトなんかしない
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰
0160デフォルトの名無しさん2014/04/26(土) 18:39:48.80ID:ztOmzoR+
>>159
コンフリクトかどうかは
重要じゃないよ。

gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。

追加漏れのファイルを追加
スペルミスの修正

こんなマヌケなコミットを残さないで済む。
0161デフォルトの名無しさん2014/04/26(土) 18:42:46.95ID:ztOmzoR+
subversionが残すのは"作業"履歴なんだろうね。
gitが残すとのは"修正"履歴

だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。

gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。

subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。
0162デフォルトの名無しさん2014/04/26(土) 18:47:04.31ID:ztOmzoR+
subversionだと作業履歴が残っちゃうから
ちょっと気軽にコミットしようということができない。

gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが

subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。
0163デフォルトの名無しさん2014/04/26(土) 18:56:37.43ID:Vv5x70uz
.bashrcや.inputrcが数千行になったらgitの導入を考える
0164デフォルトの名無しさん2014/04/26(土) 18:57:44.05ID:ztOmzoR+
HAHAHAHA、基準がおかしい奴がいる。
こういう奴がgitに反対しているわけさ。
0165デフォルトの名無しさん2014/04/26(土) 19:04:14.03ID:a+LUSt4b
bareめんどくない?
0166デフォルトの名無しさん2014/04/26(土) 19:10:57.12ID:Vv5x70uz
だいたい.screenrcに対する特定のコミットを取り消すとか、そんな必要性感じたこと一度もない
0167デフォルトの名無しさん2014/04/26(土) 19:12:42.80ID:ztOmzoR+
面倒くさいなら作らなくていいよ。
bareは必須ではない。

gitを始めるのに必要なのはディレクトリで
git initするだけ。

これでもうすぐにブランチ切り替えも
タグの作成もできる。

某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。
0168デフォルトの名無しさん2014/04/26(土) 19:13:48.14ID:ztOmzoR+
>>166
君は.screenrcの管理とかしかしないんだねｗ

えぇ、subversionは面倒だからでしょうね。
気軽に始められないｗ
0169デフォルトの名無しさん2014/04/26(土) 19:17:57.35ID:Vv5x70uz
いや、何の事かわからないが、subversionでもgitでもどういうブランチ構成にするかはその人次第だから
0170デフォルトの名無しさん2014/04/26(土) 19:22:53.05ID:ztOmzoR+
subversionにおけるブランチの作り方
※ブランチ作るたびに、この長いURLをいちいち入力する必要があります。

svn cp https://www.example.com/svn/trunk \
https://www.example.com/svn/branches/v1p2p3

gitだとこれだけです。

git branch v1p2p3


さてブランチに切り替えてみましょう。

svn sw https://www.example.com/svn/branches/v1p2p3

ぷぷぷぷｗ

なんでsvnはそんな長いURLが必要なんですか？ｗｗｗｗ
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる＝コピー場所を指定しなければいけないんですね。

これを毎回毎回入力して切り替えるんですね。大変ですねぇｗｗｗｗ

git checkout v1p2p3

みじかい！
0171デフォルトの名無しさん2014/04/26(土) 19:24:43.18ID:ztOmzoR+
>>169
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。

だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。

こんなの、き・そ・！ です。
0172デフォルトの名無しさん2014/04/26(土) 19:30:14.03ID:y+As8odQ
おっ、そうだな
0173デフォルトの名無しさん2014/04/26(土) 19:30:26.82ID:Vv5x70uz
いや、初めからブランチ作らないって言ってるし、.my.cnfでも.pgsqlでもなんでもいいが、ブランチ切って修正を分ける必要性を全く感じない
0174デフォルトの名無しさん2014/04/26(土) 19:32:08.93ID:ztOmzoR+
※>>173 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうｗｗｗ
0175デフォルトの名無しさん2014/04/26(土) 19:33:56.04ID:Z8XCebgD
なんでこの人こんなに発狂してるの・・・
別に git はゴミ！とか貶してるわけじゃないのに
0176デフォルトの名無しさん2014/04/26(土) 19:34:13.93ID:Vv5x70uz
世の中には.ssh/configをテストファーストで日々更新してる人もいるのかもしれない、そういう人にはリリースと開発でブランチを分けてるのかもしれない
俺はそんなことしてないけど
0177デフォルトの名無しさん2014/04/26(土) 19:35:28.56ID:ztOmzoR+
subversion使っている人は、みんな
ブランチ作らないって言ってるんでしょうかね

みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。

実はブランチ作れないの間違いでしょうかねｗ

面白いですねｗｗｗ
0178デフォルトの名無しさん2014/04/26(土) 19:36:05.09ID:ztOmzoR+
subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
0179デフォルトの名無しさん2014/04/26(土) 19:39:59.70ID:iVzDEppp
>>173
お前がブランチ作らないとかどうでもいいわ。

バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。

それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
0180デフォルトの名無しさん2014/04/26(土) 19:44:23.08ID:Vv5x70uz
いや、ホームディレクトリ以下の設定ファイルという前提なんだけど
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
0181デフォルトの名無しさん2014/04/26(土) 19:46:55.41ID:koYBfWi3
ホームディレクトリ以下をgitで管理しようと思うのならば、
git initするだけでもう使えるよ。

subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
0182デフォルトの名無しさん2014/04/26(土) 19:51:45.97ID:Z8XCebgD
なんか話を一般化して叩いてるけどホームディレクトリ内のファイルの管理ぐらい好きにやらせたれや・・・
0183デフォルトの名無しさん2014/04/26(土) 19:54:06.41ID:HaseiyYq
自由にやっていいよ。面倒な方法だって言っているだけだから
別に面倒な方法だってわかってやってるなら問題ない。

面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。

gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
0184デフォルトの名無しさん2014/04/26(土) 19:54:51.87ID:Vv5x70uz
>>181
なんでリポジトリを別の場所に置いたらダメなの？
特にマシン間で設定フィルを共有する場合、中央リポジトリが必要になるのは同じなんだから
0185デフォルトの名無しさん2014/04/26(土) 19:56:09.41ID:Z8XCebgD
まあそこら辺は git スレでわざわざ頑張る内容ではないだろな
0186デフォルトの名無しさん2014/04/26(土) 19:56:42.73ID:HaseiyYq
>>184
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。

gitでも当然のようにリポジトリを別の場所におけるわｗ

だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。

少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
0187デフォルトの名無しさん2014/04/26(土) 19:59:08.48ID:Z8XCebgD
>そういう使い方するとGitよりSubversionが使いやすい
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
0188デフォルトの名無しさん2014/04/26(土) 20:01:00.30ID:HaseiyYq
>>187
じゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。

お前ん中ではそうなんだろうなｗ
お前ん中では、設定ファイルの管理にぐらいしか使わないんだろうな
0189デフォルトの名無しさん2014/04/26(土) 20:14:52.93ID:7bCdF05U
まとめ

（俺にとっては）Subversionの方が簡単

俺にとってはって、君、Subversionを何に使ってるの？

設定ファイルの管理だけど？
ブランチは使わない！

でもブランチやタグを使うと面倒だよね？

だから、俺はブランチは使わない！

ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。

gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！

いや、同等って、それ簡単ということになってないじゃん。
0190デフォルトの名無しさん2014/04/26(土) 20:38:24.09ID:knmAOh4a
ブランチ使わないって前提の話で、subversionはブランチ作るのが面倒とか的外れな反論しておかしくなった
ドットファイルをブランチに分ける事は基本ないわな
■ このスレッドは過去ログ倉庫に格納されています