[過去ﾛｸﾞ] Git 15©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
59: (ﾜｯﾁｮｲ) 2017/03/02(木)23:31:43.91 ID:em5mjT5q0(1) AAS
普通じゃ？
153: (ｽｯﾌﾟ) 2017/03/16(木)11:59:54.91 ID:XUhAFY4kd(1) AAS
タイムスタンプの参照方法も知らんのか
348: (ﾜｯﾁｮｲ) 2017/03/26(日)14:31:55.91 ID:+VpcfeLe0(2/2) AAS
マージ失敗したらdropされずに残るので、やり直せる
マージ成功ならもう一回stash saveも出来る
万が一？pop後にファイルをresetしてもコンソールを閉じていなければdropしたコミットハッシュが残っているはず
億が一それも消しちゃってもfsckで到達不能なコミットを探せば復元可能
間違って消す方がむずい
539(1): (ﾜｯﾁｮｲ) 2017/04/08(土)03:33:08.91 ID:sJFTclBC0(1) AAS
ビルドに依存関係のあるファイル（中間成果物も含む）をすべて最新のソースに反映済みかビルドツールは確認しなくちゃまずいと思うんだけど、
それって結局ビルド中に出来るファイルのタイムスタンプとかハッシュをを全部確認するということと変わらないと思うんだよね。
ハッシュって結局全データ読まないとわかんないわけで、これから全データ読ませてコンパイルするかどうか判断するツールが全データ読んでたらなんとかならんのかと思うし、
普通ハッシュが変わってたらタイムスタンプも変わるので、タイムスタンプでコンパイルするかしないか判断をするのは理にかなってると思うけどもなぁ
タイムスタンプが信用できないビルド環境（分散環境とかであるんだろうけど）とか、touchしただけのファイルがコンパイルをめちゃくちゃ長くするとか、そういうケースだったら
ハッシュを使ったほうが良いのだと思うけれど。
だから、純粋にタイムスタンプを復元したほうがビルド前提のソースコード管理システムにとっていいケースってのはどういうときなのか知りたい。
ビルドが要らないものにはタイムスタンプを保持してくれたほうが同名別バージョンの判別がしやすい、ということなんだろうけれど。
けど、それも裏返せばタイムスタンプは簡単に確認できるから、人間がハッシュなんかでいちいち確認したくない、ビルド時の効率性を下げてでも人間に合わせろって意見なんじゃないかなぁ
タイムスタンプ保存する機能より、必要なファイルのハッシュ値をコミット時かなんかに取るようにして人間が変更されているのをタイムスタンプ以外の方法で確認しやすいようにした方が良いと思うけど
575(1): (ﾜｯﾁｮｲ) 2017/04/08(土)23:26:45.91 ID:ZmPKT6lF0(7/7) AAS
>>556
動画ﾘﾝｸ[YouTube]
外部ﾘﾝｸ[html]:google-engtools.blogspot.jp
772: (ｽｯｯﾌﾟ) 2017/05/03(水)11:28:03.91 ID:xkQWxFrsd(1) AAS
sidやuidのことなら、それはマルチユーザー環境やファイルサーバーなんかでアクセス制御に関連して備わっているもなので、趣旨の異なるgitで保持してもゴミ情報
単なる数字列を見て何ができるんだか
779(1): (ﾜｯﾁｮｲ) 2017/05/04(木)15:27:35.91 ID:TekYC6Iv0(1/2) AAS
Unixじゃパーミッションやグループやオーナはデプロイ時に設定するのが一般的だな
特にオーナとグループはデプロイするローカルな環境に依存していてパーミッションの効果に影響するから
ソース管理でファイルが保持している情報をそのままデプロイするとかありえん
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.029s