Git 15©2ch.net

2017/02/05(日) 05:22:15.65

ソースコード管理を行う分散型バージョン管理システム、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

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 06:30:39.79

<　｀∀´>ﾆﾀﾞｰ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 14:05:34.08

Git v2.12.0-rc0
https://github.com/git/git/blob/master/Documentation/RelNotes/2.12.0.txt

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 15:38:55.62

rebaseを使いこなして初めて
gitを使えるようになったと言える

**デフォルトの名無しさん** (ｴﾑｿﾞﾈ) · 2017/02/05(日) 15:39:17.20

>1 乙py

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/07(火) 10:05:09.07

gitlab復旧作業8時間実況すげ
https://www.youtube.com/watch?v=nc0hPGerSd4

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/07(火) 11:25:57.76

rebaseの使い途がそんなにないんじゃね
コミットが何百もあったときにrebaseで綺麗にできると思えん
squashはresetでできる
使えるのは過去のコメントを編集するときくらいか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 03:26:19.24

>>7
コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね？

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

そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 03:53:20.12

エスパーすると
>>7は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 11:32:37.78

何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか？

いつもいろんなgit操作を試行錯誤してしまって、本題がコミットすることからブランチ整理することにずれていってしまうので。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 11:38:22.96

>>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 15:36:17.78

>>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 17:10:20.00

>>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 19:40:31.54

最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:22:54.22

>>11
> cherry-pickは操作後の動作が保証できない

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

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

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

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

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

使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:48:05.72

>>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

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

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

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

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

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

rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 23:13:58.04

最初から意味がある単位で小さくまとめるのが理想だけど、
後からブランチの履歴を整理する手段も色々ある。

gitでアレを元に戻す108の方法
http://labs.timedia.co.jp/2011/08/git-undo-999.html
Gitでやらかした時に使える19個の奥義
http://qiita.com/muran001/items/dea2bbbaea1260098051

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/09(木) 08:27:12.93

git(hub)-flow

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/02/13(月) 10:17:21.25

git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 10:39:40.22

>>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 15:13:09.61

改行コード変わるだけで別ファイルになるけどな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/17(金) 09:56:23.44

毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。

**デフォルトの名無しさん** (ﾜｲﾓﾏｰ) · 2017/02/18(土) 01:13:13.92

コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:21:39.27

>>22
プッシュじゃなくて？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:58:54.36

>>24
ごめん、プッシュね。

マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。

2017/02/18(土) 02:04:19.48

細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 03:06:20.95

>>26
突っ走った後にgit add -p 使って複数のコミットを作る

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 11:33:38.07

>>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 13:22:21.19

>>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/19(日) 22:56:47.13

cron 書けとしか言いようがない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 00:19:55.01

エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 15:40:38.57

>>31
数分おきにエディタに :wq! を送るスクリプトを作ろう

**デフォルトの名無しさん** (JP) · 2017/02/22(水) 15:45:05.02

意味のある区切りじゃない自動保存などゴミ

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 16:51:00.38

そもそもコミットは成果毎に行うのであって細かくすればいいというものではない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 19:13:30.90

プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？

2017/02/22(水) 19:54:40.37

コミットと保存の話が混ざって混沌としてきてる

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 20:45:47.20

個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 01:11:00.83

ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばＯＫ
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおｋ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 10:00:04.78

>>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね

2017/02/23(木) 16:27:13.03

>>39
ない

svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある

2017/02/23(木) 20:55:38.64

チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 14:06:29.60

SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/

それに対するLinusの見解
http://marc.info/?l=git&;m=148787047422954

**デフォルトの名無しさん** (JP) · 2017/02/24(金) 14:11:42.95

hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし

2017/02/24(金) 15:11:29.62

想定はしてないでしょ、無理矢理衝突させたらリポジトリ壊れたって書いてるし
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 16:02:16.98

>>43
5桁でちぎって管理ってなんのこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 10:54:33.01

v2.12.0

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 11:32:01.15

>>46
何か面白い機能追加された？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 04:28:34.00

Linusの公式コメント
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 13:29:26.47

SHA1衝突なんか怖かねーぜバーカ！
ってこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 00:08:39.88

ファイル数が20万～30万個あるプロジェクトをgitで管理できる？
git statusすると20万～30万の全部のファイルの更新日チェックするの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 01:39:05.95

gitで管理できなかったら、他の何を使っても出来ないと思うｗ
管理せずにファイル置いとくだけならできるだろうけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 05:02:00.38

>>51
きも

**デフォルトの名無しさん** (ｵｯﾍﾟｹ) · 2017/03/01(水) 12:18:24.07

俺も思った

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/03/01(水) 12:52:10.72

>>50
それくらいなら全然大丈夫だよー

**デフォルトの名無しさん** (JP) · 2017/03/02(木) 19:24:50.56

>>50
人間よりは速い

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/02(木) 23:03:10.15

gitを使うのが目的になってる奴がいるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:06:07.56

gitを使うのが目的じゃないけど結果的にgitを使ってるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:30:35.54

gitを使ってるカッコいい俺

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:31:43.91

普通じゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:36:40.95

gitの使い方を覚えられないおっさんも世の中には居るんだ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:42:40.19

使える人が使わないなら、それはいいんだよ。

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

あと使って見てないやつもダメだな

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/03(金) 11:58:15.68

Gitが使えない外注イラネ

**デフォルトの名無しさん** (JP) · 2017/03/03(金) 12:30:04.87

篩に使うのはありか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/03(金) 21:00:59.00

なんでもいいから自分のソースくらい自分でコミットしろ。

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/03(金) 21:35:27.51

本当になんでもいいの？

2017/03/03(金) 23:39:23.71

masterにコミットしていいの？

2017/03/04(土) 00:19:50.00

結果にコミットしていいの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 00:59:09.29

面倒臭いのでだいたい
git add .
git commit --amend -m "hoge"

で済ましてる
一通り終わったらgit commit --amendでコミットメッセージちゃんと書く
squashしなくてよい方法だよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 03:38:59.15

Git - 高度なマージ手法
https://git-scm.com/book/ja/v2/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-%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%9E%E3%83%BC%E3%82%B8%E6%89%8B%E6%B3%95

これいいね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 11:03:44.63

git merge --abort
git rebase --abort

これいいよな。

svnとかだとやらかしてしまって中途半端な状態になって
これどうすりゃいいんだよってなってしまうけど、
gitだとたいてい--abortすればリセットできる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 14:23:44.15

AにコミットしてA'
A'にコミットしてA''
になってるとき
A'をBに名前変えて
A->A''と
A->Bに分けることはできますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 15:02:21.59

git checkout 好きなコミットID

ブランチ名なんて最新のコミットに名前つけてるだけであって
コミットIDで全て参照できる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:15:35.10

A->A''の方にはB(A')が無かったことにしたいのですが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:34:49.80

説明がわかりにくすぎだろw
pushしてればrevertで
してなければrebase -iで

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 21:55:14.48

cherrypickでA''からAにパッチ当てりゃいいだけじゃね？

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/04(土) 22:05:36.70

>>71
git branch B A'
をする
git rebase A -i
でA'の行を消す

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:20:15.96

ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み

こう言う場合って作業完了してからまとめてコミットすべき？
それともキリのいいところでコミットすべき？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:34:33.58

適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 15:02:30.70

rebaseは甘え。使ってはいけない。

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/07(火) 18:29:12.37

せっかくローカルにあるんだし、どんどんコミットしたら？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 19:25:45.74

rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:49:12.26

rerebaseだと!?

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:55:44.46

rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
rebaseしたってコミットそのものが世界からすぐに消えるわけじゃないんだし

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/07(火) 22:48:44.65

git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 00:28:53.24

> rebase怖いならブランチ切るなりタグつけるなりして

そのブランチやタグを作るのが面倒なバージョン管理ツールがありまして、
そのせいでブランチやタグを切るのが嫌なんですよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 01:12:08.47

知らんがな

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/08(水) 08:51:03.76

ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/08(水) 18:56:28.23

(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ブランチを作りなおして新たに作るのが面倒くさいので

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 19:57:59.67

git reset --hard コミットID2

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 06:48:45.74

>>88
コミットIDでcheckoutすりゃいいだけじゃね

(1)git checkout コミットID1
(2)git checkout コミットID2

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 08:26:50.81

>>88
git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/09(木) 08:37:37.52

>>82
リ・リ・リベース
アホデミー賞を総なめ

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/09(木) 10:28:24.13

resetは困ります。。。。
checkoutでどうにかやる方法はないということでしょうか？

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 10:29:17.80

ブランチは１個しか作りたくないんです

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 12:31:57.97

>>93
じゃあ>>90で良いんじゃないの？
コミットは出来ないけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:13:36.94

>>88
git checkout hoge
git merge <commit>

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:42:24.50

>>93
なんでreset困るの？ブランチ消してる時点で同じことだと思うけど
resetしたってコミットが消えるわけじゃないよ

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 22:57:50.27

git checkout -b hoge
git reset --hard コミットid1
git reset --hard HEAD@{1}
masterブランチには何の影響もないですね
最新のコミットに戻るときにreflogで位置を確認するのが面倒くさそうです
これも覚えておきます

>>96
mergeだと古いコミットに戻ろうとした時にAlready up-to-date.って表示されてしまいました

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 23:15:12.39

hogeにはすでにコミット1やコミット2が含まれてる場合もあって
その場合はそれ以降のコミットを捨てた状態にしたいってことなの！？
用途が謎

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 03:45:25.28

>>98
ブランチは1個しか作りたくない理由がわからないから、それだったらID1とID2に別のブランチを付けたら良いんじゃない？って思っちゃうんだけど
何で作りたくないんですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 04:41:26.50

>>90のやり方がスルーされるからやりたいことと違うんだろうなあ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 14:48:19.74

タグの代わりなんじゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:15:08.71

みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
する機能使ってる？

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

あとdiffの結果画面の見方が今ひとつ苦手w

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:48:11.92

>>103
使わんなー

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:51:35.65

>>103
細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:13:50.48

git add -p のこと？
ならすげー使うけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:28:17.98

git add -pの存在がsvnからの移行を決定づけた

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:51:42.82

俺もよく使うな。

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

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

他の人が理解・レビューしやすい並びのコミットと、
実際の開発順っていうのは必ずしも一致しないからさ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 23:30:38.30

git add -pなら使う。行単位でステージングする機能、だよね？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 06:24:50.89

>>108
SVN 使いだけどこの機能とローカルコミットはマジで欲しい

**デフォルトの名無しさん** (JP) · 2017/03/11(土) 10:36:14.71

>>110
gitに乗り換えても良いんですよ？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/11(土) 11:07:52.10

行単位使ってる人多いんだな
完全ファイル単位だわ
考え方古いのか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 12:21:39.87

>>111
何となくだけど git は性に合わない

**デフォルトの名無しさん** (ｽｯﾌﾟ) · 2017/03/11(土) 12:39:37.19

>>113
おじいちゃんこんにちは

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 13:07:42.60

stash, cherry-pick, rebaseのないコーディングなんてもう考えられない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 14:17:42.96

試行錯誤のあととかノイズでしかないからな。
そんなものを大事に抱えていても、コードリーディングの
じゃまになるだけで意味が全くない。
快適な開発をするときに役立つコマンドがgitには多く搭載されている

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 16:27:54.83

行単位とかやりすぎだろ。。
それなら作業者を統一するなり、ファイル分割するなりした方がいいんじゃねーの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 17:15:54.01

作業者が独りだから、同じファイルを複数行編集するんだろｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 18:39:00.61

まとめてコミットするつもりで編集中だったワークツリーから
部分的に何行かコミットしてpushする必要ができたとか
けっこうある

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 16:00:30.11

ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？

**デフォルトの名無しさん** (JP) · 2017/03/14(火) 16:01:15.03

>>120
git

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 16:49:48.82

ワロタ

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 19:54:39.02

はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 20:00:39.69

もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 21:49:01.07

>>120
svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 21:57:48.94

gitはOSSなんだからHACKするなり自分で手を加えればいいのでは？

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/14(火) 22:06:05.44

>>123
コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 22:42:41.89

適当なツール使えばいいじゃん

https://github.com/search?q=timestamp+git

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 01:16:30.21

タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの？
タイムスタンプはOSごとのローカルな仕様っぽいのでGit本体には入れなくないってこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 01:23:09.75

全く欲しいと思ったことが無いけど何に使うの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 02:50:18.09

>>130
あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 04:09:45.52

そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 07:04:46.81

Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 07:44:08.96

>>131
今時そんな事してる現場なんてあるわけないじゃん？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 08:18:02.75

>>129
記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。

ファイルの日付どころか行単位で
修正日時が記録されているので必要ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 08:32:23.84

>>133
> Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります

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

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

あんたはどうしてもほしいの？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/15(水) 10:18:23.23

結論:Gitは素晴らしい仕組

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/15(水) 10:22:20.47

流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
所詮は℃素人の烏合の衆かw

**デフォルトの名無しさん** (ｽﾌｯ) · 2017/03/15(水) 10:35:49.13

gitを使うことが目的になってるからな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 12:42:56.93

>>135
ごもっとも
だけどFAQでこの文章みた記憶がない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 12:45:29.83

>>138
commit時の日時だっけ？
checkout時の日時だと思ってた

2017/03/15(水) 12:52:42.68

チェックアウトの度にタイムスタンプが書き換わっていたらさらに大混乱のような

手元にないから誰か試して

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 13:05:12.43

>チェックアウトの度にタイムスタンプが書き換わっていたら

その時点で存在しないファイルとかチェックアウトの結果変更されるファイルのタイムスタンプの話なんですが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 13:06:14.60

>>138
馬鹿がばれるからやめとけ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 16:57:44.56

>>133
で、何に使うの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 22:27:20.10

チェックアウトっていうのは手元のファイルを書き換えているわけで
ファイルの更新日付は変わるほうが動作として正しいんですよね

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/16(木) 08:39:50.82

ユーザー視点からはタイムスタンプごと戻るほうが正しいだろ。

システムの都合を言われても知らんわ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 09:06:14.81

ユーザー視点ってなんだ？
バージョン管理ツールは開発者視点のものなんだが。

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

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

バージョン管理ツールはバックアップツールじゃないんだぞ
開発者じゃないやつが使うものじゃない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 09:28:08.60

>>147
システムの都合じゃなくて、ユーザー（開発者）視点から
ビルドしやすいようにあえて日付を更新してる

2017/03/16(木) 11:09:03.98

それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含めそっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

上の流れを要約するとそういうこと

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 11:18:06.56

>>150
誰も何に使うか挙げれてないのに？

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2017/03/16(木) 11:50:16.25

gitの操作によって更新されたファイルのタイムスタンプをユーザが参照出来ないとか、ユーザーにとって拷問じゃね？

**デフォルトの名無しさん** (ｽｯﾌﾟ) · 2017/03/16(木) 11:59:54.91

タイムスタンプの参照方法も知らんのか

**デフォルトの名無しさん** (ｵｯﾍﾟｹ) · 2017/03/16(木) 12:19:13.00

大体お前ら殆どペチパーだろｗ
そもそもビルドプロセスなんかねえじゃんｗ

2017/03/16(木) 12:54:44.92

ペチパーてなに？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 13:30:19.82

プロパーのことかな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 14:26:14.45

https://www.indeed.com/jobtrends/Java,JavaScript,Perl,PHP,Python,Ruby,Scala.html
ペチパー=PHPerだけど、PerlとPHPの仕事は減る一方で３年以内にScalaに追い越される。
JavaとScalaはコンパイルのために、JavaScriptはトランスパイルのためにビルドが必要だ。

**デフォルトの名無しさん** (JP) · 2017/03/16(木) 14:37:48.23

でも、githubなんかのリポジトリブラウザでlast commitが一覧できるのは便利。
ファイルの更新具合が一目瞭然。
git cloneのデフォルト動作がlast commitを復元するのでいいとさえ思う。

**デフォルトの名無しさん** (JP) · 2017/03/16(木) 14:42:25.18

タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
ビルドしたときのハッシュを保存しておいて、違ってたらビルド（コンパイル）対象にするとか。

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/16(木) 14:57:26.15

>>159
遅くなるだろ。何のためにタイムスタンプ単純比較してると思ってるんだ。

**デフォルトの名無しさん** (JP) · 2017/03/16(木) 15:21:13.16

>>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

2017/03/16(木) 15:57:58.78

Git真理教信者はGitはとにかく正しいのだという盲信から発言するから、自分とは違ったニーズを持つ他者がいるという想像もできないし、そもそもエビデンスを出しての議論ができないんだよなあ
口汚く罵るだけで

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 18:08:47.10

>>150
初心者はとまどうのかもしれないが
慣れたら問題ないことに気付く

どうせ秀丸でも使ってるんだろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 18:35:50.30

hookで実現する方法はあるし、必要ならそれを使えばいいだけだと思うんだがどうしてその機能がデフォルトで用意されてないだけでそこまで喚くのかわからない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 18:40:51.93

>>164
わからなければ参加しなくてもいいんですよw

2017/03/16(木) 18:45:10.48

公式のgit guiもネイティブのwindowsソフトのくせに日本語含んだディレクトリ名とか未だにダメダメだな
この時代に他言語対応がここまでダメなメジャーなソフトも珍しいんじゃね？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 19:10:46.07

git for windows ならいける

2017/03/16(木) 19:14:58.70

>>166
まったく珍しくないけど。
ユーザー名に日本語含めないようにするというバッドノウハウが広まってるのがいい証拠

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 19:25:54.89

あれがだめだ
これもだめだ
文句ばっかり一人前

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 19:42:09.30

>>169
少しは文句ばっかり言われる自分を省みてみたらw

2017/03/16(木) 19:53:27.96

>>167
サンクス
そうなんだ。試してみる。

2017/03/16(木) 23:09:13.57

結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ？
煽るにしたってgitに取って代わるようなツールを挙げてくれないと面白くないんだけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 23:28:53.65

お前が面白いとかつまらんとかほんとどうでもいい
言うことないならスレ汚さずに黙ってろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 23:50:24.62

>>150
> それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

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

gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/16(木) 23:59:09.02

>>174
gitしか知らないぺーぺーのひよっ子が面白い事言うなｗ
お前センスねえわｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:01:17.52

そもそも
>gitの思想と違う
なんて発言は誰もしてないのに、さもそんな発言があって、それが共通認識であるかのように語る

病気ですね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:07:16.69

>>175
svnも知ってるが？

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

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

間違いは間違いのまま残り、意味のないコードを他の人にレビューさせるのが
すごく無駄に感じた。それが解消されたのでgitはすごくストレスフリーだよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:11:39.15

>>177
いや知らねえよお前はｗ
それどこのｲﾝﾀｰﾈｯﾂで拾ってきたgit神話だよｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:20:09.47

>>178
なんで俺の書いた内容に反論しないの？ｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:23:50.09

>>179
それはこっちのセリフだよｗぺーぺーのひよっ子クンｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:27:58.36

このように必死になるのがワロエルｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:33:43.21

>>161
例えばGoogle Chromeとか1000万行以上、ファイル数も数万個あるんだよなぁ、そこまで大きなプロジェクトはあまり無いだろうけどさ。
ハッシュをDBか何かにファイルパスのようなuniqueな値と合わせて書き込まなきゃならないだろうし、画像などのリソースを固めるなら大きめのファイルのハッシュも計算しなけらばならないだろう。そのベンチマークはちょっと見通し甘いと思う。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 00:34:13.23

>>181
なんだよもう諦めたのかｗ
俺はもっと笑いたいんだけどなｗ
もっと聞かせてくれよぅ
ひよっ子クンのソフトウェアなんとかｗの思想ｗ

2017/03/17(金) 00:50:55.73

構ってもらえて嬉しそう
よかったね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 01:35:25.41

>>174
なんかよくわからんけど、例えば一年前にコミットしたmakeファイル含むビルド環境一式があって、
それを再現したいとき、オプションでタイムスタンプも含めてぜんぶそのときの環境が再現される
オプションがあればそれはそれで便利じゃないの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 01:45:34.43

>>185
だから何が便利なの？
タイムスタンプを再現して何が嬉しいの？
標準に入れろっていうくらいなんだから大多数が納得するようなメリットを示せるはずだよね？
それがこのスレで一つも出てきてないんだけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 01:50:24.59

>>185
>それを再現したいとき
それってどんな時？ってのが行き着くところだと思うよ
上の方でもちらほら出てるけど、必要なら実装すれば良いし、必要だと思う人が多ければ標準の機能として組み込まれるでしょ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 02:44:39.70

>>185
日付が戻るのはソースファイルだけ。
そのソースファイルを使ってコンパイルすると
オブジェクトファイルができる。
"現在の日付の"オブジェクトファイルができる。

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

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

で、なんか言った？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 03:08:37.61

まぁ git checkout でブランチ変えるたびに make clean なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな

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

git以外の何らかの管理ツールがタイムスタンプで何らかの整合性を保っててその管理ツールのデータファイルもgitリポジトリに一緒に突っ込んでるとかかなあ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 03:38:39.20

>>189
そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 03:47:35.77

普通に考えて日付が違っていてもコンパイルすれば
同じ実行ファイルができるべきである。

でないと、ファイルを保存し直しただけで
違う物ができることになってしまう

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/17(金) 08:32:42.50

>>188
いや >>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/03/17(金) 08:39:41.92

>>191
そもそも具体的に何のためにそんなことしたいのかが分からないな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 09:05:02.21

>>192
じゃあバックアップツール使え馬鹿で終わりだなｗ

2017/03/17(金) 09:21:50.26

意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 09:28:24.44

じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
言い続けるかｗｗｗ

**デフォルトの名無しさん** (JP) · 2017/03/17(金) 11:36:42.96

>>182
まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。

つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ？

**デフォルトの名無しさん** (JP) · 2017/03/17(金) 12:07:10.25

>>189
秀丸ですねわかります

**デフォルトの名無しさん** (JP) · 2017/03/17(金) 12:08:06.93

>>195
それは永遠にないわ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/17(金) 12:09:21.75

>>196
gitでタイムスタンプを管理しないのは失敗だったかも
（でも今更だし悪い仕様でもこのまま乗り切るわ）

と講演で言っていたよね