2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

Git 15©2ch.net

1 :
2017/02/05(日) 05:22:15.65 ID:AxwpDksc0
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

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

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

◆前スレ
Git 13
http://echo.2ch.net/test/read.cgi/tech/1439563364/
Git 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured
2 :
デフォルトの名無しさん (ワッチョイ)
2017/02/05(日) 06:30:39.79 ID:Aiaziz9C0
< `∀´>ニダー
3 :
2017/02/05(日) 14:05:34.08 ID:k22lvY+90
4 :
2017/02/05(日) 15:38:55.62 ID:+MDXuZ600
rebaseを使いこなして初めて
gitを使えるようになったと言える
5 :
デフォルトの名無しさん (エムゾネ)
2017/02/05(日) 15:39:17.20 ID:uN/SMrchF
>1 乙py
6 :
2017/02/07(火) 10:05:09.07 ID:rbbJBTTu0
gitlab復旧作業8時間実況すげ
https://www.youtube.com/watch?v=nc0hPGerSd4
7 :
2017/02/07(火) 11:25:57.76 ID:HoZye2uF0
rebaseの使い途がそんなにないんじゃね
コミットが何百もあったときにrebaseで綺麗にできると思えん
squashはresetでできる
使えるのは過去のコメントを編集するときくらいか
8 :
2017/02/08(水) 03:26:19.24 ID:EqksEKaR0
>>7
コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね?

そのどでかいブランチから、小さく機能を抜き取って
小さなブランチにしてマージするべきだよ。

そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う
9 :
2017/02/08(水) 03:53:20.12 ID:TcrM+SWf0
エスパーすると
>>7は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね
10 :
2017/02/08(水) 11:32:37.78 ID:glAhqeU30
何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか?

いつもいろんなgit操作を試行錯誤してしまって、本題がコミットすることからブランチ整理することにずれていってしまうので。
11 :
2017/02/08(水) 11:38:22.96 ID:AT2+3Uwc0
>>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている
12 :
2017/02/08(水) 15:36:17.78 ID:fGXhImwi0
>>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ
13 :
2017/02/08(水) 17:10:20.00 ID:glAhqeU30
>>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい
14 :
2017/02/08(水) 19:40:31.54 ID:Z548kjM+0
最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの
15 :
2017/02/08(水) 22:22:54.22 ID:EqksEKaR0
>>11
> cherry-pickは操作後の動作が保証できない

何を言ってるんだ?
cherry-pickはあるコミットを持ってくるというだけの機能で
cherry-pickしたあとの動作なんて最初から何も保証してないんだが

保証できないんじゃなくて、保証してない
だからrebaseして、そのcherry-pickしたコミットが正しく動くようにするんだよ

ちなみに、そもそもなんでcherry-pickして動かなくなるのかといえば
こまめなrebaseをしてないから。例えばコミットに対する修正を別コミットに
していたりするとそうなる。こまめにrebaseして意味のある単位にコミットを
修正していれば他人が読んだときのレビューも楽になるし、再利用もしやすくなる


> mergeなら操作後の動作が保証できる

mergeはブランチ全てをマージするものであってそもそも使うべきところが違う。
ブランチの中の1コミットだけを抜き取りたいときにmergeではできない
(できないからmergeの方が劣ってるとでも?w)

使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない
16 :
2017/02/08(水) 22:48:05.72 ID:EqksEKaR0
>>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

簡単に言えば、こまめなコミット、こまめなrebaseだよ
有名なオープンソースソフト(例git)のコミットログを眺めてみればいい
あれが目標とすべきコミット

眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。
後から読むこともあるしレビューのときに読むこともある。だから可読性が必要

じゃあコミットの可読性はどうやればあげられるかというと
意味がある単位で小さくまとまめること

例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって
ここバグってる?すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ
かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる

では意味がある単位で小さくまとめる(=ワークフロー)にはどうするかとうと
まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。
そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。
プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。

rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない
17 :
2017/02/08(水) 23:13:58.04 ID:I20sKjnm0
最初から意味がある単位で小さくまとめるのが理想だけど、
後からブランチの履歴を整理する手段も色々ある。

gitでアレを元に戻す108の方法
http://labs.timedia.co.jp/2011/08/git-undo-999.html
Gitでやらかした時に使える19個の奥義
http://qiita.com/muran001/items/dea2bbbaea1260098051
18 :
デフォルトの名無しさん (アウアウカー)
2017/02/09(木) 08:27:12.93 ID:ClsEJCvia
git(hub)-flow
19 :
デフォルトの名無しさん (エーイモ)
2017/02/13(月) 10:17:21.25 ID:Ql0/GOXFE
git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか?
20 :
2017/02/13(月) 10:39:40.22 ID:1h+Oz1MN0
>>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ
21 :
デフォルトの名無しさん (ワッチョイ)
2017/02/13(月) 15:13:09.61 ID:UyeCKZqE0
改行コード変わるだけで別ファイルになるけどな
22 :
2017/02/17(金) 09:56:23.44 ID:hEtwtvyY0
毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。
23 :
2017/02/18(土) 01:13:13.92 ID:neEeF1u6M
コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな
24 :
2017/02/18(土) 01:21:39.27 ID:YzcxuYMW0
>>22
プッシュじゃなくて?
25 :
2017/02/18(土) 01:58:54.36 ID:SqGT/vv90
>>24
ごめん、プッシュね。

マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。
26 :
2017/02/18(土) 02:04:19.48 ID:odevQhO/p
細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか
27 :
2017/02/18(土) 03:06:20.95 ID:3dbLYC4l0
>>26
突っ走った後にgit add -p 使って複数のコミットを作る
28 :
2017/02/18(土) 11:33:38.07 ID:YCJMYP7V0
>>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う
29 :
2017/02/18(土) 13:22:21.19 ID:y2nzrwVZ0
>>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなw
30 :
2017/02/19(日) 22:56:47.13 ID:ae9YYSse0
cron 書けとしか言いようがない。
31 :
デフォルトの名無しさん (ワッチョイ)
2017/02/22(水) 00:19:55.01 ID:doFig/5A0
エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ
32 :
デフォルトの名無しさん (ワッチョイ)
2017/02/22(水) 15:40:38.57 ID:7bpb3LbA0
>>31
数分おきにエディタに :wq! を送るスクリプトを作ろう
33 :
2017/02/22(水) 15:45:05.02 ID:T1tKwjPzH
意味のある区切りじゃない自動保存などゴミ
34 :
2017/02/22(水) 16:51:00.38 ID:QaRsR5LQa
そもそもコミットは成果毎に行うのであって細かくすればいいというものではない
35 :
2017/02/22(水) 19:13:30.90 ID:nmnET67+0
プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない?
36 :
2017/02/22(水) 19:54:40.37 ID:OuXxGo6Bp
コミットと保存の話が混ざって混沌としてきてる
37 :
2017/02/22(水) 20:45:47.20 ID:bVHsZCW9a
個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね
38 :
2017/02/23(木) 01:11:00.83 ID:9wlFqT9C0
ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばOK
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおk
39 :
2017/02/23(木) 10:00:04.78 ID:lHjqIPrz0
>>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね
40 :
デフォルトの名無しさん (ササクッテロラ)
2017/02/23(木) 16:27:13.03 ID:EPi8ln12p
>>39
ない

svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある
41 :
2017/02/23(木) 20:55:38.64 ID:0FbQfq3Vp
チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか
42 :
デフォルトの名無しさん (ワッチョイ)
2017/02/24(金) 14:06:29.60 ID:STsv/yLm0
SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/

それに対するLinusの見解
http://marc.info/?l=git&m=148787047422954
43 :
2017/02/24(金) 14:11:42.95 ID:xRGcfmimH
hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし
44 :
2017/02/24(金) 15:11:29.62 ID:qhcGsvfzM
想定はしてないでしょ、無理矢理衝突させたらリポジトリ壊れたって書いてるし
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob
45 :
2017/02/24(金) 16:02:16.98 ID:U6j2M/4W0
>>43
5桁でちぎって管理ってなんのこと?
46 :
デフォルトの名無しさん (ワッチョイ)
2017/02/25(土) 10:54:33.01 ID:xirdZVsB0
v2.12.0
47 :
2017/02/25(土) 11:32:01.15 ID:PfZ6yy2F0
>>46
何か面白い機能追加された?
48 :
2017/02/27(月) 04:28:34.00 ID:RD4dbD8r0
49 :
2017/02/27(月) 13:29:26.47 ID:v76+Cgkq0
SHA1衝突なんか怖かねーぜバーカ!
ってこと?
50 :
デフォルトの名無しさん (ワッチョイ)
2017/03/01(水) 00:08:39.88 ID:MSk4m/Wm0
ファイル数が20万〜30万個あるプロジェクトをgitで管理できる?
git statusすると20万〜30万の全部のファイルの更新日チェックするの?
51 :
2017/03/01(水) 01:39:05.95 ID:B+RUxrlO0
gitで管理できなかったら、他の何を使っても出来ないと思うw
管理せずにファイル置いとくだけならできるだろうけど
52 :
2017/03/01(水) 05:02:00.38 ID:TmPMZG9k0
>>51
きも
53 :
デフォルトの名無しさん (オッペケ)
2017/03/01(水) 12:18:24.07 ID:riQaWnbAr
俺も思った
54 :
2017/03/01(水) 12:52:10.72 ID:D9Ze9lwZa
>>50
それくらいなら全然大丈夫だよー
55 :
2017/03/02(木) 19:24:50.56 ID:ZV5SMkF2H
>>50
人間よりは速い
56 :
2017/03/02(木) 23:03:10.15 ID:sITpgG7dd
gitを使うのが目的になってる奴がいるな
57 :
2017/03/02(木) 23:06:07.56 ID:qpimcWgg0
gitを使うのが目的じゃないけど結果的にgitを使ってるな
58 :
2017/03/02(木) 23:30:35.54 ID:GmcRpo7M0
gitを使ってるカッコいい俺
59 :
2017/03/02(木) 23:31:43.91 ID:em5mjT5q0
普通じゃ?
60 :
2017/03/02(木) 23:36:40.95 ID:XOZN9kk90
gitの使い方を覚えられないおっさんも世の中には居るんだ
61 :
2017/03/02(木) 23:42:40.19 ID:qpimcWgg0
使える人が使わないなら、それはいいんだよ。

能力不足で使えない(=無能すぎる)
会社のしがらみで使えない(=かわいそう)

あと使って見てないやつもダメだな
62 :
2017/03/03(金) 11:58:15.68 ID:SmLECISdd
Gitが使えない外注イラネ
63 :
デフォルトの名無しさん (JP)
2017/03/03(金) 12:30:04.87 ID:IUFykjWpH
篩に使うのはありか
64 :
2017/03/03(金) 21:00:59.00 ID:n9rn4mK30
なんでもいいから自分のソースくらい自分でコミットしろ。
65 :
2017/03/03(金) 21:35:27.51 ID:EvAeH8F3d
本当になんでもいいの?
66 :
2017/03/03(金) 23:39:23.71 ID:q5L7Z+jKM
masterにコミットしていいの?
67 :
2017/03/04(土) 00:19:50.00 ID:2pwhOacNp
結果にコミットしていいの?
68 :
デフォルトの名無しさん (ワッチョイ)
2017/03/04(土) 00:59:09.29 ID:kf4torcY0
面倒臭いのでだいたい
git add .
git commit --amend -m "hoge"

で済ましてる
一通り終わったらgit commit --amendでコミットメッセージちゃんと書く
squashしなくてよい方法だよ
69 :
2017/03/04(土) 03:38:59.15 ID:X3LbZrz10
70 :
2017/03/04(土) 11:03:44.63 ID:fiOXClU60
git merge --abort
git rebase --abort

これいいよな。

svnとかだとやらかしてしまって中途半端な状態になって
これどうすりゃいいんだよってなってしまうけど、
gitだとたいてい--abortすればリセットできる
71 :
デフォルトの名無しさん (ワッチョイ)
2017/03/04(土) 14:23:44.15 ID:GRvQ2lmz0
AにコミットしてA'
A'にコミットしてA''
になってるとき
A'をBに名前変えて
A->A''と
A->Bに分けることはできますか?
72 :
2017/03/04(土) 15:02:21.59 ID:fiOXClU60
git checkout 好きなコミットID

ブランチ名なんて最新のコミットに名前つけてるだけであって
コミットIDで全て参照できる
73 :
デフォルトの名無しさん (ワッチョイ)
2017/03/04(土) 17:15:35.10 ID:GRvQ2lmz0
A->A''の方にはB(A')が無かったことにしたいのですが
74 :
2017/03/04(土) 17:34:49.80 ID:NAI/204b0
説明がわかりにくすぎだろw
pushしてればrevertで
してなければrebase -iで
75 :
2017/03/04(土) 21:55:14.48 ID:X3LbZrz10
cherrypickでA''からAにパッチ当てりゃいいだけじゃね?
76 :
デフォルトの名無しさん (スプッッ)
2017/03/04(土) 22:05:36.70 ID:TK9n5Zigd
>>71
git branch B A'
をする
git rebase A -i
でA'の行を消す
77 :
2017/03/06(月) 23:20:15.96 ID:8UuxKa0s0
ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み

こう言う場合って作業完了してからまとめてコミットすべき?
それともキリのいいところでコミットすべき?
78 :
2017/03/06(月) 23:34:33.58 ID:hCzUBa9v0
適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね
79 :
2017/03/07(火) 15:02:30.70 ID:+1wYVpxF0
rebaseは甘え。 使ってはいけない。
80 :
2017/03/07(火) 18:29:12.37 ID:JtxH0L4+M
せっかくローカルにあるんだし、どんどんコミットしたら?
81 :
2017/03/07(火) 19:25:45.74 ID:deKTD69U0
rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫
82 :
2017/03/07(火) 20:49:12.26 ID:buHXdcTx0
rerebaseだと!?
83 :
2017/03/07(火) 20:55:44.46 ID:FdtwfqDL0
rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
rebaseしたってコミットそのものが世界からすぐに消えるわけじゃないんだし
84 :
デフォルトの名無しさん (エーイモ)
2017/03/07(火) 22:48:44.65 ID:6dT6PmkfE
git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください
85 :
2017/03/08(水) 00:28:53.24 ID:bFUfM0140
> rebase怖いならブランチ切るなりタグつけるなりして

そのブランチやタグを作るのが面倒なバージョン管理ツールがありまして、
そのせいでブランチやタグを切るのが嫌なんですよ。
86 :
2017/03/08(水) 01:12:08.47 ID:+/47+kY70
知らんがな
87 :
2017/03/08(水) 08:51:03.76 ID:dlE+7VUyM
ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。
88 :
デフォルトの名無しさん (エーイモ)
2017/03/08(水) 18:56:28.23 ID:tzSf6NwiE
(1)git checkout -b hoge コミットID1 でhogeブランチを作る
(2)masterブランチに戻る
(3)git branch -D hoge でhogeブランチを削除する
(4)git checkout -b hoge コミットID2 で異なるコミットのhogeブランチを作る

hogeブランチでは何かを編集したりするわけではないので
hogeブランチにいたまま別のコミットIDでhogeブランチを上書き?する方法ありませんか?
masterブランチに戻ってからhogeブランチを作りなおして新たに作るのが面倒くさいので
89 :
2017/03/08(水) 19:57:59.67 ID:AFnyce7m0
git reset --hard コミットID2
90 :
デフォルトの名無しさん (ワッチョイ)
2017/03/09(木) 06:48:45.74 ID:fQxPjt/z0
>>88
コミットIDでcheckoutすりゃいいだけじゃね

(1)git checkout コミットID1
(2)git checkout コミットID2
91 :
デフォルトの名無しさん (スプッッ)
2017/03/09(木) 08:26:50.81 ID:TQt2xuGKd
>>88
git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと
92 :
2017/03/09(木) 08:37:37.52 ID:K/l9Si6sM
>>82
リ・リ・リベース
アホデミー賞を総なめ
93 :
デフォルトの名無しさん (エーイモ)
2017/03/09(木) 10:28:24.13 ID:xGhx3aNSE
resetは困ります。。。。
checkoutでどうにかやる方法はないということでしょうか?
94 :
88=93 (エーイモ)
2017/03/09(木) 10:29:17.80 ID:xGhx3aNSE
ブランチは1個しか作りたくないんです
95 :
デフォルトの名無しさん (スプッッ)
2017/03/09(木) 12:31:57.97 ID:TQt2xuGKd
>>93
じゃあ>>90で良いんじゃないの?
コミットは出来ないけど
96 :
2017/03/09(木) 13:13:36.94 ID:x6aOWZGA0
>>88
git checkout hoge
git merge <commit>
97 :
2017/03/09(木) 13:42:24.50 ID:quKxBXU+0
>>93
なんでreset困るの?ブランチ消してる時点で同じことだと思うけど
resetしたってコミットが消えるわけじゃないよ
98 :
88=93 (エーイモ)
2017/03/09(木) 22:57:50.27 ID:DwjAxR0kE
git checkout -b hoge
git reset --hard コミットid1
git reset --hard HEAD@{1}
masterブランチには何の影響もないですね
最新のコミットに戻るときにreflogで位置を確認するのが面倒くさそうです
これも覚えておきます

>>96
mergeだと古いコミットに戻ろうとした時にAlready up-to-date.って表示されてしまいました
99 :
2017/03/09(木) 23:15:12.39 ID:x6aOWZGA0
hogeにはすでにコミット1やコミット2が含まれてる場合もあって
その場合はそれ以降のコミットを捨てた状態にしたいってことなの!?
用途が謎
100 :
2017/03/10(金) 03:45:25.28 ID:V4zus/a90
>>98
ブランチは1個しか作りたくない理由がわからないから、それだったらID1とID2に別のブランチを付けたら良いんじゃない?って思っちゃうんだけど
何で作りたくないんですか?
101 :
2017/03/10(金) 04:41:26.50 ID:hkfiatAK0
>>90のやり方がスルーされるからやりたいことと違うんだろうなあ
102 :
2017/03/10(金) 14:48:19.74 ID:y8xCqliG0
タグの代わりなんじゃ?
103 :
2017/03/10(金) 21:15:08.71 ID:mGr7V+b80
みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
する機能使ってる?

俺はファイル単位でしかコミットとかしないんだけどさ、そもそもステージング
してるところから行単位でまた編集するようなもんだから、テスト通るかわからなく
なるわけだし、あんまり積極的に使うもんじゃないよね。

あとdiffの結果画面の見方が今ひとつ苦手w
104 :
2017/03/10(金) 21:48:11.92 ID:cBCq3F3F0
>>103
使わんなー
105 :
2017/03/10(金) 21:51:35.65 ID:V4zus/a90
>>103
細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある?
106 :
2017/03/10(金) 22:13:50.48 ID:y8xCqliG0
git add -p のこと?
ならすげー使うけど
107 :
2017/03/10(金) 22:28:17.98 ID:gboOrvO30
git add -pの存在がsvnからの移行を決定づけた
108 :
2017/03/10(金) 22:51:42.82 ID:mJMnK6Gx0
俺もよく使うな。

gitの便利さっていうのは現実的な問題を解決してることにあると思っていて、
理想は最初に計画を立てて間違えることなく作業をすることだけど
現実にはいろんな細かい修正を忘れたり分けるべき修正を一緒にやってしまったりするでしょ?

そういう時に俺は、いま修正している中で、特定の部分だけgit add -pつかって
一つのコミットにして、あとの分は別コミットにして、
テストは後から書いてrebaseしてまとめるとかやるよ。

他の人が理解・レビューしやすい並びのコミットと、
実際の開発順っていうのは必ずしも一致しないからさ
109 :
2017/03/10(金) 23:30:38.30 ID:V4zus/a90
git add -pなら使う。行単位でステージングする機能、だよね?
110 :
2017/03/11(土) 06:24:50.89 ID:d5jme4tX0
>>108
SVN 使いだけどこの機能とローカルコミットはマジで欲しい
111 :
2017/03/11(土) 10:36:14.71 ID:JsoExgwjH
>>110
gitに乗り換えても良いんですよ?
112 :
2017/03/11(土) 11:07:52.10 ID:qCTmGWaIM
行単位使ってる人多いんだな
完全ファイル単位だわ
考え方古いのか
113 :
2017/03/11(土) 12:21:39.87 ID:d5jme4tX0
>>111
何となくだけど git は性に合わない
114 :
2017/03/11(土) 12:39:37.19 ID:vAAcV1Smd
>>113
おじいちゃんこんにちは
115 :
2017/03/11(土) 13:07:42.60 ID:/v3Qrvkv0
stash, cherry-pick, rebaseのないコーディングなんてもう考えられない
116 :
2017/03/11(土) 14:17:42.96 ID:qqD7bP3W0
試行錯誤のあととかノイズでしかないからな。
そんなものを大事に抱えていても、コードリーディングの
じゃまになるだけで意味が全くない。
快適な開発をするときに役立つコマンドがgitには多く搭載されている
117 :
2017/03/11(土) 16:27:54.83 ID:yCUlIQxq0
行単位とかやりすぎだろ。。
それなら作業者を統一するなり、ファイル分割するなりした方がいいんじゃねーの?
118 :
2017/03/11(土) 17:15:54.01 ID:qqD7bP3W0
作業者が独りだから、同じファイルを複数行編集するんだろw
119 :
2017/03/11(土) 18:39:00.61 ID:4afooUsq0
まとめてコミットするつもりで編集中だったワークツリーから
部分的に何行かコミットしてpushする必要ができたとか
けっこうある
120 :
デフォルトの名無しさん (ワントンキン)
2017/03/14(火) 16:00:30.11 ID:E+FUCYqdM
ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの?
121 :
2017/03/14(火) 16:01:15.03 ID:vbV/Jpv3H
>>120
git
122 :
2017/03/14(火) 16:49:48.82 ID:vIMzEjCF0
ワロタ
123 :
2017/03/14(火) 19:54:39.02 ID:6i3O/c5aM
はぁ?gitじゃタイムスタンプは戻らんから質問してんのにバカなの?
124 :
デフォルトの名無しさん (ワントンキン)
2017/03/14(火) 20:00:39.69 ID:gPjrDEpaM
もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ
125 :
2017/03/14(火) 21:49:01.07 ID:094BKVIr0
>>120
svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう
126 :
2017/03/14(火) 21:57:48.94 ID:olV+TTff0
gitはOSSなんだからHACKするなり自分で手を加えればいいのでは?
127 :
デフォルトの名無しさん (スプッッ)
2017/03/14(火) 22:06:05.44 ID:U+Sav0FRd
>>123
コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ
128 :
2017/03/14(火) 22:42:41.89 ID:olV+TTff0
適当なツール使えばいいじゃん

https://github.com/search?q=timestamp+git
129 :
2017/03/15(水) 01:16:30.21 ID:GKUdhRYR0
タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの?
タイムスタンプはOSごとのローカルな仕様っぽいのでGit本体には入れなくないってこと?
130 :
デフォルトの名無しさん (ワッチョイ)
2017/03/15(水) 01:23:09.75 ID:1ghxI2bb0
全く欲しいと思ったことが無いけど何に使うの?
131 :
2017/03/15(水) 02:50:18.09 ID:Kz3kbyRR0
>>130
あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか?
132 :
2017/03/15(水) 04:09:45.52 ID:UbexXnp10
そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな
133 :
2017/03/15(水) 07:04:46.81 ID:GKUdhRYR0
Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
134 :
デフォルトの名無しさん (ワッチョイ)
2017/03/15(水) 07:44:08.96 ID:1ghxI2bb0
>>131
今時そんな事してる現場なんてあるわけないじゃん?
135 :
2017/03/15(水) 08:18:02.75 ID:WjEGzhMP0
>>129
記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。

ファイルの日付どころか行単位で
修正日時が記録されているので必要ない
136 :
2017/03/15(水) 08:32:23.84 ID:WjEGzhMP0
>>133
> Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります

Aというブランチでファイルを追加します。
Aブランチから派生したBというブランチでそのファイルを修正します。
Bというブランチでコンパイルしてオブジェクトファイルを作ります。
Aというブランチに戻ります。

Bというブランチでコンパイルしたオブジェクトファイルが残っています。
ファイルの日付はリポジトリに入れないのでAの方が更新日付が新しくなります
そのためコンパイルするとBのオブジェクトファイルは使用されません。
という素晴らしい仕組みはgitだけの特典だとでも?

あんたはどうしてもほしいの?
137 :
2017/03/15(水) 10:18:23.23 ID:8jeOIUNnM
結論:Gitは素晴らしい仕組
138 :
2017/03/15(水) 10:22:20.47 ID:8jeOIUNnM
流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
所詮は℃素人の烏合の衆かw
139 :
2017/03/15(水) 10:35:49.13 ID:enIXRUuud
gitを使うことが目的になってるからな
140 :
2017/03/15(水) 12:42:56.93 ID:7YWEdixI0
>>135
ごもっとも
だけどFAQでこの文章みた記憶がない
141 :
2017/03/15(水) 12:45:29.83 ID:7YWEdixI0
>>138
commit時の日時だっけ?
checkout時の日時だと思ってた
142 :
2017/03/15(水) 12:52:42.68 ID:kqJ31I++M
チェックアウトの度にタイムスタンプが書き換わっていたらさらに大混乱のような

手元にないから誰か試して
143 :
2017/03/15(水) 13:05:12.43 ID:7YWEdixI0
>チェックアウトの度にタイムスタンプが書き換わっていたら

その時点で存在しないファイルとかチェックアウトの結果変更されるファイルのタイムスタンプの話なんですが
144 :
2017/03/15(水) 13:06:14.60 ID:T3K1qf0+0
>>138
馬鹿がばれるからやめとけ
145 :
デフォルトの名無しさん (ワッチョイ)
2017/03/15(水) 16:57:44.56 ID:1ghxI2bb0
>>133
で、何に使うの?
146 :
2017/03/15(水) 22:27:20.10 ID:WjEGzhMP0
チェックアウトっていうのは手元のファイルを書き換えているわけで
ファイルの更新日付は変わるほうが動作として正しいんですよね
147 :
2017/03/16(木) 08:39:50.82 ID:kc3kp+lPM
ユーザー視点からはタイムスタンプごと戻るほうが正しいだろ。

システムの都合を言われても知らんわ。
148 :
2017/03/16(木) 09:06:14.81 ID:jj6/8HdQ0
ユーザー視点ってなんだ?
バージョン管理ツールは開発者視点のものなんだが。

バージョン管理ツールができる以前から
makeはタイムスタンプを参照して更新されたものだけを
ビルド、リンクする。

checkoutしてブランチを切り替えてファイルが変わったら
当然ビルド、リンクしなきゃならないんだから、タイムスタンプは
新しくなくちゃいけないだろ。

バージョン管理ツールはバックアップツールじゃないんだぞ
開発者じゃないやつが使うものじゃない
149 :
2017/03/16(木) 09:28:08.60 ID:EaMVfj+z0
>>147
システムの都合じゃなくて、ユーザー(開発者)視点から
ビルドしやすいようにあえて日付を更新してる
150 :
2017/03/16(木) 11:09:03.98 ID:WA6lSXVKM
それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含めそっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

上の流れを要約するとそういうこと
151 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 11:18:06.56 ID:F3E/ISVf0
>>150
誰も何に使うか挙げれてないのに?
152 :
デフォルトの名無しさん (ブーイモ)
2017/03/16(木) 11:50:16.25 ID:aO6lZIizM
gitの操作によって更新されたファイルのタイムスタンプをユーザが参照出来ないとか、ユーザーにとって拷問じゃね?
153 :
2017/03/16(木) 11:59:54.91 ID:XUhAFY4kd
タイムスタンプの参照方法も知らんのか
154 :
デフォルトの名無しさん (オッペケ)
2017/03/16(木) 12:19:13.00 ID:1l8QOGUAr
大体お前ら殆どペチパーだろw
そもそもビルドプロセスなんかねえじゃんw
155 :
2017/03/16(木) 12:54:44.92 ID:WA6lSXVKM
ペチパーてなに?
156 :
2017/03/16(木) 13:30:19.82 ID:dChQd8LQ0
プロパーのことかな
157 :
2017/03/16(木) 14:26:14.45 ID:N9tvbPpS0
https://www.indeed.com/jobtrends/Java,JavaScript,Perl,PHP,Python,Ruby,Scala.html
ペチパー=PHPerだけど、PerlとPHPの仕事は減る一方で3年以内にScalaに追い越される。
JavaとScalaはコンパイルのために、JavaScriptはトランスパイルのためにビルドが必要だ。
158 :
2017/03/16(木) 14:37:48.23 ID:tDvUwYEMH
でも、githubなんかのリポジトリブラウザでlast commitが一覧できるのは便利。
ファイルの更新具合が一目瞭然。
git cloneのデフォルト動作がlast commitを復元するのでいいとさえ思う。
159 :
2017/03/16(木) 14:42:25.18 ID:tDvUwYEMH
タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
ビルドしたときのハッシュを保存しておいて、違ってたらビルド(コンパイル)対象にするとか。
160 :
デフォルトの名無しさん (ワントンキン)
2017/03/16(木) 14:57:26.15 ID:1IuM6Iv2M
>>159
遅くなるだろ。何のためにタイムスタンプ単純比較してると思ってるんだ。
161 :
2017/03/16(木) 15:21:13.16 ID:tDvUwYEMH
>>160
> 遅くなるだろ
そうでもない。

243ファイル10万行のハッシュ値計算:
$ ls *.[ch] | wc -l
243

$ wc -l *.[ch]
102429 合計

$ time md5sum *.[ch] > /dev/null
real 0m0.014s
user 0m0.008s
sys 0m0.006s
162 :
2017/03/16(木) 15:57:58.78 ID:qLAiRgHgM
Git真理教信者はGitはとにかく正しいのだという盲信から発言するから、自分とは違ったニーズを持つ他者がいるという想像もできないし、そもそもエビデンスを出しての議論ができないんだよなあ
口汚く罵るだけで
163 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 18:08:47.10 ID:Xe646fvV0
>>150
初心者はとまどうのかもしれないが
慣れたら問題ないことに気付く

どうせ秀丸でも使ってるんだろ
164 :
2017/03/16(木) 18:35:50.30 ID:Ko8IVZtl0
hookで実現する方法はあるし、必要ならそれを使えばいいだけだと思うんだがどうしてその機能がデフォルトで用意されてないだけでそこまで喚くのかわからない
165 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 18:40:51.93 ID:6u/sVXZC0
>>164
わからなければ参加しなくてもいいんですよw
166 :
2017/03/16(木) 18:45:10.48 ID:DHYgGwbjM
公式のgit guiもネイティブのwindowsソフトのくせに日本語含んだディレクトリ名とか未だにダメダメだな
この時代に他言語対応がここまでダメなメジャーなソフトも珍しいんじゃね?
167 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 19:10:46.07 ID:Xe646fvV0
git for windows ならいける
168 :
デフォルトの名無しさん (ワンミングク)
2017/03/16(木) 19:14:58.70 ID:Zmwuwj98M
>>166
まったく珍しくないけど。
ユーザー名に日本語含めないようにするというバッドノウハウが広まってるのがいい証拠
169 :
2017/03/16(木) 19:25:54.89 ID:0IkihSnt0
あれがだめだ
これもだめだ
文句ばっかり一人前
170 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 19:42:09.30 ID:6u/sVXZC0
>>169
少しは文句ばっかり言われる自分を省みてみたらw
171 :
2017/03/16(木) 19:53:27.96 ID:0HPyU1HgM
>>167
サンクス
そうなんだ。試してみる。
172 :
2017/03/16(木) 23:09:13.57 ID:6N+4it80p
結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ?
煽るにしたってgitに取って代わるようなツールを挙げてくれないと面白くないんだけど
173 :
2017/03/16(木) 23:28:53.65 ID:w4Havbm70
お前が面白いとかつまらんとかほんとどうでもいい
言うことないならスレ汚さずに黙ってろ
174 :
2017/03/16(木) 23:50:24.62 ID:EaMVfj+z0
>>150
> それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

gitの思想じゃない。ソフトウェア開発の思想。
最新のタイムスタンプのものだけビルドするという考え方は
gitができるよりはるか昔からのやり方

gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ?
175 :
デフォルトの名無しさん (ワッチョイ)
2017/03/16(木) 23:59:09.02 ID:6u/sVXZC0
>>174
gitしか知らないぺーぺーのひよっ子が面白い事言うなw
お前センスねえわw
176 :
2017/03/17(金) 00:01:17.52 ID:KqZX+Igl0
そもそも
>gitの思想と違う
なんて発言は誰もしてないのに、さもそんな発言があって、それが共通認識であるかのように語る

病気ですね
177 :
2017/03/17(金) 00:07:16.69 ID:lgb+n3WO0
>>175
svnも知ってるが?

svnを使っているときからsvnはだめだと理解していた。
gitを知った(がまだ使えない)ときから、俺が欲しかったのはgitだと理解できた。

svnはすごく開発しづらかった。なにせ間違いが許されないから。
人間だから間違いはかならずある。svnだと間違いが許されなかったから
仕事を一旦片付けて(コミットして)落ち着いて確認するという作業ができなかった。

間違いは間違いのまま残り、意味のないコードを他の人にレビューさせるのが
すごく無駄に感じた。それが解消されたのでgitはすごくストレスフリーだよ。
178 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 00:11:39.15 ID:HumUZXIf0
>>177
いや知らねえよお前はw
それどこのインターネッツで拾ってきたgit神話だよw
179 :
2017/03/17(金) 00:20:09.47 ID:lgb+n3WO0
>>178
なんで俺の書いた内容に反論しないの?w
180 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 00:23:50.09 ID:HumUZXIf0
>>179
それはこっちのセリフだよwぺーぺーのひよっ子クンw
181 :
2017/03/17(金) 00:27:58.36 ID:lgb+n3WO0
このように必死になるのがワロエルw
182 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 00:33:43.21 ID:RKn5d9hw0
>>161
例えばGoogle Chromeとか1000万行以上、ファイル数も数万個あるんだよなぁ、そこまで大きなプロジェクトはあまり無いだろうけどさ。
ハッシュをDBか何かにファイルパスのようなuniqueな値と合わせて書き込まなきゃならないだろうし、画像などのリソースを固めるなら大きめのファイルのハッシュも計算しなけらばならないだろう。そのベンチマークはちょっと見通し甘いと思う。
183 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 00:34:13.23 ID:HumUZXIf0
>>181
なんだよもう諦めたのかw
俺はもっと笑いたいんだけどなw
もっと聞かせてくれよぅ
ひよっ子クンのソフトウェアなんとかwの思想w
184 :
2017/03/17(金) 00:50:55.73 ID:CHXjDOQAp
構ってもらえて嬉しそう
よかったね
185 :
2017/03/17(金) 01:35:25.41 ID:g7c8SdZF0
>>174
なんかよくわからんけど、例えば一年前にコミットしたmakeファイル含むビルド環境一式があって、
それを再現したいとき、オプションでタイムスタンプも含めてぜんぶそのときの環境が再現される
オプションがあればそれはそれで便利じゃないの?
186 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 01:45:34.43 ID:RKn5d9hw0
>>185
だから何が便利なの?
タイムスタンプを再現して何が嬉しいの?
標準に入れろっていうくらいなんだから大多数が納得するようなメリットを示せるはずだよね?
それがこのスレで一つも出てきてないんだけど
187 :
2017/03/17(金) 01:50:24.59 ID:KqZX+Igl0
>>185
>それを再現したいとき
それってどんな時?ってのが行き着くところだと思うよ
上の方でもちらほら出てるけど、必要なら実装すれば良いし、必要だと思う人が多ければ標準の機能として組み込まれるでしょ
188 :
2017/03/17(金) 02:44:39.70 ID:lgb+n3WO0
>>185
日付が戻るのはソースファイルだけ。
そのソースファイルを使ってコンパイルすると
オブジェクトファイルができる。
"現在の日付の"オブジェクトファイルができる。

その"現在の日付の"オブジェクトファイルをリンクして
"現在の日付の"実行ファイルができる。

出来上がるのは現在の日付のファイルばっかり

で、なんか言った?
189 :
2017/03/17(金) 03:08:37.61 ID:gNJfFjGV0
まぁ git checkout でブランチ変えるたびに make clean なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな

タイムスタンプを復元して何が嬉しいのか良く分からないけど
(ファイルに変更を加えた日を知りたいだけなら適切にコミットしてたらファイルに手を加えた日とコミットした日に大きな違いはないだろうから確認に困るってことはないし)

git以外の何らかの管理ツールがタイムスタンプで何らかの整合性を保っててその管理ツールのデータファイルもgitリポジトリに一緒に突っ込んでるとかかなあ?
190 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 03:38:39.20 ID:RKn5d9hw0
>>189
そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。
191 :
2017/03/17(金) 03:47:35.77 ID:lgb+n3WO0
普通に考えて日付が違っていてもコンパイルすれば
同じ実行ファイルができるべきである。

でないと、ファイルを保存し直しただけで
違う物ができることになってしまう
192 :
2017/03/17(金) 08:32:42.50 ID:dpI1G6OFM
>>188
いや >>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが
193 :
2017/03/17(金) 08:39:41.92 ID:pWaboA+Ja
>>191
そもそも具体的に何のためにそんなことしたいのかが分からないな
194 :
2017/03/17(金) 09:05:02.21 ID:lgb+n3WO0
>>192
じゃあバックアップツール使え馬鹿で終わりだなw
195 :
2017/03/17(金) 09:21:50.26 ID:u9tsLZrBM
意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw
196 :
2017/03/17(金) 09:28:24.44 ID:lgb+n3WO0
じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
言い続けるかwww
197 :
2017/03/17(金) 11:36:42.96 ID:hpHy/rBLH
>>182
まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。

つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ?
198 :
デフォルトの名無しさん (JP)
2017/03/17(金) 12:07:10.25 ID:ol/nseXLH
>>189
秀丸ですねわかります
199 :
デフォルトの名無しさん (JP)
2017/03/17(金) 12:08:06.93 ID:ol/nseXLH
>>195
それは永遠にないわ
200 :
2017/03/17(金) 12:09:21.75 ID:w8cg3b8g0
>>196
gitでタイムスタンプを管理しないのは失敗だったかも
(でも今更だし悪い仕様でもこのまま乗り切るわ)

と講演で言っていたよね
201 :
2017/03/17(金) 16:41:29.29 ID:ABuej+2JM
>>196
やっすいことで満足できんだなあお前って
悲しくない?
202 :
2017/03/17(金) 18:58:28.73 ID:g7c8SdZF0
>>200
なんだライナスも悪い仕様ってみとめてんだ
203 :
デフォルトの名無しさん (エーイモ)
2017/03/17(金) 20:33:35.90 ID:vzlc7+0GE
プロジェクトを作り直してコードもファイル構成も全部作り直す場合は
gitでブランチを作成して底で作業するか、別のディレクトリを作成してそこで作業するかどっちがいいでしょうか?
204 :
2017/03/17(金) 20:46:01.32 ID:lgb+n3WO0
>>200
ああ、アイツだろ? 名前忘れたけど
あとでTwitterとかで馬鹿にされまくってて
アカウント削除して逃げちゃったやつ

>>202
> なんだライナスも悪い仕様ってみとめてんだ
ライナスのことじゃないよw
205 :
2017/03/17(金) 20:51:50.50 ID:lgb+n3WO0
リーナスは「なんでお前、タイムスタンプを戻すのが間違ってるってわかんねーの?馬鹿なの?」って
煽ってるしなw


Linus Torvalds
https://web.archive.org/web/20120701070035/http://kerneltrap.org/mailarchive/git/2007/3/5/240530
> But Bill, don't you realize that restoring the timestamp is *WRONG*?



スレトップ
https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536
206 :
2017/03/17(金) 20:57:08.80 ID:lgb+n3WO0
リーナス・トーバルズ曰く

https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536
>
> それは間違い
>
> それは馬鹿
>
(gitでタイムスタンプを管理なんて)
> ぜってーに実装しねーよwwww


リーナスにも煽られちゃったなwwww
207 :
2017/03/17(金) 21:53:41.23 ID:BNQrAo9GM
調べてみるとvsもcsvもsubversionも当然のようにタイムスタンプ復活できるんだな
リーナスの手を離れたわけだしメンテやってるあの人もそんな当たり前の機能はとっとと実装して欲しいもの
208 :
2017/03/17(金) 22:09:18.47 ID:lgb+n3WO0
つまりgitは進化したってことだな(爆笑)

はいはい、なんでsubversionでタイムスタンプ復活させるのが
間違ったやり方だって言われていてデフォルトオフなのか考えてみましょうか
209 :
2017/03/17(金) 22:12:32.69 ID:lgb+n3WO0
>>207
あ、ぶっちゃけさ、お前

gitでタイムスタンプを管理しないのは失敗だったと
リーナスが言ったと嘘を言ったのがバレたから、
調べてきたろ?w
210 :
2017/03/17(金) 22:27:18.70 ID:oBXg3cgS0
git logからコミット日時引っ張ってくるシェルスクリプト書きゃいいだけなのに、標準で入れるまでもないだろう
211 :
デフォルトの名無しさん (ワッチョイ)
2017/03/17(金) 23:07:30.79 ID:RKn5d9hw0
>>207
焦らしてないで教えてよ。何に使うの?
212 :
2017/03/17(金) 23:35:47.42 ID:gNJfFjGV0
>>210
わざわざ自分で書かなくてもGitHubとかで誰かがその手のツール作ってるだろうからそれ使えばよくね?
213 :
2017/03/18(土) 00:05:08.09 ID:zaoPrLbB0
Linus教はLinusが言ったことは全て真理というドグマで洗脳されているのか。
そりゃ議論にならんわけだw
214 :
2017/03/18(土) 00:11:39.83 ID:3XCCJELr0
議論したかったら用途くらい考えてから来いよ
215 :
デフォルトの名無しさん (ワッチョイ)
2017/03/18(土) 00:14:57.35 ID:ux+WuUO90
Linusが言ったとデマ飛ばして、それを否定したら >>213 コレ
議論したいやつには全く見えない
216 :
2017/03/18(土) 00:17:21.58 ID:zaoPrLbB0
そんなこと誰もいってねーじゃん
病気なのお前?
217 :
2017/03/18(土) 00:19:04.49 ID:zaoPrLbB0
>>167
>git for windows ならいける

そういやこれ試してみたがちゃんと日本語ディレクトリや空白いりディレクトリでもちゃんと動作するな。
なんで公式のGUIツールはあんなクソがいつまでもほったらかしなんだ?
メンテナの出来が悪いのか?
218 :
デフォルトの名無しさん (ワッチョイ)
2017/03/18(土) 00:19:13.30 ID:ux+WuUO90
219 :
デフォルトの名無しさん (ワッチョイ)
2017/03/18(土) 00:33:25.67 ID:ux+WuUO90
>>217
彼らにとってWindows版が必要ないからかな
220 :
2017/03/18(土) 06:56:38.21 ID:zyxHQlVL0
git gui普通に日本語ディレクトリ名を表示できたけど・・・?
221 :
デフォルトの名無しさん (ワッチョイ)
2017/03/19(日) 03:20:17.16 ID:awlj00/Y0
>>203
新しいリポジトリ作るほうがいいと俺個人は思う
222 :
2017/03/19(日) 13:22:53.84 ID:mGXfpPMY0
gitでコードを管理している分にはタイムスタンプを戻すのは愚策だと思う
(Linusもそこはハッキリ言っている)

コード以外のファイルを管理するならタイムスタンプを戻せるようにすべきだし
cvsやsvnは実際に戻せる仕様になっている

要するにgitではソースコード以外は管理できないし、させたくもない
(Linusはこれもはっきり言っている)
だからタイムスタンプも戻さない
223 :
2017/03/19(日) 13:31:01.38 ID:Ua2nNRR50
ExcelとかビットマップまでGitで管理しようと主張するマヌケが会社にいて困るわ。
適材適所ってことがわからなくて、なんでもGitが優れていると盲信してる。
224 :
デフォルトの名無しさん (アウアウアー)
2017/03/19(日) 14:04:20.89 ID:mYROXWJoa
>>223
おかしくないけど?
225 :
デフォルトの名無しさん (アウアウアー)
2017/03/19(日) 14:06:20.27 ID:mYROXWJoa
>>223
決めの問題だからそう決めたなら、Gitで管理すればいい。成果物によって数ヶ所に置き分けないといけないよりまし。
226 :
2017/03/19(日) 16:31:47.33 ID:mGXfpPMY0
>>224
決めの問題ならなおのこと 決めたやつがおかしい という話では

実際のところ、テキストベースではないドキュメントの管理は
gitでやる価値が半減すると思う
もちろんcvsやsvnでもあまり意味はないけど
227 :
2017/03/19(日) 17:05:26.08 ID:iE0mqC8JM
>>223
困るならちゃんと説明してあげるか転職して会社変わったほうがいいよ
228 :
2017/03/19(日) 17:10:53.15 ID:zGHcaEctH
節目節目のあるリリースに関連付けられた形での
重要なデータとかテストデータとかをコミットに加えるのはありでしょ
229 :
2017/03/19(日) 17:34:08.84 ID:IinMJCLx0
>>227
説明しても聞かないって話だろ
盲信ってことばも知らんのか?
230 :
2017/03/19(日) 18:21:18.84 ID:Ua2nNRR50
なんだGitに向き不向きがあるよって話だけでここまで怒り狂うのか
怖いわほんとw
231 :
デフォルトの名無しさん (ワッチョイ)
2017/03/19(日) 18:52:47.95 ID:GmJCDs4Q0
diffが取れない程度でべつにエクセルのファイルを管理してもいいと思うけどね。
向かないとかいっても 20170319-hogehoge.xls みたいなファイルが山盛りよりはいいと思うな。
232 :
2017/03/19(日) 18:54:26.01 ID:awlj00/Y0
ここでもめてるgitの話題って英語圏のフォーラムとかでも似たようなやりとりあったりすんのかな
please recovery timestamp!って
233 :
2017/03/19(日) 19:30:28.68 ID:nRqPseDT0
実質的にタイムスタンプ復元する方法が提示されて終わりじゃない?まともなフォーラムなら

どんなケースでどんな機能を求めてて何を試してみたかを全く明らかにしようとしないまま機能が足りないって喚いてるだけだからなぁ
建設的な議論にならないよね。
234 :
2017/03/19(日) 20:08:02.32 ID:IinMJCLx0
235 :
2017/03/19(日) 20:51:27.65 ID:A9u3VMEFM
>>229
知らなかったから辞書で調べてから書き込んだんだけど…
なにか気に触ったのならゴメンな
236 :
デフォルトの名無しさん (ワッチョイ)
2017/03/19(日) 21:16:00.33 ID:s3dEl3fs0
>>234
Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うw
237 :
2017/03/19(日) 21:23:49.85 ID:HZYtfAfs0
WindowsでGUIのものを使おうと思ったら・・・・
お勧めって、亀さん?
238 :
2017/03/19(日) 21:48:28.76 ID:szsTqBFI0
git archiveで作ったzipのタイムスタンプって
コミット時の時刻になってない?
239 :
2017/03/19(日) 22:34:24.09 ID:Lj5IhMr80
>>231
Excelはxmlになってからdiffとれるでしょ
見やすいdiffが必要なら専用のツールが必要
240 :
2017/03/19(日) 22:57:18.43 ID:awlj00/Y0
241 :
2017/03/20(月) 09:41:20.76 ID:MXp+WHcu0
そういや最近TortoiseSVNでexcelやwordファイルのdiff見たら、Office自体の
変更差分表示機能使ってくれて驚いた。
gitはコマンドラインでしか使わないから知らないが、どうなんだろう。
242 :
デフォルトの名無しさん (アウアウアー)
2017/03/20(月) 13:11:24.09 ID:ioazcijZa
>>241
あのさ、差分機能で更新箇所を確認するのは仕事のやり方としては下策で、仕方なくやるものなんだけどな。
243 :
2017/03/20(月) 13:29:20.77 ID:XpvRbpIm0
だからなに?
244 :
2017/03/20(月) 13:59:55.23 ID:LcNjV7jZ0
>>242
上級者のやり方教えてくれ w
245 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 14:42:33.04 ID:nkICAmgQ0
プログラミングにかかわらずドキュメントの類は差分ベースで仕事を進めることで効率が著しく向上する
これに気がついてない日本のホワイトカラーの現場はほんとヤバイ
246 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 14:45:08.86 ID:NCsVeUw30
オイまた拗らしちゃったのが出てきたぜw
247 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 14:52:58.33 ID:+YHRRlIg0
Excel仕様書なんか捨ててMarkdownとかで書いた方がいいこと多いよね
軽いし差分比較も見やすいし
248 :
デフォルトの名無しさん (アウアウアー)
2017/03/20(月) 14:59:20.46 ID:ioazcijZa
おまえらどこをどう変えたのか毎回忘れて差分比較して仕事してんのかよw
249 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 15:05:10.03 ID:+YHRRlIg0
>>248
お前の所は作った本人しかドキュメント読まないのか?
250 :
2017/03/20(月) 15:05:18.55 ID:nkICAmgQ0
わざと忘れたりするわけじゃないが
最近は差分を積み上げてくような感じで仕事をしてる
できうる限りそれで進めて、どうしようもない時だけ時間をかけて全体を見る
251 :
2017/03/20(月) 15:09:35.83 ID:nkICAmgQ0
>>249
共同作業の場合は更に効果倍増だな
でも、おれは一人でも作業する場合も、差分ベースで作業を進めることが劇的に効率を上げると思ってる
252 :
デフォルトの名無しさん (アウアウアー)
2017/03/20(月) 15:28:42.55 ID:ioazcijZa
レベルが低すぎて話にならん
253 :
2017/03/20(月) 15:39:14.64 ID:LcNjV7jZ0
>>247
個人的には AsciiDoc 使ってるんだけど他にお勧めある?
254 :
2017/03/20(月) 15:40:55.13 ID:LcNjV7jZ0
>>252
もう逃げ恥モードかよ w
255 :
2017/03/20(月) 15:47:00.13 ID:nkICAmgQ0
>>252
あんたにとってはgitもレベルが低い仕組みなんだろうな
でもこれが普及して他のツールを駆逐してしまった意味をよく考えてみた方がいいぞ
256 :
2017/03/20(月) 16:05:06.81 ID:1UoT8BnQ0
全然駆逐してないんだけどな
SVNもP4も普通に使われてる
257 :
2017/03/20(月) 17:02:29.72 ID:ixIx9fRF0
>>255
駆逐してねーよ
258 :
デフォルトの名無しさん (ブーイモ)
2017/03/20(月) 17:31:37.67 ID:IH4X2rRzM
もうgit以外を使ってるのは普通じゃない
特殊な事情
259 :
デフォルトの名無しさん (アウアウアー)
2017/03/20(月) 17:37:45.35 ID:ioazcijZa
>>255
おまえのことなど知らない
260 :
2017/03/20(月) 17:47:53.18 ID:nkICAmgQ0
>>259
で、gitのことはどう思ってるの?
差分を編集する機能を重視してるのがgitなんだけど
差分機能で更新箇所を確認するのが下策だと思ってる人はこれを受け入れちゃうわけ?
261 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 17:58:26.24 ID:j9IxIyz40
>>260
gitやその他vcsのことを何もわからずに煽ってるだけなんだから、
そんなに難しい質問してやるなよ。無視するしかなくなるだろ。
262 :
2017/03/20(月) 19:06:09.70 ID:DOhv8ff5d
>>242
頭おかしい
263 :
デフォルトの名無しさん (エムゾネ)
2017/03/20(月) 19:09:27.54 ID:CYCZfEErF
>>237
亀はだめ
Explorereが劇重になる
264 :
デフォルトの名無しさん (ワッチョイ)
2017/03/20(月) 19:50:34.58 ID:KXLYvEOG0
>>258
新しいプロジェクトに配属されて、バージョン管理がSVNだったらガッカリするからな
265 :
2017/03/20(月) 21:52:06.09 ID:qIiVvRhT0
>>236
> Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うw
ファイルのタイムスタンプだろ?
保存してないよ。

嘘だと思うのなら、ファイルを修正してから次の日にコミットしてみ
ファイルのタイムスタンプじゃないものが保存されるから
266 :
2017/03/20(月) 23:40:00.30 ID:oLSEmtobM
>>265
頭大丈夫か?
267 :
デフォルトの名無しさん (ワッチョイ)
2017/03/21(火) 00:33:18.86 ID:9goWKttg0
>>260
Office製品の変更履歴機能の失敗も知らない世代なのか?
268 :
2017/03/21(火) 00:37:26.92 ID:KGQ11aI90
>>266
え? そんだけ?
269 :
2017/03/21(火) 00:49:07.64 ID:1pi9Zbm10
>>267
それがどうしたんだよw
270 :
2017/03/21(火) 00:55:25.33 ID:KGQ11aI90
バイナリファイル系は適切なツールを使えば
差分を知ることはできるが、
差分を知る以上のことはできない。

例えばcherry-pickとかmergeとかね

ただsvnとかでバックアップツールとしか
見てなかったやつは、そもそもmergeとかいう概念がないから
差分だけわかればいいと勘違いしてしまう。

それじゃプログラマとはいえない。
271 :
2017/03/21(火) 01:17:05.94 ID:VJPcfHdS0
officeのドキュメントを差分管理ベースで作業できるようにするなら
ドキュメントの中の要素を個別に差分取って管理できるようにならないとダメだろうなあ

アプリのソースが一つのファイルにすべて書かれてて、
それをgitで管理しろとか言われたら気が狂うw
272 :
2017/03/21(火) 01:37:41.67 ID:xwYJW6M40
複数のブランチを切ることがそもそもない環境なら、mergeとか知らなくてもしょうがない
273 :
2017/03/21(火) 01:39:23.98 ID:1pi9Zbm10
>>271
ZIP解凍した中身をgitで管理
pullで自動圧縮するようにできればお望みのことが実現するのだが
274 :
2017/03/21(火) 02:02:40.95 ID:VJPcfHdS0
>>273
docxとかだよね?あれの中身って文章が構造的に分割されてるわけじゃなくて
単にスタイルとかイメージとかが分離されてるだけじゃないの?
275 :
2017/03/21(火) 02:10:13.49 ID:1pi9Zbm10
>>274
それでもXMLだから差分は一目瞭然かなと

xlsxやpptxならシート/ページごとにXMLファイルが分かれるからもっと管理しやすいかも
276 :
2017/03/21(火) 02:14:24.08 ID:jV0Y+t/Y0
>>270
行単位の処理とかは無理かもだけどcherry-pickやmergeはできるんでない?
277 :
2017/03/21(火) 02:16:22.53 ID:VJPcfHdS0
>>275
少なくとも、差分を見ただけでどの章のどこが更新されたかが分からないとつらいかな
ドキュメント全体をひとつのxmlで管理するなら
そういう機能をもった差分ビューワが必要になると思う
278 :
2017/03/21(火) 02:19:18.55 ID:1pi9Zbm10
>>277
そういう目的ならExcelかPowerPointってことになるかね
279 :
2017/03/21(火) 02:23:17.75 ID:jV0Y+t/Y0
Office用の見やすいGUIの差分ビューワもあるけどたいてい有償だから
まずはここに書いてるのから試してみたら
http://qiita.com/shuhei/items/6a18d968051378d7ac1a
280 :
デフォルトの名無しさん (ワッチョイ)
2017/03/21(火) 03:53:28.35 ID:vLQCNfD00
>>275
差分見えてもmergeはconflictの山になって事実上無理ぽそう。
281 :
2017/03/21(火) 09:23:16.21 ID:e/VBfIvSp
ここで言うことでもないけど
いい加減Officeを卒業したい
282 :
2017/03/21(火) 09:26:11.18 ID:A2xILC47M
早く画面キャプチャをExcelに貼る作業にもどるんだ
283 :
2017/03/21(火) 09:41:34.15 ID:KGQ11aI90
>>275
> それでもXMLだから差分は一目瞭然かなと

え? お前OfficeのXMLのタグを知ってるの?
XMLのタグを知っていないと、差分は分かっても
その意味はわからないよね?

>>280
> 差分見えてもmergeはconflictの山になって事実上無理ぽそう。

XMLのタグの整合性、つまり閉じタグの対応まで
ちゃんとやらないとだめだからねw
タグの意味、属性、誰か解説してる人いる?
284 :
2017/03/21(火) 09:46:31.05 ID:dDb6xsPz0
Excelファイルのバージョン管理なんて実質タイムスタンプで管理するしかないのに、とにかくGit真理教の信者は
なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す
285 :
2017/03/21(火) 09:56:27.64 ID:e/VBfIvSp
gitがバイナリに弱いのは誰もが認める話だと思うけど、タイムスタンプで管理するのは無くない?
svnとか他のバージョン管理システムってタイムスタンプ見て管理なんかしてたっけ?
286 :
デフォルトの名無しさん (スプッッ)
2017/03/21(火) 10:41:32.81 ID:CAHXK6Wdd
>>270
適切な扱いが出来るかはそのバイナリファイルを扱うソフトウェア次第
3wayマージが出来るならgitの機能は全部使えるだろう
287 :
デフォルトの名無しさん (スプッッ)
2017/03/21(火) 10:47:26.85 ID:CAHXK6Wdd
>>285
gitがじゃなく、汎用バージョン管理システム全般が、個々のファイル仕様に独自に対応しなければならないファイルに弱い
というより、テキストファイルのシーケンシャル性と改行で意味分割する仕様が特別汎用性に優れてるだけ
gitはエディタも差分表示もマージツールもファイル属性に応じた外部ツールを使用出来るようになってるから、まだそういう仕様が不明なファイルに強いと言える
gitが弱いのはバイナリファイルではなくサイズが巨大なファイル
たとえテキストファイルでも1ファイル1Gとかになると扱い辛い事になるはず
288 :
デフォルトの名無しさん (エムゾネ)
2017/03/21(火) 10:56:57.56 ID:2pW378OvF
>>284
excelは標準では同じファイル名のファイルを同時に複数開けないし開いただけでタイムスタンプが変わるから、ファイル名でバージョン管理するのが基本だと思うけど
どうやってタイムスタンプでバージョン管理するんだ?
289 :
2017/03/21(火) 14:58:44.05 ID:6WWBsw/3F
>>265
どうでもいいけどファイルのタイムスタンプを保存している(する必要がある)なら
ファイルの中身を変更せずにファイルの日付だけ変更してコミットしたときに
何も変更されてねーコミットスルーしよーぜってのがgit
それもファイルの変更とみなしてコミットするのはあほ
290 :
デフォルトの名無しさん (エーイモ)
2017/03/21(火) 16:43:16.40 ID:RUBeb/rgE
指定した範囲のコミットログを表示する方法を教えてください

例えばhttps://github.com/git/git/releasesなら
タグv2.11.1からv2.10.0の間のログのみgit logで表示したい
タグがダメならコミットIDで指定でも構いません指定した範囲のログさえ取れれば
291 :
デフォルトの名無しさん (ブーイモ)
2017/03/21(火) 16:52:15.37 ID:vbOnldibM
てんてん
292 :
2017/03/21(火) 20:49:02.70 ID:KGQ11aI90
>>284
> なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す

差分での管理なんて一言も言ってないけど、
ソースコードであればテキストファイルで管理するのが
一番実用的だ。これは本当。

ソースコードがテキストファイルでないものがあるが
(例えばExcelなどの埋め込みVBScript)
見事に管理しづらい。
293 :
2017/03/21(火) 20:52:20.32 ID:KGQ11aI90
>>289
何を言ってるのか全くわからない。

コミットの日付とファイルの日付(タイムスタンプ)は本質的に違うものであって
gitが記録しているのはコミットの日付であって
タイムスタンプじゃないといったのが理解できなかったの?

コミットの日付を記録するんだから、ファイルに変更がなくコミット自体が発生しなければ
当然コミットの日付は記録されんよ。当たり前だよ。
294 :
2017/03/21(火) 20:56:22.17 ID:KGQ11aI90
>>288
> どうやってタイムスタンプでバージョン管理するんだ?

ここで>>284に言ってほしい言葉は、

「タイムスタンプが新しい方を最新バージョンとみなすべきだ。
たとえ古いファイルを間違って修正した結果、新しい日付になった場合でも
AさんとBさんがそれぞれ違うシートを修正したとしてもだ!」

って(間抜けな)言葉だねw
295 :
2017/03/21(火) 21:01:05.29 ID:fjLA+enk0
当然、そうならないようにロック機能をつけるんだよw
296 :
2017/03/21(火) 21:13:08.26 ID:KGQ11aI90
ロック機能をつけた所で、違うブランチで作業したら
ロックかからないんだから、同じ問題が発生するだろw
297 :
2017/03/21(火) 21:26:41.34 ID:fjLA+enk0
当然、リポジトリは1つだけに限定してブランチも認めないんだよw
298 :
2017/03/21(火) 21:30:32.46 ID:KGQ11aI90
>>297
それじゃファイルの管理しか出来ないじゃんw
どうやってアプリのバージョンの管理をするんだよw

新しいバージョンへ追加する機能をマージしていくのが
バージョン管理というものなのに
299 :
デフォルトの名無しさん (ワッチョイ)
2017/03/21(火) 21:38:19.51 ID:YgRGY1SP0
せっかくのボケに対してマジレスしてどうする。
「それはSVNやんかー」と正しく拾ってあげんか。
300 :
2017/03/21(火) 21:39:24.77 ID:KGQ11aI90
マジレスすると、馬鹿がムキーってなるだろ?w
それが狙いだよ。
301 :
2017/03/21(火) 21:46:06.80 ID:kM/ZbQe40
VSS
をお勧めするw
302 :
2017/03/21(火) 22:09:22.81 ID:wENhDYbfM
>>294
なんか勝手にレベルの低い敵を想定して、それをバカにすることで勝ったつもりってのが新しいなw
情けないにも程があるw
303 :
2017/03/21(火) 22:14:43.17 ID:KGQ11aI90
>>302
そうじゃないよ。もっと面白いことを言ってみせろってことだよw
>>294ぐらいの内容は想定済みだからさ
304 :
2017/03/21(火) 22:28:04.46 ID:72kEtT2QM
>>296
そんな間抜けな機能を実装してどうする w
305 :
デフォルトの名無しさん (ワッチョイ)
2017/03/21(火) 22:35:23.92 ID:3G08meY40
v2.12.1
306 :
デフォルトの名無しさん (ワッチョイ)
2017/03/21(火) 22:53:46.86 ID:3WUWYr7R0
>>304
SVNディスってんの?
307 :
デフォルトの名無しさん (ブーイモ)
2017/03/21(火) 23:35:33.90 ID:vbOnldibM
svnは駆逐された
308 :
2017/03/21(火) 23:55:56.28 ID:eniBTwk40
svnはバックアップツール的な役割で当分生き続けると思う
ソースコード管理としてのsvnはもう見たくない
あとVSSとかいうゴミが未だに生き残ってるのはうちの会社だけであってくれ
309 :
2017/03/22(水) 00:14:08.46 ID:MyrW3Mfd0
>>307
されてないよ
310 :
2017/03/22(水) 00:55:23.96 ID:9PE4AFjh0
GNU - Free Software Directory
http://directory.fsf.org/wiki/GNU

この中でGitを採用してるプロジェクト少なそう
311 :
2017/03/22(水) 00:57:04.80 ID:9PE4AFjh0
GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)
https://gcc.gnu.org/


gccですらSVNだし
312 :
2017/03/22(水) 01:23:51.07 ID:twIlTm4o0
Gnu Emacs は古参を説得してgitに移行したんだよな
313 :
2017/03/22(水) 11:06:02.00 ID:6SOT+CpTM
ローカルコミットあればsvnでもいいんだけどな。
314 :
2017/03/23(木) 01:26:02.84 ID:K0r5mLIw0
gitと同じ機能があればsvnでもいいんだけどなA: [0.091163 sec.]B: [1.205233 sec.]
315 :
2017/03/23(木) 20:35:05.23 ID:YiRNRc4u0
いやそれなら git でいいだろってなるでしょ。
ってなんか話がわかんなくなってきた。。
316 :
デフォルトの名無しさん (ワッチョイ)
2017/03/23(木) 20:40:47.51 ID:xoR/oCcH0
リーナスの最大の功績はlinuxではないrebaseなのだ
おかげでバカがrebaseに夢中になっている間にスムーズに仕事が終えられる
317 :
2017/03/23(木) 23:04:58.72 ID:K0r5mLIw0
そのリーナスがrebase使いまくってるんだが?
318 :
2017/03/23(木) 23:52:59.08 ID:pns5gc7N0
じゃあリーナスはバカだな
319 :
2017/03/24(金) 00:01:42.64 ID:eFzcKtyj0
だって「git」じゃん……
320 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 00:05:33.87 ID:pHNq00OZ0
道具は使うためにあるんだよ
321 :
2017/03/24(金) 00:16:43.48 ID:eJM70nNY0
道具に使われてる感があるな
322 :
2017/03/24(金) 00:23:01.51 ID:zQzOEJABd
gitは使うことに意義がある
323 :
2017/03/24(金) 07:58:41.73 ID:hRC2OOpsM
ここは布教に意義を見いだしてる奴の方が多くね?
324 :
デフォルトの名無しさん (オッペケ)
2017/03/24(金) 12:23:45.71 ID:+6lNlTOdr
gitに限らずコイツらの布教活動が成功したためしなどただの一度もないけどなw
325 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 12:52:55.54 ID:lapEt7PI0
>>323
自分がいいと思ってる、使っているものが正しいという阿呆がなんにでもある。
326 :
2017/03/24(金) 14:23:13.53 ID:pHNq00OZ0
世界を自分(たち)にとって都合の良い方向へ変えようとする活動が布教
変えてゆくためには相手を納得させるか騙すか強要するか
都合の良い部分は伝えるが都合の悪い部分は隠すか屁理屈か嘘で押し通す

布教行為を許してはならない
327 :
2017/03/24(金) 14:27:43.43 ID:pHNq00OZ0
VCSは頭の良い奴にしか使いこなせない
複数種類のVCSを使いこなせるのならかなり頭が良い
328 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 15:38:22.82 ID:lapEt7PI0
>>327
あっそ
329 :
2017/03/24(金) 17:39:10.63 ID:bDNInspW0
Git推しのやつの微妙なウザさってのはあるよなあ
330 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 19:00:52.18 ID:tPVQTU6p0
>>326
という布教
331 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 19:01:20.67 ID:tPVQTU6p0
>>329
gitスレで言うことかね
332 :
2017/03/24(金) 19:20:07.13 ID:aTcy1Xxd0
言ってもいいんじゃね。
おれもgit は好きだけどgit厨は嫌いだし。
333 :
2017/03/24(金) 19:54:00.71 ID:TtVdytu+d
>>331
言うことだよ!
334 :
2017/03/24(金) 19:56:35.65 ID:uEBgSsc/0
>>332
わかる
特定のflowを絶対正義だと信じて「git pull --rebaseしないのは馬鹿」とか言い切ってくる奴とかなー
335 :
2017/03/24(金) 20:11:39.04 ID:cySUBa280
あるある大事典:
git の話ばかりしているから svn スレかと思ったら git スレだった…
336 :
2017/03/24(金) 20:14:03.33 ID:TtVdytu+d
>>335
意味が分からない
337 :
デフォルトの名無しさん (ワッチョイ)
2017/03/24(金) 21:33:44.74 ID:hATCGDnU0
>>335
思わねーよ
338 :
2017/03/25(土) 00:34:43.50 ID:OqJqFalA0
gitの話ばかりしてるから、(gitに対して嫉妬してる)svn(ユーザ)のスレかと思ったら、git(信者がのさばってる)スレだった…
339 :
2017/03/25(土) 10:29:50.70 ID:GiAuLLWQ0
SourceTreeって重くね?
リポジトリを幾つかブックマークに追加しただけなのに
起動がとんでもなく遅くなった
340 :
デフォルトの名無しさん (ワッチョイ)
2017/03/26(日) 00:38:00.55 ID:J8Vm0Xfq0
v2.12.2
341 :
2017/03/26(日) 02:34:38.78 ID:0Soyrw+Z0
短期間リリースに方針変更?
342 :
2017/03/26(日) 07:13:07.41 ID:4U1MmeM70
branchだけしてcheckoutし忘れ
誤ってmasterブランチにコミットする大事故
343 :
2017/03/26(日) 08:23:06.27 ID:ns//jG8c0
王様のbranch
344 :
2017/03/26(日) 10:00:08.97 ID:+VpcfeLe0
>>342
つgit checkout -b new_branch
345 :
2017/03/26(日) 12:53:22.44 ID:0NHqcIOe0
git stash popは危険なコマンドだと思いませんか?
間違えたブランチで実行してしまったら元に戻せませんね。
346 :
2017/03/26(日) 13:43:28.99 ID:7dOJEWlC0
正しいブランチでやり直せばいいだけ
347 :
2017/03/26(日) 14:18:20.64 ID:+CTQx9f50
>>345
元に戻すためのgitでしょ
348 :
2017/03/26(日) 14:31:55.91 ID:+VpcfeLe0
マージ失敗したらdropされずに残るので、やり直せる
マージ成功ならもう一回stash saveも出来る

万が一?pop後にファイルをresetしてもコンソールを閉じていなければdropしたコミットハッシュが残っているはず
億が一それも消しちゃってもfsckで到達不能なコミットを探せば復元可能
間違って消す方がむずい
349 :
2017/03/26(日) 15:41:48.18 ID:+CTQx9f50
大抵の手違いは元に戻せるのがgitのいいところなんだけど
ファイルスタンプを戻すのだけはなぜかできないんだよな・・・
350 :
2017/03/26(日) 15:49:48.61 ID:7dOJEWlC0
ファイルスタンプは手違いで発生するものじゃないからねw
手違いじゃないのだから戻さらないというのが
正しい動作。
351 :
2017/03/26(日) 16:34:52.44 ID:ns//jG8c0
またお前か
352 :
デフォルトの名無しさん (ワッチョイ)
2017/03/26(日) 19:08:55.12 ID:K0FPpjuZ0
東京電力の新会長に日立製作所の人間が就任
353 :
2017/03/26(日) 20:18:09.67 ID:HpKD8Qm70
>>352
git終了だな
354 :
2017/03/26(日) 20:59:01.54 ID:oEHJolMv0
いつまでタイムスタンプの話続けるの?
欲しいやつはgit logから引っ張ってくればいいだろ
355 :
2017/03/26(日) 21:28:59.97 ID:7dOJEWlC0
リーナスにタイムスタンプ入れるとかアホって言われたのが
よっぽど悔しいんだろw
356 :
2017/03/27(月) 00:02:27.22 ID:Rc7q5+sM0
またお前か
357 :
2017/03/27(月) 08:45:42.95 ID:DZ7KBqWQ0
インターネットみてると「マスターをチェックアウトして」とか
「マスターへチェックアウトして」とかいろいろな表現を見るけれど。
どれもマスターのブランチへ移動していることを示しているのがおかしくないですか?
今のブランチをチェックアウトしてマスターにチェックインするってことなんだから
前者はマスターから抜け出すことになるし、後者は意味不明になりますと思いませんか?
358 :
2017/03/27(月) 13:08:51.32 ID:wTfMHfwZ0
君の日本語が意味不明
359 :
2017/03/27(月) 13:18:36.33 ID:En3IMuBbp
自分がブランチに出たり入ったりするというのは斬新な見方だな。ホテルかよ。
リポジトリから指定のリビジョンのソースを(ブランチ・タグ・ハッシュ等で指定して)チェックアウトするんだよ。
後者は日本語に不自由なやつなだけだと思うが。
360 :
デフォルトの名無しさん (スッップ)
2017/03/27(月) 15:24:31.02 ID:FTQE7C/md
>>359
後者は「マスターをチェクアウト」と「マスターブランチへ移動」が混ざったんじゃ無いかな?
361 :
2017/03/27(月) 15:44:40.12 ID:BGS+rNUAH
>>357
> 「マスターへチェックアウトして」とかいろいろな表現を見るけれど。
気のせいでは?

https://www.google.co.jp/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%22%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%B8%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A2%E3%82%A6%E3%83%88%22&*
"マスターへチェックアウト"との一致はありません。
362 :
2017/03/27(月) 15:48:03.74 ID:BGS+rNUAH
ごめん、結構いたわ。

"masterにチェックアウト"
約 724 件 (0.45 秒)
363 :
2017/03/27(月) 16:32:28.67 ID:DZ7KBqWQ0
コンフィグのここで疑問なんだけど
[branch "master"]
remote = origin
merge = refs/heads/master
ここで、なぜmerge = origin/masterじゃなんですか?
branchマスターが追跡しているのはorigin/masterで
origin/masterが追跡しているのがrefs/heads/masterなので、
一段飛び越えていて変なんですけど。
364 :
2017/03/27(月) 16:37:48.22 ID:4R4DHhDf0
ブランチを切る ってどっちの意味?
作成する? 削除する?
365 :
2017/03/27(月) 16:38:51.24 ID:DZ7KBqWQ0
もしかしてrefs/heads/masterはローカルを指していて
デフォルトでmasterでpullすると別のブランチのところにmergeされるってこと?
それがなにの役に立つというの?
366 :
2017/03/27(月) 16:39:30.52 ID:LarKYmAi0
小切手を切ると同じ意味
367 :
2017/03/27(月) 16:43:59.37 ID:BGS+rNUAH
>>363
それは、ローカルのファイルシステムのパスです。
https://git-scm.com/book/ja/v1/Git%E3%81%AE%E5%86%85%E5%81%B4-Git%E3%81%AE%E5%8F%82%E7%85%A7
368 :
2017/03/27(月) 17:41:44.24 ID:DZ7KBqWQ0
refs/heads/masterはリモートを指してるらしい、
そしてpullで初めにfetchしたときにrefs/heads/masterがfetchしたなかにあると
refspecで調べてorigin/masterに変換して今のブランチにmergeするらしい
369 :
デフォルトの名無しさん (スッップ)
2017/03/27(月) 18:23:11.66 ID:FTQE7C/md
>>368
refs/heads/masterが、masterという名前のブランチの正式表記で、originのリモートリポジトリの別名表記ってだけじゃないの?

tagにも同じ名前を付けられるからコンフィグは正式名称の方が都合がいいし、
リモートリポジトリは参照するサーバーやリポジトリパスが変わることもあるし、同時に同じリモート名は付けられないから別名表記の方が都合が良い
ってことだと思うけど。
370 :
2017/03/27(月) 22:00:13.07 ID:Kxi6Yxme0
ホテルから出ることをチェックアウトと言う

リポジトリという名のホテルに
masterブランチさんやdevelopブランチさんたちが宿泊してる
そこからチェックアウトして作業現場まで来てくださいって意味

git checkout master
371 :
2017/03/28(火) 15:27:51.25 ID:p6rrPrRVM
SVCとかSubversionとかVSSだとリポジトリからファイルがチェックアウトされて
編集されたあとまたチェックインして元に戻る、というアナロジーが非常にわかりやすい
けど、Gitだとなんかいろんな路線に分岐してはまた合流、って感じが強くてなんか
あわない感じはあるよな。
流れのなかのある「状態」に戻したり勧めたりする感じというか。
もっとわかりやすい用語にできたのかもしれない。
120KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: