Git 15©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
ソースコード管理を行う分散型バージョン管理システム、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 rebaseを使いこなして初めて
gitを使えるようになったと言える rebaseの使い途がそんなにないんじゃね
コミットが何百もあったときにrebaseで綺麗にできると思えん
squashはresetでできる
使えるのは過去のコメントを編集するときくらいか >>7
コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね？
そのどでかいブランチから、小さく機能を抜き取って
小さなブランチにしてマージするべきだよ。
そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う エスパーすると
>>7は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね 何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか？
いつもいろんなgit操作を試行錯誤してしまって、本題がコミットすることからブランチ整理することにずれていってしまうので。 >>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている >>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ >>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい 最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの >>11
> cherry-pickは操作後の動作が保証できない
何を言ってるんだ？
cherry-pickはあるコミットを持ってくるというだけの機能で
cherry-pickしたあとの動作なんて最初から何も保証してないんだが
保証できないんじゃなくて、保証してない
だからrebaseして、そのcherry-pickしたコミットが正しく動くようにするんだよ
ちなみに、そもそもなんでcherry-pickして動かなくなるのかといえば
こまめなrebaseをしてないから。例えばコミットに対する修正を別コミットに
していたりするとそうなる。こまめにrebaseして意味のある単位にコミットを
修正していれば他人が読んだときのレビューも楽になるし、再利用もしやすくなる
> mergeなら操作後の動作が保証できる
mergeはブランチ全てをマージするものであってそもそも使うべきところが違う。
ブランチの中の1コミットだけを抜き取りたいときにmergeではできない
（できないからmergeの方が劣ってるとでも？ｗ）
使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない >>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい
簡単に言えば、こまめなコミット、こまめなrebaseだよ
有名なオープンソースソフト（例git）のコミットログを眺めてみればいい
あれが目標とすべきコミット
眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。
後から読むこともあるしレビューのときに読むこともある。だから可読性が必要
じゃあコミットの可読性はどうやればあげられるかというと
意味がある単位で小さくまとまめること
例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって
ここバグってる？すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ
かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる
では意味がある単位で小さくまとめる（＝ワークフロー）にはどうするかとうと
まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。
そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。
プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。
rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか？ >>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ 毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。 コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな >>24
ごめん、プッシュね。
マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。 細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか >>26
突っ走った後にgit add -p 使って複数のコミットを作る >>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う >>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ >>31
数分おきにエディタに :wq! を送るスクリプトを作ろう そもそもコミットは成果毎に行うのであって細かくすればいいというものではない プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？ 個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばＯＫ
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおｋ >>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね >>39
ない
svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/
それに対するLinusの見解
http://marc.info/?l=git&;m=148787047422954 hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし ファイル数が20万〜30万個あるプロジェクトをgitで管理できる？
git statusすると20万〜30万の全部のファイルの更新日チェックするの？ gitで管理できなかったら、他の何を使っても出来ないと思うｗ
管理せずにファイル置いとくだけならできるだろうけど gitを使うのが目的じゃないけど結果的にgitを使ってるな gitの使い方を覚えられないおっさんも世の中には居るんだ 使える人が使わないなら、それはいいんだよ。
能力不足で使えない（＝無能すぎる）
会社のしがらみで使えない（＝かわいそう）
あと使って見てないやつもダメだな なんでもいいから自分のソースくらい自分でコミットしろ。 面倒臭いのでだいたい
git add .
git commit --amend -m "hoge"
で済ましてる
一通り終わったらgit commit --amendでコミットメッセージちゃんと書く
squashしなくてよい方法だよ git merge --abort
git rebase --abort
これいいよな。
svnとかだとやらかしてしまって中途半端な状態になって
これどうすりゃいいんだよってなってしまうけど、
gitだとたいてい--abortすればリセットできる AにコミットしてA'
A'にコミットしてA''
になってるとき
A'をBに名前変えて
A->A''と
A->Bに分けることはできますか？ git checkout 好きなコミットID
ブランチ名なんて最新のコミットに名前つけてるだけであって
コミットIDで全て参照できる A->A''の方にはB(A')が無かったことにしたいのですが 説明がわかりにくすぎだろw
pushしてればrevertで
してなければrebase -iで cherrypickでA''からAにパッチ当てりゃいいだけじゃね？ >>71
git branch B A'
をする
git rebase A -i
でA'の行を消す ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み
こう言う場合って作業完了してからまとめてコミットすべき？
それともキリのいいところでコミットすべき？ 適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね せっかくローカルにあるんだし、どんどんコミットしたら？ rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫 rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
rebaseしたってコミットそのものが世界からすぐに消えるわけじゃないんだし git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください > rebase怖いならブランチ切るなりタグつけるなりして
そのブランチやタグを作るのが面倒なバージョン管理ツールがありまして、
そのせいでブランチやタグを切るのが嫌なんですよ。 ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。 (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ブランチを作りなおして新たに作るのが面倒くさいので >>88
コミットIDでcheckoutすりゃいいだけじゃね
(1)git checkout コミットID1
(2)git checkout コミットID2 >>88
git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと resetは困ります。。。。
checkoutでどうにかやる方法はないということでしょうか？ >>93
じゃあ>>90で良いんじゃないの？
コミットは出来ないけど >>88
git checkout hoge
git merge <commit> >>93
なんでreset困るの？ブランチ消してる時点で同じことだと思うけど
resetしたってコミットが消えるわけじゃないよ git checkout -b hoge
git reset --hard コミットid1
git reset --hard HEAD@{1}
masterブランチには何の影響もないですね
最新のコミットに戻るときにreflogで位置を確認するのが面倒くさそうです
これも覚えておきます
>>96
mergeだと古いコミットに戻ろうとした時にAlready up-to-date.って表示されてしまいました hogeにはすでにコミット1やコミット2が含まれてる場合もあって
その場合はそれ以降のコミットを捨てた状態にしたいってことなの！？
用途が謎 >>98
ブランチは1個しか作りたくない理由がわからないから、それだったらID1とID2に別のブランチを付けたら良いんじゃない？って思っちゃうんだけど
何で作りたくないんですか？ >>90のやり方がスルーされるからやりたいことと違うんだろうなあ みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
する機能使ってる？
俺はファイル単位でしかコミットとかしないんだけどさ、そもそもステージング
してるところから行単位でまた編集するようなもんだから、テスト通るかわからなく
なるわけだし、あんまり積極的に使うもんじゃないよね。
あとdiffの結果画面の見方が今ひとつ苦手w >>103
細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？ git add -p のこと？
ならすげー使うけど git add -pの存在がsvnからの移行を決定づけた 俺もよく使うな。
gitの便利さっていうのは現実的な問題を解決してることにあると思っていて、
理想は最初に計画を立てて間違えることなく作業をすることだけど
現実にはいろんな細かい修正を忘れたり分けるべき修正を一緒にやってしまったりするでしょ？
そういう時に俺は、いま修正している中で、特定の部分だけgit add -pつかって
一つのコミットにして、あとの分は別コミットにして、
テストは後から書いてrebaseしてまとめるとかやるよ。
他の人が理解・レビューしやすい並びのコミットと、
実際の開発順っていうのは必ずしも一致しないからさ git add -pなら使う。行単位でステージングする機能、だよね？ >>108
SVN 使いだけどこの機能とローカルコミットはマジで欲しい 行単位使ってる人多いんだな
完全ファイル単位だわ
考え方古いのか >>111
何となくだけど git は性に合わない stash, cherry-pick, rebaseのないコーディングなんてもう考えられない 試行錯誤のあととかノイズでしかないからな。
そんなものを大事に抱えていても、コードリーディングの
じゃまになるだけで意味が全くない。
快適な開発をするときに役立つコマンドがgitには多く搭載されている 行単位とかやりすぎだろ。。
それなら作業者を統一するなり、ファイル分割するなりした方がいいんじゃねーの？ 作業者が独りだから、同じファイルを複数行編集するんだろｗ まとめてコミットするつもりで編集中だったワークツリーから
部分的に何行かコミットしてpushする必要ができたとか
けっこうある ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？ はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？ もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ >>120
svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう gitはOSSなんだからHACKするなり自分で手を加えればいいのでは？ >>123
コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの？
タイムスタンプはOSごとのローカルな仕様っぽいのでGit本体には入れなくないってこと？ >>130
あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか？ そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります >>131
今時そんな事してる現場なんてあるわけないじゃん？ >>129
記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。
ファイルの日付どころか行単位で
修正日時が記録されているので必要ない >>133
> Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
Aというブランチでファイルを追加します。
Aブランチから派生したBというブランチでそのファイルを修正します。
Bというブランチでコンパイルしてオブジェクトファイルを作ります。
Aというブランチに戻ります。
Bというブランチでコンパイルしたオブジェクトファイルが残っています。
ファイルの日付はリポジトリに入れないのでAの方が更新日付が新しくなります
そのためコンパイルするとBのオブジェクトファイルは使用されません。
という素晴らしい仕組みはgitだけの特典だとでも？
あんたはどうしてもほしいの？ 流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
所詮は℃素人の烏合の衆かw >>135
ごもっとも
だけどFAQでこの文章みた記憶がない >>138
commit時の日時だっけ？
checkout時の日時だと思ってた チェックアウトの度にタイムスタンプが書き換わっていたらさらに大混乱のような
手元にないから誰か試して >チェックアウトの度にタイムスタンプが書き換わっていたら
その時点で存在しないファイルとかチェックアウトの結果変更されるファイルのタイムスタンプの話なんですが チェックアウトっていうのは手元のファイルを書き換えているわけで
ファイルの更新日付は変わるほうが動作として正しいんですよね ユーザー視点からはタイムスタンプごと戻るほうが正しいだろ。
システムの都合を言われても知らんわ。 ユーザー視点ってなんだ？
バージョン管理ツールは開発者視点のものなんだが。
バージョン管理ツールができる以前から
makeはタイムスタンプを参照して更新されたものだけを
ビルド、リンクする。
checkoutしてブランチを切り替えてファイルが変わったら
当然ビルド、リンクしなきゃならないんだから、タイムスタンプは
新しくなくちゃいけないだろ。
バージョン管理ツールはバックアップツールじゃないんだぞ
開発者じゃないやつが使うものじゃない >>147
システムの都合じゃなくて、ユーザー（開発者）視点から
ビルドしやすいようにあえて日付を更新してる それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含めそっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する
上の流れを要約するとそういうこと gitの操作によって更新されたファイルのタイムスタンプをユーザが参照出来ないとか、ユーザーにとって拷問じゃね？ 大体お前ら殆どペチパーだろｗ
そもそもビルドプロセスなんかねえじゃんｗ https://www.indeed.com/jobtrends/Java,JavaScript,Perl,PHP,Python,Ruby,Scala.html
ペチパー=PHPerだけど、PerlとPHPの仕事は減る一方で３年以内にScalaに追い越される。
JavaとScalaはコンパイルのために、JavaScriptはトランスパイルのためにビルドが必要だ。 でも、githubなんかのリポジトリブラウザでlast commitが一覧できるのは便利。
ファイルの更新具合が一目瞭然。
git cloneのデフォルト動作がlast commitを復元するのでいいとさえ思う。 タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
ビルドしたときのハッシュを保存しておいて、違ってたらビルド（コンパイル）対象にするとか。 >>159
遅くなるだろ。何のためにタイムスタンプ単純比較してると思ってるんだ。 >>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 Git真理教信者はGitはとにかく正しいのだという盲信から発言するから、自分とは違ったニーズを持つ他者がいるという想像もできないし、そもそもエビデンスを出しての議論ができないんだよなあ
口汚く罵るだけで >>150
初心者はとまどうのかもしれないが
慣れたら問題ないことに気付く
どうせ秀丸でも使ってるんだろ hookで実現する方法はあるし、必要ならそれを使えばいいだけだと思うんだがどうしてその機能がデフォルトで用意されてないだけでそこまで喚くのかわからない >>164
わからなければ参加しなくてもいいんですよw 公式のgit guiもネイティブのwindowsソフトのくせに日本語含んだディレクトリ名とか未だにダメダメだな
この時代に他言語対応がここまでダメなメジャーなソフトも珍しいんじゃね？ >>166
まったく珍しくないけど。
ユーザー名に日本語含めないようにするというバッドノウハウが広まってるのがいい証拠 >>169
少しは文句ばっかり言われる自分を省みてみたらw 結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ？
煽るにしたってgitに取って代わるようなツールを挙げてくれないと面白くないんだけど お前が面白いとかつまらんとかほんとどうでもいい
言うことないならスレ汚さずに黙ってろ >>150
> それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する
gitの思想じゃない。ソフトウェア開発の思想。
最新のタイムスタンプのものだけビルドするという考え方は
gitができるよりはるか昔からのやり方
gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ？ >>174
gitしか知らないぺーぺーのひよっ子が面白い事言うなｗ
お前センスねえわｗ そもそも
>gitの思想と違う
なんて発言は誰もしてないのに、さもそんな発言があって、それが共通認識であるかのように語る
病気ですね >>175
svnも知ってるが？
svnを使っているときからsvnはだめだと理解していた。
gitを知った（がまだ使えない）ときから、俺が欲しかったのはgitだと理解できた。
svnはすごく開発しづらかった。なにせ間違いが許されないから。
人間だから間違いはかならずある。svnだと間違いが許されなかったから
仕事を一旦片付けて（コミットして）落ち着いて確認するという作業ができなかった。
間違いは間違いのまま残り、意味のないコードを他の人にレビューさせるのが
すごく無駄に感じた。それが解消されたのでgitはすごくストレスフリーだよ。 >>177
いや知らねえよお前はｗ
それどこのｲﾝﾀｰﾈｯﾂで拾ってきたgit神話だよｗ >>178
なんで俺の書いた内容に反論しないの？ｗ >>179
それはこっちのセリフだよｗぺーぺーのひよっ子クンｗ >>161
例えばGoogle Chromeとか1000万行以上、ファイル数も数万個あるんだよなぁ、そこまで大きなプロジェクトはあまり無いだろうけどさ。
ハッシュをDBか何かにファイルパスのようなuniqueな値と合わせて書き込まなきゃならないだろうし、画像などのリソースを固めるなら大きめのファイルのハッシュも計算しなけらばならないだろう。そのベンチマークはちょっと見通し甘いと思う。 >>181
なんだよもう諦めたのかｗ
俺はもっと笑いたいんだけどなｗ
もっと聞かせてくれよぅ
ひよっ子クンのソフトウェアなんとかｗの思想ｗ >>174
なんかよくわからんけど、例えば一年前にコミットしたmakeファイル含むビルド環境一式があって、
それを再現したいとき、オプションでタイムスタンプも含めてぜんぶそのときの環境が再現される
オプションがあればそれはそれで便利じゃないの？ >>185
だから何が便利なの？
タイムスタンプを再現して何が嬉しいの？
標準に入れろっていうくらいなんだから大多数が納得するようなメリットを示せるはずだよね？
それがこのスレで一つも出てきてないんだけど >>185
>それを再現したいとき
それってどんな時？ってのが行き着くところだと思うよ
上の方でもちらほら出てるけど、必要なら実装すれば良いし、必要だと思う人が多ければ標準の機能として組み込まれるでしょ >>185
日付が戻るのはソースファイルだけ。
そのソースファイルを使ってコンパイルすると
オブジェクトファイルができる。
"現在の日付の"オブジェクトファイルができる。
その"現在の日付の"オブジェクトファイルをリンクして
"現在の日付の"実行ファイルができる。
出来上がるのは現在の日付のファイルばっかり
で、なんか言った？ まぁ git checkout でブランチ変えるたびに make clean なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな
タイムスタンプを復元して何が嬉しいのか良く分からないけど
（ファイルに変更を加えた日を知りたいだけなら適切にコミットしてたらファイルに手を加えた日とコミットした日に大きな違いはないだろうから確認に困るってことはないし）
git以外の何らかの管理ツールがタイムスタンプで何らかの整合性を保っててその管理ツールのデータファイルもgitリポジトリに一緒に突っ込んでるとかかなあ？ >>189
そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。 普通に考えて日付が違っていてもコンパイルすれば
同じ実行ファイルができるべきである。
でないと、ファイルを保存し直しただけで
違う物ができることになってしまう >>188
いや >>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが >>191
そもそも具体的に何のためにそんなことしたいのかが分からないな >>192
じゃあバックアップツール使え馬鹿で終わりだなｗ 意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
言い続けるかｗｗｗ >>182
まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。
つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ？ >>196
gitでタイムスタンプを管理しないのは失敗だったかも
（でも今更だし悪い仕様でもこのまま乗り切るわ）
と講演で言っていたよね >>196
やっすいことで満足できんだなあお前って
悲しくない？ >>200
なんだライナスも悪い仕様ってみとめてんだ プロジェクトを作り直してコードもファイル構成も全部作り直す場合は
gitでブランチを作成して底で作業するか、別のディレクトリを作成してそこで作業するかどっちがいいでしょうか？ >>200
ああ、アイツだろ？ 名前忘れたけど
あとでTwitterとかで馬鹿にされまくってて
アカウント削除して逃げちゃったやつ
>>202
> なんだライナスも悪い仕様ってみとめてんだ
ライナスのことじゃないよｗ リーナスは「なんでお前、タイムスタンプを戻すのが間違ってるってわかんねーの？馬鹿なの？」って
煽ってるしなｗ
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 リーナス・トーバルズ曰く
https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536
>
> それは間違い
>
> それは馬鹿
>
（gitでタイムスタンプを管理なんて）
> ぜってーに実装しねーよｗｗｗｗ
リーナスにも煽られちゃったなｗｗｗｗ 調べてみるとvsもcsvもsubversionも当然のようにタイムスタンプ復活できるんだな
リーナスの手を離れたわけだしメンテやってるあの人もそんな当たり前の機能はとっとと実装して欲しいもの つまりgitは進化したってことだな（爆笑）
はいはい、なんでsubversionでタイムスタンプ復活させるのが
間違ったやり方だって言われていてデフォルトオフなのか考えてみましょうか >>207
あ、ぶっちゃけさ、お前
gitでタイムスタンプを管理しないのは失敗だったと
リーナスが言ったと嘘を言ったのがバレたから、
調べてきたろ？ｗ git logからコミット日時引っ張ってくるシェルスクリプト書きゃいいだけなのに、標準で入れるまでもないだろう >>210
わざわざ自分で書かなくてもGitHubとかで誰かがその手のツール作ってるだろうからそれ使えばよくね？ Linus教はLinusが言ったことは全て真理というドグマで洗脳されているのか。
そりゃ議論にならんわけだw Linusが言ったとデマ飛ばして、それを否定したら >>213 コレ
議論したいやつには全く見えない >>167
>git for windows ならいける
そういやこれ試してみたがちゃんと日本語ディレクトリや空白いりディレクトリでもちゃんと動作するな。
なんで公式のGUIツールはあんなクソがいつまでもほったらかしなんだ？
メンテナの出来が悪いのか？ >>217
彼らにとってWindows版が必要ないからかな git gui普通に日本語ディレクトリ名を表示できたけど・・・？ >>203
新しいリポジトリ作るほうがいいと俺個人は思う gitでコードを管理している分にはタイムスタンプを戻すのは愚策だと思う
（Linusもそこはハッキリ言っている）
コード以外のファイルを管理するならタイムスタンプを戻せるようにすべきだし
cvsやsvnは実際に戻せる仕様になっている
要するにgitではソースコード以外は管理できないし、させたくもない
（Linusはこれもはっきり言っている）
だからタイムスタンプも戻さない ExcelとかビットマップまでGitで管理しようと主張するマヌケが会社にいて困るわ。
適材適所ってことがわからなくて、なんでもGitが優れていると盲信してる。 >>223
決めの問題だからそう決めたなら、Gitで管理すればいい。成果物によって数ヶ所に置き分けないといけないよりまし。 >>224
決めの問題ならなおのこと 決めたやつがおかしい という話では
実際のところ、テキストベースではないドキュメントの管理は
gitでやる価値が半減すると思う
もちろんcvsやsvnでもあまり意味はないけど >>223
困るならちゃんと説明してあげるか転職して会社変わったほうがいいよ 節目節目のあるリリースに関連付けられた形での
重要なデータとかテストデータとかをコミットに加えるのはありでしょ >>227
説明しても聞かないって話だろ
盲信ってことばも知らんのか？ なんだGitに向き不向きがあるよって話だけでここまで怒り狂うのか
怖いわほんとｗ diffが取れない程度でべつにエクセルのファイルを管理してもいいと思うけどね。
向かないとかいっても 20170319-hogehoge.xls みたいなファイルが山盛りよりはいいと思うな。 ここでもめてるgitの話題って英語圏のフォーラムとかでも似たようなやりとりあったりすんのかな
please recovery timestamp!って 実質的にタイムスタンプ復元する方法が提示されて終わりじゃない？まともなフォーラムなら
どんなケースでどんな機能を求めてて何を試してみたかを全く明らかにしようとしないまま機能が足りないって喚いてるだけだからなぁ
建設的な議論にならないよね。 >>229
知らなかったから辞書で調べてから書き込んだんだけど…
なにか気に触ったのならゴメンな >>234
Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ WindowsでGUIのものを使おうと思ったら・・・・
お勧めって、亀さん？ git archiveで作ったzipのタイムスタンプって
コミット時の時刻になってない？ >>231
Excelはxmlになってからdiffとれるでしょ
見やすいdiffが必要なら専用のツールが必要 そういや最近TortoiseSVNでexcelやwordファイルのdiff見たら、Office自体の
変更差分表示機能使ってくれて驚いた。
gitはコマンドラインでしか使わないから知らないが、どうなんだろう。 >>241
あのさ、差分機能で更新箇所を確認するのは仕事のやり方としては下策で、仕方なくやるものなんだけどな。 プログラミングにかかわらずドキュメントの類は差分ベースで仕事を進めることで効率が著しく向上する
これに気がついてない日本のホワイトカラーの現場はほんとヤバイ Excel仕様書なんか捨ててMarkdownとかで書いた方がいいこと多いよね
軽いし差分比較も見やすいし おまえらどこをどう変えたのか毎回忘れて差分比較して仕事してんのかよw >>248
お前の所は作った本人しかドキュメント読まないのか？ わざと忘れたりするわけじゃないが
最近は差分を積み上げてくような感じで仕事をしてる
できうる限りそれで進めて、どうしようもない時だけ時間をかけて全体を見る >>249
共同作業の場合は更に効果倍増だな
でも、おれは一人でも作業する場合も、差分ベースで作業を進めることが劇的に効率を上げると思ってる >>247
個人的には AsciiDoc 使ってるんだけど他にお勧めある？ >>252
あんたにとってはgitもレベルが低い仕組みなんだろうな
でもこれが普及して他のツールを駆逐してしまった意味をよく考えてみた方がいいぞ 全然駆逐してないんだけどな
SVNもP4も普通に使われてる もうgit以外を使ってるのは普通じゃない
特殊な事情 >>259
で、gitのことはどう思ってるの？
差分を編集する機能を重視してるのがgitなんだけど
差分機能で更新箇所を確認するのが下策だと思ってる人はこれを受け入れちゃうわけ？ >>260
gitやその他vcsのことを何もわからずに煽ってるだけなんだから、
そんなに難しい質問してやるなよ。無視するしかなくなるだろ。 >>237
亀はだめ
Explorereが劇重になる >>258
新しいプロジェクトに配属されて、バージョン管理がSVNだったらガッカリするからな >>236
> Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
ファイルのタイムスタンプだろ？
保存してないよ。
嘘だと思うのなら、ファイルを修正してから次の日にコミットしてみ
ファイルのタイムスタンプじゃないものが保存されるから >>260
Office製品の変更履歴機能の失敗も知らない世代なのか？ バイナリファイル系は適切なツールを使えば
差分を知ることはできるが、
差分を知る以上のことはできない。
例えばcherry-pickとかmergeとかね
ただsvnとかでバックアップツールとしか
見てなかったやつは、そもそもmergeとかいう概念がないから
差分だけわかればいいと勘違いしてしまう。
それじゃプログラマとはいえない。 officeのドキュメントを差分管理ベースで作業できるようにするなら
ドキュメントの中の要素を個別に差分取って管理できるようにならないとダメだろうなあ
アプリのソースが一つのファイルにすべて書かれてて、
それをgitで管理しろとか言われたら気が狂うｗ 複数のブランチを切ることがそもそもない環境なら、mergeとか知らなくてもしょうがない >>271
ZIP解凍した中身をgitで管理
pullで自動圧縮するようにできればお望みのことが実現するのだが >>273
docxとかだよね？あれの中身って文章が構造的に分割されてるわけじゃなくて
単にスタイルとかイメージとかが分離されてるだけじゃないの？ >>274
それでもXMLだから差分は一目瞭然かなと
xlsxやpptxならシート/ページごとにXMLファイルが分かれるからもっと管理しやすいかも >>270
行単位の処理とかは無理かもだけどcherry-pickやmergeはできるんでない？ >>275
少なくとも、差分を見ただけでどの章のどこが更新されたかが分からないとつらいかな
ドキュメント全体をひとつのxmlで管理するなら
そういう機能をもった差分ビューワが必要になると思う >>277
そういう目的ならExcelかPowerPointってことになるかね Office用の見やすいGUIの差分ビューワもあるけどたいてい有償だから
まずはここに書いてるのから試してみたら
http://qiita.com/shuhei/items/6a18d968051378d7ac1a >>275
差分見えてもmergeはconflictの山になって事実上無理ぽそう。 ここで言うことでもないけど
いい加減Officeを卒業したい 早く画面キャプチャをExcelに貼る作業にもどるんだ >>275
> それでもXMLだから差分は一目瞭然かなと
え？ お前OfficeのXMLのタグを知ってるの？
XMLのタグを知っていないと、差分は分かっても
その意味はわからないよね？
>>280
> 差分見えてもmergeはconflictの山になって事実上無理ぽそう。
XMLのタグの整合性、つまり閉じタグの対応まで
ちゃんとやらないとだめだからねｗ
タグの意味、属性、誰か解説してる人いる？ Excelファイルのバージョン管理なんて実質タイムスタンプで管理するしかないのに、とにかくGiｔ真理教の信者は
なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す gitがバイナリに弱いのは誰もが認める話だと思うけど、タイムスタンプで管理するのは無くない？
svnとか他のバージョン管理システムってタイムスタンプ見て管理なんかしてたっけ？ >>270
適切な扱いが出来るかはそのバイナリファイルを扱うソフトウェア次第
3wayマージが出来るならgitの機能は全部使えるだろう >>285
gitがじゃなく、汎用バージョン管理システム全般が、個々のファイル仕様に独自に対応しなければならないファイルに弱い
というより、テキストファイルのシーケンシャル性と改行で意味分割する仕様が特別汎用性に優れてるだけ
gitはエディタも差分表示もマージツールもファイル属性に応じた外部ツールを使用出来るようになってるから、まだそういう仕様が不明なファイルに強いと言える
gitが弱いのはバイナリファイルではなくサイズが巨大なファイル
たとえテキストファイルでも1ファイル1Gとかになると扱い辛い事になるはず >>284
excelは標準では同じファイル名のファイルを同時に複数開けないし開いただけでタイムスタンプが変わるから、ファイル名でバージョン管理するのが基本だと思うけど
どうやってタイムスタンプでバージョン管理するんだ？ >>265
どうでもいいけどファイルのタイムスタンプを保存している(する必要がある)なら
ファイルの中身を変更せずにファイルの日付だけ変更してコミットしたときに
何も変更されてねーコミットスルーしよーぜってのがgit
それもファイルの変更とみなしてコミットするのはあほ 指定した範囲のコミットログを表示する方法を教えてください
例えばhttps://github.com/git/git/releasesなら
タグv2.11.1からv2.10.0の間のログのみgit logで表示したい
タグがダメならコミットIDで指定でも構いません指定した範囲のログさえ取れれば >>284
> なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す
差分での管理なんて一言も言ってないけど、
ソースコードであればテキストファイルで管理するのが
一番実用的だ。これは本当。
ソースコードがテキストファイルでないものがあるが
（例えばExcelなどの埋め込みVBScript）
見事に管理しづらい。 >>289
何を言ってるのか全くわからない。
コミットの日付とファイルの日付（タイムスタンプ）は本質的に違うものであって
gitが記録しているのはコミットの日付であって
タイムスタンプじゃないといったのが理解できなかったの？
コミットの日付を記録するんだから、ファイルに変更がなくコミット自体が発生しなければ
当然コミットの日付は記録されんよ。当たり前だよ。 >>288
> どうやってタイムスタンプでバージョン管理するんだ？
ここで>>284に言ってほしい言葉は、
「タイムスタンプが新しい方を最新バージョンとみなすべきだ。
たとえ古いファイルを間違って修正した結果、新しい日付になった場合でも
AさんとBさんがそれぞれ違うシートを修正したとしてもだ！」
って（間抜けな）言葉だねｗ 当然、そうならないようにロック機能をつけるんだよw ロック機能をつけた所で、違うブランチで作業したら
ロックかからないんだから、同じ問題が発生するだろｗ 当然、リポジトリは1つだけに限定してブランチも認めないんだよw >>297
それじゃファイルの管理しか出来ないじゃんｗ
どうやってアプリのバージョンの管理をするんだよｗ
新しいバージョンへ追加する機能をマージしていくのが
バージョン管理というものなのに せっかくのボケに対してマジレスしてどうする。
「それはSVNやんかー」と正しく拾ってあげんか。 マジレスすると、馬鹿がムキーってなるだろ？ｗ
それが狙いだよ。 >>294
なんか勝手にレベルの低い敵を想定して、それをバカにすることで勝ったつもりってのが新しいなw
情けないにも程があるw >>302
そうじゃないよ。もっと面白いことを言ってみせろってことだよｗ
>>294ぐらいの内容は想定済みだからさ >>296
そんな間抜けな機能を実装してどうする w svnはバックアップツール的な役割で当分生き続けると思う
ソースコード管理としてのsvnはもう見たくない
あとVSSとかいうゴミが未だに生き残ってるのはうちの会社だけであってくれ GNU - Free Software Directory
http://directory.fsf.org/wiki/GNU
この中でGitを採用してるプロジェクト少なそう GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)
https://gcc.gnu.org/
gccですらSVNだし Gnu Emacs は古参を説得してgitに移行したんだよな gitと同じ機能があればsvnでもいいんだけどなA: [0.091163 sec.]B: [1.205233 sec.] いやそれなら git でいいだろってなるでしょ。
ってなんか話がわかんなくなってきた。。 リーナスの最大の功績はlinuxではないrebaseなのだ
おかげでバカがrebaseに夢中になっている間にスムーズに仕事が終えられる gitに限らずコイツらの布教活動が成功したためしなどただの一度もないけどなｗ >>323
自分がいいと思ってる、使っているものが正しいという阿呆がなんにでもある。 世界を自分(たち)にとって都合の良い方向へ変えようとする活動が布教
変えてゆくためには相手を納得させるか騙すか強要するか
都合の良い部分は伝えるが都合の悪い部分は隠すか屁理屈か嘘で押し通す
布教行為を許してはならない VCSは頭の良い奴にしか使いこなせない
複数種類のVCSを使いこなせるのならかなり頭が良い 言ってもいいんじゃね。
おれもgit は好きだけどgit厨は嫌いだし。 >>332
わかる
特定のflowを絶対正義だと信じて「git pull --rebaseしないのは馬鹿」とか言い切ってくる奴とかなー あるある大事典：
git の話ばかりしているから svn スレかと思ったら git スレだった… gitの話ばかりしてるから、(gitに対して嫉妬してる)svn(ユーザ)のスレかと思ったら、git(信者がのさばってる)スレだった… SourceTreeって重くね？
リポジトリを幾つかブックマークに追加しただけなのに
起動がとんでもなく遅くなった branchだけしてcheckoutし忘れ
誤ってmasterブランチにコミットする大事故 >>342
つgit checkout -b new_branch git stash popは危険なコマンドだと思いませんか？
間違えたブランチで実行してしまったら元に戻せませんね。 マージ失敗したらdropされずに残るので、やり直せる
マージ成功ならもう一回stash saveも出来る
万が一？pop後にファイルをresetしてもコンソールを閉じていなければdropしたコミットハッシュが残っているはず
億が一それも消しちゃってもfsckで到達不能なコミットを探せば復元可能
間違って消す方がむずい 大抵の手違いは元に戻せるのがgitのいいところなんだけど
ファイルスタンプを戻すのだけはなぜかできないんだよな・・・ ファイルスタンプは手違いで発生するものじゃないからねｗ
手違いじゃないのだから戻さらないというのが
正しい動作。 いつまでタイムスタンプの話続けるの？
欲しいやつはgit logから引っ張ってくればいいだろ リーナスにタイムスタンプ入れるとかアホって言われたのが
よっぽど悔しいんだろｗ インターネットみてると「マスターをチェックアウトして」とか
「マスターへチェックアウトして」とかいろいろな表現を見るけれど。
どれもマスターのブランチへ移動していることを示しているのがおかしくないですか？
今のブランチをチェックアウトしてマスターにチェックインするってことなんだから
前者はマスターから抜け出すことになるし、後者は意味不明になりますと思いませんか？ 自分がブランチに出たり入ったりするというのは斬新な見方だな。ホテルかよ。
リポジトリから指定のリビジョンのソースを(ブランチ・タグ・ハッシュ等で指定して)チェックアウトするんだよ。
後者は日本語に不自由なやつなだけだと思うが。 >>359
後者は「マスターをチェクアウト」と「マスターブランチへ移動」が混ざったんじゃ無いかな？ >>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&*
"マスターへチェックアウト"との一致はありません。 ごめん、結構いたわ。
"masterにチェックアウト"
約 724 件 （0.45 秒） コンフィグのここで疑問なんだけど
[branch "master"]
remote = origin
merge = refs/heads/master
ここで、なぜmerge = origin/masterじゃなんですか？
branchマスターが追跡しているのはorigin/masterで
origin/masterが追跡しているのがrefs/heads/masterなので、
一段飛び越えていて変なんですけど。 ブランチを切る ってどっちの意味？
作成する？ 削除する？ もしかしてrefs/heads/masterはローカルを指していて
デフォルトでmasterでpullすると別のブランチのところにmergeされるってこと？
それがなにの役に立つというの？ refs/heads/masterはリモートを指してるらしい、
そしてpullで初めにfetchしたときにrefs/heads/masterがfetchしたなかにあると
refspecで調べてorigin/masterに変換して今のブランチにmergeするらしい >>368
refs/heads/masterが、masterという名前のブランチの正式表記で、originのリモートリポジトリの別名表記ってだけじゃないの？
tagにも同じ名前を付けられるからコンフィグは正式名称の方が都合がいいし、
リモートリポジトリは参照するサーバーやリポジトリパスが変わることもあるし、同時に同じリモート名は付けられないから別名表記の方が都合が良い
ってことだと思うけど。 ホテルから出ることをチェックアウトと言う
リポジトリという名のホテルに
masterブランチさんやdevelopブランチさんたちが宿泊してる
そこからチェックアウトして作業現場まで来てくださいって意味
git checkout master SVCとかSubversionとかVSSだとリポジトリからファイルがチェックアウトされて
編集されたあとまたチェックインして元に戻る、というアナロジーが非常にわかりやすい
けど、Gitだとなんかいろんな路線に分岐してはまた合流、って感じが強くてなんか
あわない感じはあるよな。
流れのなかのある「状態」に戻したり勧めたりする感じというか。
もっとわかりやすい用語にできたのかもしれない。 >>373
おっさんは色んな環境・用語に晒されてるから、VCSみたいな同じような機能にそれぞれのアプリケーションで別の用語を割り当てるシステムだと、ごっちゃになるんだよ gitのタイムスタンプは記録されてないけれど
パーミッションは記憶されてるの？ >371
そーかなー
むしろそういう風にコマンドを整理したのがsvnでリポジトリからローカルコピーを得る時しかcheckoutじゃないでしょ。
gitはチェックイン/チェックアウトシステム体系はCVSと変わらないからcheckoutするときはcheckoutで良いと思うんだが、ローカルの編集を破棄したいときこそresetだとかrevertとかにして欲しかったとは思う。 >>375
実行権限のみ
いろんな人がいろんな環境でチェックアウトするのだから
グループやその他のパーミッションは記録する意味がないし、
umaskの設定に従えば十分
また自分自身がチェックアウト（＝書き込む）ファイルなのだから、
リードオンリーにすることもできない。
よって実行権限のみ記録するのが
バージョン管理ソフトとして正しい仕様。
gitもそれに従っている。 正しい仕様、みたいにすぐドグマ化しちゃう人って柔軟な発想ができなくて開発者としてはポンコツなんだろうなあ >>380
これわかるわ
正しいとか正解とかそういう言葉を頻繁に使う人は状況に応じた選択ができない >>380
同意
明確に条件が限定された状況で、考え抜いた上に「正しい」とか言うのならわかるけど、バージョン管理なんてソフトウェアのソースコードに限ったとしても
ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに、自分の知ってる範囲だけで決めつけちゃうのってダメだよね
お客さんの要求の本質を汲み取ろうとせず勝手に自分の都合で判断してそう >>378
> 所有者くらいは記録してほしかったよね
所有者とは？ 会社名？ｗ
一行ごとに誰が修正したかは記録されている。
その話をしていないということはお互い理解しているという前提で
なんのために所有者を記録するの？ >>384
> ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに
ぜんぜん違うと言うものの具体的な例を
君はこれから言わなくてはいけないということになったんだが、
できるかい？
それができるまでは、ゲーム、組み込み、Web、業務システムで
求めるものに違いはないという今までの常識通りでいくからさｗ 信者というとgitが如何わしい新興宗教みたいじゃないか
こういうのはストレートに馬鹿と呼んで欲しい git信者は巨大なバイナリデータの管理もgit一本でやるの？
カッコ良すぎて濡れちゃう// 信者なら「そんなもんリポジトリに入れんな」って一蹴だろ。 そしたらリポジトリに入れないでどうやって管理するの？という質問がでてくる 刺身包丁で中華料理をつくる料理人みたいだな。
gitでバイナリ管理。 巨大なファイルはリポジトリに入れないで、ファイルがある場所の情報だけいれればいいのよという意見が出てくる ブランチ切り替えて別のファイルに変わるたびに入れ替えるの面倒だよ gitのフックがあるじゃないか。そこで自動化すれば良いのさ なるほど。巨大なファイルは別のストレージで管理して、git cloneしたときなどに
フックでファイルが有る場所の情報からファイルを取ってくれば良いのか！ 便利そう！それプラグインにした良いんじゃないかな！？ 暇なので何度も出たであろうネタ投下ｗ
Linus曰く「Subversionは史上最も無意味なプロジェクト」
https://developers.srad.jp/story/07/12/03/1024220/ 何に使うかも分からん機能について語るのが最近の流行りなん？ >>385
基本的に 可能な限りファイルの属性は記録してほしい ということ
タイムスタンプもそうだし、userやgroupもほしい
あとはスペシャルファイルのたぐいも >>390
じゃあどうするの？
別のバージョン管理ツール使うの？ >>415
"バージョン"管理ソフトっていうのはファイルの版ではなくて
アプリのバージョンを管理するもので突き詰めるとソースコードを管理するものなんだよ。
ソースコードの管理というのはファイルの中の修正箇所を調べたり
一部分を抜き出したりマージすること、ソースコードエディタと言ってもいいぐらい
バイナリファイルであればそれらが出来ないので
どうあがいてもバージョン管理は出来ない
せいぜいファイル管理程度 >>416
じゃぁファイルの版はどうやって管理するの？ ファイルサーバーにでもおいておけば良いんじゃねーの？ >>418
ファイルサーバーで「版」の管理はできるの？ 「版」の管理ができるファイルサーバーを使えばいいし、
たいていはバックアップ機能で十分 >>419
そんなもんWindows標準のバックアップ機能でもできるよ ソースの版とリンクしてる
バイナリファイルの版をどう管理するのかってことじゃないのか？
バイナリしかないサードパーティライブラリとか画像系のアセットも普通gitで管理するよね？
デザイナ系の人が頻繁に編集するデカいファイルはGitLFSみたいな追加の仕組みを使うか
別のツールで管理してリリースバージョンのみgitに入れるかかな >>423
結局これが一番困るよな。
テキスト以外なくても困らない開発だったらいいんだろうけど、そうじゃないものも多い。 大きなバイナリファイルのバージョン管理が本当に必要ならべつにリポジトリに入れてもいいんじゃね？
単にリポジトリがでかくなるのが嫌われるだけで、他のsvn等に比べて特にgitが苦手というわけでもあるまい。 >>423
そんなもんファイル名、もしくなディレクトリ名を別にしておいて
参照先の名前を変えれば済む話だろう？ >>427
済まないから困るんだろ、勝手に問題ないケースに置き換えて話するのはおかしいでしょ 画像リソースまでソース管理から除外するのかよw
基地外じみてる 俺はできる限りはリポジトリに入れるけど。
100 M とか超えてる場合はちとどうするか迷うが。 >>427
参照先の名前変えるってなにそれ？
管理したいバージョンごとにファイル名やディレクトリ名を変えるの？ >>432
ファイル名やディレクトリ名は最初に作ったまま固定変えたりしない。
ファイルサーバーは原則として追加するだけ。
そして新しいリソースに更新したければ、
ソースコードの設定ファイルをいじって、
参照するファイル名（ディレクトリ名）のパスを変更する パスを変更するってことはディレクトリ名かファイル名かは変わってるんじゃないの？ >>434
ファイルは追加するだけなんだから、最初から別の名前にするしかないだろ。
中身が違えば、それは別のものだ。 結局ファイル名に日付入れて管理しろと言い出すわけだな。
gitいらないじゃん。 ソースコードはGitで管理して
ソースコードに関連するバイナリはファイルサーバに日付入りのディレクトリにおいて
新しいバイナリが追加されたらGitで管理してるソースコードにそのバイナリへの参照の更新をコミットする
こんなの普通にやるだろ
これとgit無しで全部日付入りフォルダで管理することの違いが判らないのは基地外 >>436
> 結局ファイル名に日付入れて管理しろと言い出すわけだな。
> gitいらないじゃん。
だからバージョン管理システムは、ファイルの版ではなく、
ソースコードのバージョンを管理するものだから、
バイナリにはgitいらないって言ってる。
人の話聞けやｗ
gitはソースコードを管理するためのものだ
ソースコードじゃないものを管理するものじゃない。
巨大なバイナリファイルをいれんなｗ Git LFSはすでにVersion2.0.2でGitHubもGitLabもGit LFSに対応済みなのに
バイナリだけファイルサーバや別のツールを使う理由がわからない。 Git LFSは "別のツール" だぞｗ
それこそバイナリだけ別のファイルサーバーに格納するものだし、
単にファイル名とリンク先の対応を自動化したものにすぎない。 >>442
別サーバーにする必要はないよｗ
同じサーバーで2つのツールを動かせばいいだけ
gitサーバーとファイルサーバーの2つ 何がありえないのかわからん。
そんなにいやなら、gitlabみたいな
gitサーバーとlfsサーバーが
一緒になったツールに使えばいいやん。 >>441
バイナリは世代ごとにディレクトリを変えて保存し
ソースコードの設定ファイルをいじれという話はなんだったの?
Git LFSならそんな手間は不要でソースと同じように扱えるだろ。
まあGit LFSを使う事に異論がないなら他は重要ではないけど。
>>444
GitLabとGit LFSを使ってExcelなどのバイナリでできたドキュメントの世代管理をする
http://blog.naotaco.com/archives/1112
最初にバイナリ管理にしたい拡張子とLFSサーバを登録するだけで、
後はソースと同じgit コマンドで取り扱える。 >>446
> バイナリは世代ごとにディレクトリを変えて保存し
> ソースコードの設定ファイルをいじれという話はなんだったの?
gitにバイナリファイルを入れないでバイナリファイルを使う方法の一つ
それを自動化したのがgit lfs >>445
そんなアホなことせんでも全部gitに放り込んで問題ないですし >>448
バージョン管理ソフトでバイナリファイルを扱う意味がないということ
問題がないなら入れてもいいだろうが、それは単に入れるだけ。
バージョン管理は出来ない。 >>449
プロジェクトのリリースバージョンごとにバイナリを管理できて大いに価値がありますが >>450
> プロジェクトのリリースバージョンごとにバイナリを管理できて大いに価値がありますが
それは、リリースバージョンごとにバイナリをディレクトリに配置して
リポジトリに登録するという作業をやった場合の話だろう？
その作業とファイルのリンク先を変えるのとは手間は大して変わらんのだが？ >>451
え？
リリースごとにタグ付けるなりブランチ切るなりするだけですけど >>452
それはファイルのリンク先変えるのも一緒です。
はい、ざーんねーんｗ >>439
ソースコードと不可分なリソースファイルだったとしても、「見た目がバイナリだから」バージョン管理ツールであるgitで管理する必要はないと言いたいのかな？
例えば、ゲームのマップデータのような独自フォーマットのリソースはパーサーと一緒に管理しないと意味が無いわけだが、「バイナリだから」入れる必要はないのかな？
逆に、自動生成された巨大なXMLは実際にはgitで管理しても実際にはdiffを確認したりマージしたりすることはできないけど、結局はバイナリデータのようにしか
取り扱えないと思うけど、「テキストだから」gitで管理する意味があるのかな？
「バージョン管理」と「差分確認、マージ」は完全に同一というわけではないし、バイナリだからできない、テキストだからできるってものでもないだろ。 >>456
バージョン管理ソフトはソースコードを管理（＝マージなど）するもので
それができないのなら入れる必要はない。
入れてもいいけど入れる必要はない。
大きいバイナリなど入れることで問題が起きるのなら
入れないほうが良い 画像リソースなんてソースファイルみたいなもんなのにいちいち分離してられるかよ
CUIしか作ったことないのかな バイナリはファイル名でバージョン管理したい人みたいだからもうほっといて差し上げろ
ID:9Eckjtd/0 == ID:n7h/bBRg0 ファイルを管理するためにgitを使うんじゃなくて、
gitを使うためにソースコード入れてるだけの人だよね。
開発してるわけじゃないんだよ、git使ってるだけ。 >>383
>ファイルを管理するためにgitを使うんじゃなくて、
>gitを使うためにソースコード入れてるだけの人だよね。
>開発してるわけじゃないんだよ、git使ってるだけ。
こいつバカかw 好きに使え。
ツールに振り回されてどうする。
バイナリ入れたきゃ入れればいい。
入れたくなければ入れなきゃいい。
ケースバイケース。 バックアップツールとして使いたいなら
gitじゃなくてバックアップツールを使ったら良いじゃん？ プログラムに内蔵されるリソースの話をしてるのに、
バックアップツール使えとか、頭おかしいだろ。
頭の中身もgitで管理してみたらどうだろう？ 画像リソースで話が通じないんだもん
本当にCUIしか知らないんだろ GitLFSは2.0になったとは言っても、1.xの頃がベータ版みたいなものだったし、
使ってみるとわりとトラブルになることが多いよ >>467
svnになれるってのがどういうことかわからない。
俺はsvn使っていたときから、間違ってコミットしたらどうするんだよ？
こんな多すぎるコミット他人がレビューできないだろ。
ネットワーク通信いちいち遅いだろ。リポジトリを新しく作るだけで
なんでこんなに手間かかるんだよって不満たらたらだったんだが
（当時gitなどの分散バージョン管理ソフトは知らなかった）
不便に慣れてしまったってこと？ これは流石にsvn使いこなせてないとしか言いようがない ID:n7h/bBRg0に釣られている人は下記スレをID:n7h/bBRg0で検索してみよう。
自分と他人の意見が違うのは他人がバカだからだ、で思考停止して
他人の説明を理解しようとしないからこの人に何か理解させるのは難しいよ。
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/ >>467が一番あんぽんたん
あんぽんたんに釣り上げられた奴が2番目のあんぽんたん >>473
> あんぽんたんに釣り上げられた奴が2番目のあんぽんたん
再帰問題だな svnは逆に集中管理できるのがいいんだろ
間違ってコミットしたら前のバージョンに戻せばいいじゃん gitを宣伝するためのこき下ろしって分かんないのかな >>479
それはgitと関係ない。
シェルプロンプトの問題であり
Windowsのコマンドプロンプトなんかだと関係ない >>472
「お前がそう思うんならそうなんだろう お前ん中ではな」っていうのを地で行くパターンだよなぁ
仕事で使ってるなら実際に困る案件で使わせてやりたいわ >>483
納品関係のタイムスタンプ重視の風潮と正反対だな >>485
知らん
誰もが意味ないよなと思いつつ、納品日に合わせて納品ドキュメントのタイムスタンプを合わせる
多分、何らかの儀式なんだと思う >>485
ファイルのタイムスタンプは基本的にファイルを編集した日になるから
納品日以降になっていたら誰かが編集しちゃったことが簡単にわかる。
納品物に.gitとかないしね >>487
タイムスタンプで編集されたことを検出しようとする事はとりあえずおいておくとして、それだったら別にcheckoutした日時で良くない？ >>487
誰が編集したかどうかは、わからんよ
納品日は3/31であっても、その前に諸々のチェックが必要だから1週間前には納める
だが作業予定は3/31まで入ってるので、納品物の日付は3/31で作る
3/31の日付のファイルのタイムスタンプが3/24だと不自然なのでタイムスタンプを3/31に変えておく
タイムスタンプに手作業が入ってるので、日付が新しい方が最新とは限らない >>487
> 納品日以降になっていたら誰かが編集しちゃったことが簡単にわかる。
え？ 悪意がある人にタイムスタンプを変更されたことないの？
バージョン管理ツールを使ってない時に、ウイルスチェックをした後に
ファイルの同じ日付をみたらウイルスチェックをする前だから
ウイルスチェックした後に修正されていません（＝ウイルスに感染していません）と
OKだしたら実はウイルスに感染していて、大混乱が起きたんだが？
それ以降バージョン管理ツールを使ってソースの修正履歴を完全にトレースできるようにしている。
仮に誰かが感染したとしても、他の人と違いがあればマージとかで問題が発生してすぐに気づくことができる。 >>493
1. 悪意がある人にファイル修正した後にタイムスタンプを戻された。
2. ファイルの更新日付が変わってないのにウイルスに感染していた。
これでわかる？ なんか知らんけどいちいちアーカイブ作ってんの？
gitでやり取りした方が速くね？ >>491
>3/31の日付のファイルのタイムスタンプが3/24だと不自然なのでタイムスタンプを3/31に変えておく
すんげー無駄な作業だな
官公庁系？ >>497
svnだとリポジトリの中身、ツール使わないと見れないんだっけ？
gitだと今使ってる作業ディレクトリがそのまま
リポジトリになるんだよ。 素人さんに納品するのにgit使わすのはあり得ないね >>500
うん
客自身はソースコードを読まないだろうけど形式的に要求してくるところあるからね hashとればすむ話なのにタイムスタンプとかgitとか関係ないだろ
素人に納品してるだけじゃなく納品するほうも素人じゃないのか？ タイムスタンプを信じとるんやー
タイムスタンプ見れば更新されてるかわかるんやー
タイムスタンプで比較する方法が確実なんやー
故にタイムスタンプは信頼できるから
タイムスタンプを正しく保持しないと信頼できん 俺が信じるタイムスタンプを信じられるようにgitはタイムスタンプを保持しろ タイムスタンプ改ざんされて基礎された役人いなかったっけか
タイムスタンプそんなに重要っすか 発注後数日後のタイムスタンプだと苦労せずに作ったみたいで有り難みがないね 全てのプログラムは日付を不正に書き換えてはならない。
そうすれば、パソコンの時計を弄くらない限り
タイムスタンプは信用できる！ >>503
素人に納品したことないの？ 幸せなことだね。 うらやましいよ >>510
たぶん下請けしかやったことないってことだから幸せなのかどうかw >>512
素人と電話やFAXで問題解決をするはめになる >>510
ないよ 納品されるほうだから
受け取ったコードは自分たちでも管理するし
タイムスタンプなんて気にしたことない
そもそも相手が素人なら
タイムスタンプは簡単に改ざんできるから違う方法にしましょうって簡単に説得できる
お互いメリットがあるんだからそれをやらない・できない理由がわからないよ Git for Windows 2.12.2(2) タイムスタンプの話題はひっぱるなあ
もともとタイムスタンプが保持される方が便利な用途もある、Gitでもコミット時のファイルセットで
タイムスタンプが戻るのも選べると便利なのに、って内容のこと言われたら、現gitの仕様が絶対な人が
ずーとキチガイみたいにタイムスタンプ復元必要ねえ、ってわめいているんだよね？ ううん
タイムスタンプ保持して何に使うの？って質問に全く回答できなかった子が信者だキチガイだと暴れまわってるだけよ タイムスタンプ自体が不要だとは言わんが、gitに求めるもんじゃないだろう。 >>510
> もともとタイムスタンプが保持される方が便利な用途もある。
ソースコードにおいてはタイムスタンプは、便利便利じゃない以前に
ファイルを更新した時間でなければいけない。
ソースのコミット時間であってはならない。
これはMUST、絶対的な要件だ
checkoutなどでファイルを変更したならば、
その変更した時間（つまり現在日時）にならないといけない。
そうしないとソースコードは適切にビルドできないし、
ビルドを必要としないスクリプト系でもソースコードが
修正されたタイミングで内部的に再コンパイルするものがある。
今あんたが気づくべきは、俺がソースコードに限定した話をしているってところだ。
ソースコードを管理するツールだから、そういう設計になっている。 メタデータをコミット時に保存してチェックアウト時に復元できるような別ツール使えばいいんじゃね
必要としてる人がたくさんいると思うなら自前で作って有償で売ればいいよ
そんな難しいわけじゃないから ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
それでも後方互換性というか広く使われてるツールをサポートすることは大事だし
タイムスタンプを復元することの必要性がないからgitで対応されることは当面ないだろうね >>524
ビルドの度に全ファイルハッシュ計算して保持とかわざわざ遅くなる割にメリット殆どないような事をするわけがない。
メリットがあるのであればそんなに難しい事じゃないんだし既に存在して知られてるよ。 >>524
>ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
そんな話どこにあるんだ...ビルド時間が無駄に増えるだけに思えるんだけど、何かメリットがあるのだろうか >>525
> どこにハッシュ値を保持しろと？
全くそのとおりだなｗ
ビルド前のファイル ・・・の日付
ビルド後のファイル ・・・の日付
両方共ファイルの日付という情報を持っているからこそできること お前ら必死だな
ビルドツールがタイムスタンプベースで仕事をしてるのは
納品物のタイムスタンプを気にしてる素人のロジックと同じだっての
古くからの慣習ってだけ それは違う
ビルドツールが気にしているのはファイルが更新された時間だ
納品する時間ではない >>529
IDEのビルトインも含めてビルドツールいままでどれだか作られてると思ってんの？
で、それらすべて素人が作ってると？ 素人が作ったって言ってんじゃないよ
おまえらがバカにしてる納品物のタイムスタンプを気にしてるやつと考え方が同じだって言ってるの
Googleはタイムスタンプベースじゃないビルドツール使ってるけど
「何かメリットがあるのだろうか？」って聞いてこいよ
https://bazel.build/versions/master/docs/bazel-user-manual.html#correctness むしろタイムスタンプで十分なものをわざわざ遅く無駄にメモリとストレージとIO帯域を浪費するような実装しようとするほうが余程のマヌケか素人 >>532
タイムスタンプを使わないとは書いてないぞ？
タイムスタンプとファイル内容と書いてあるぞ？ >>532
それ、デフォルトでタイムスタンプ使うと書いてるけど？ >>534
ファイル内容というかファイルの依存関係だね。
既存の大抵のビルドシステムとやろうとしてることは同じ bazelを含めたビルドツールがタイムスタンプに依存しているのは
やはりタイムスタンプで比較したほうが速いからなんだろうね だってファイルシステムのエントリに保存されてるもの
ハッシュを常に取って保存するファイルシステム使ってたら、ハッシュベースな比較もいいだろうが ビルドに依存関係のあるファイル（中間成果物も含む）をすべて最新のソースに反映済みかビルドツールは確認しなくちゃまずいと思うんだけど、
それって結局ビルド中に出来るファイルのタイムスタンプとかハッシュをを全部確認するということと変わらないと思うんだよね。
ハッシュって結局全データ読まないとわかんないわけで、これから全データ読ませてコンパイルするかどうか判断するツールが全データ読んでたらなんとかならんのかと思うし、
普通ハッシュが変わってたらタイムスタンプも変わるので、タイムスタンプでコンパイルするかしないか判断をするのは理にかなってると思うけどもなぁ
タイムスタンプが信用できないビルド環境（分散環境とかであるんだろうけど）とか、touchしただけのファイルがコンパイルをめちゃくちゃ長くするとか、そういうケースだったら
ハッシュを使ったほうが良いのだと思うけれど。
だから、純粋にタイムスタンプを復元したほうがビルド前提のソースコード管理システムにとっていいケースってのはどういうときなのか知りたい。
ビルドが要らないものにはタイムスタンプを保持してくれたほうが同名別バージョンの判別がしやすい、ということなんだろうけれど。
けど、それも裏返せばタイムスタンプは簡単に確認できるから、人間がハッシュなんかでいちいち確認したくない、ビルド時の効率性を下げてでも人間に合わせろって意見なんじゃないかなぁ
タイムスタンプ保存する機能より、必要なファイルのハッシュ値をコミット時かなんかに取るようにして人間が変更されているのをタイムスタンプ以外の方法で確認しやすいようにした方が良いと思うけど >>520
タイムスタンプを保存したり復元するツールはそれなりに使い所があるかもしれないが、gitに含めない方が良いよな
ひとつのツールに機能を盛り込みすぎない方が良い 「Gitを部内で普及させた方がいいですよおー」
「でもそれプログラマ向けのソフトでしょ。使い方難しそうだし」
「慣れれば簡単ですよ。それにドキュメントの履歴管理にも便利なんです」
「バックアップで十分じゃないの？」
「いえ、過去にコミットした状態に自由に戻せるんですよ、ほら」
「なるほどねー、あれ？ でもファイルのタイムスタンプは今の時点だよ？」
「そりゃそうです。タイムスタンプが戻った方がいいなんてどシロウトの発想ですよ。
そもそもタイムスタンプとファイルの中身になんの関係があるんですか？ 説明
できますか？ 頭悪いんですか？
「・・・お前、Gitを推奨ツールにする案は却下な」 >>541
今でさえいい加減多機能すぎなのに、タイムスタンプを戻すスイッチのオプションが増える
ことが「機能盛り込みすぎ」と言えるだろうか？ バックアップからコピーしても
ファイルが入っているフォルダの更新日時や
ファイルの作成日時は変わってしまうじゃん。 >「Gitを部内で普及させた方がいいですよおー」
>「慣れれば簡単ですよ。それにドキュメントの履歴管理にも便利なんです」
gitにタイムスタンプ保持の機能を欲しがっている阿呆の話か？ >>539
話は簡単。
ファイルのハッシュを使ったほうが完璧だが、
それはタイムスタンプを戻す理由にはならない。 信者が納品にまでgitを使わすことを強制しててワロタ >>548
git archiveといって、納品とかに使える機能すら
gitは用意してくれているよ。
そういう意味ね。納品にgit強制＝git archiveを使う あ、一応説明しておくか。
単にファイルをコピーとかすると、
作業中のファイルとか納品に必要のないものが
間違って入ってしまう可能性がある。
git archiveだと本当に納品するものだけを入れられる。 知らんけど
そんな前時代的な会社は辞めたらいいんじゃない？ >>534
タイムスタンプにだけ依存してるツールと
最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
Bazelはファイルシステムでハッシュ持ってる場合はハッシュ比較を先にしてmtimeの比較はしない
mtimeで比較する場合もその後ハッシュで比較する
Google内部ではカスタマイズしたファイルシステムを使ってハッシュを保存してるからタイムスタンプに依存しない
>>525-528
この辺のやつは既存の慣習や制約の枠内でしか物事を捉えられない脳みそだから
タイムスタンプ君と同類 いい反面教師 >>552
デタラメばかり言ってんじゃねえよ
だいたいファイルの内容量のハッシュを保持するファイルシステムがどこにあんだよ >>552
> 最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
一緒にしてないぞ？
最適化のためにタイムスタンプは、コミット日時ではなく
最後に変更した日時になるべきだって話をしてる >>553
内容量？
Googleが使ってるのはクローズドソースだよ
>>554
は？
タイムスタンプ君？ >>555
ファイル内容のハッシュを
そんなファイルシステムがGoogle社内に存在しているという根拠ぐらい貼れよ ソースを管理するためじゃなくてgitを使うためにgitを使う信者が、
たかがタイムスタンプすら保持できないという話を出されただけで
こんなにも必死なのはなんで？やっぱ図星だから？ >>557
そんな話をしてる奴居るか？
ちなみに俺は一度もgitの話なんてしてない。スレ違いのビルドツールの話をしてるぞ gitは完璧である
gitに現在ない機能を欲しがる奴は絶対にそいつが間違ってる
ﾌｧﾋﾞｮｰﾝ
って思考なんじゃね >>555
> は？
> タイムスタンプ君？
なんだそりゃｗ
反論の一つも言えなかったのかよｗ >>559
マヌケだなｗ
こちとらgitはソースコードのバージョンを管理するためのツールで
バックアップソフトが欲しければ、そっち使えという、
すごく当たり前の前提において、
ソースコードのバージョン管理ソフトはどうあるべきかを語っているだけなのに、
そうか。あのバカ、gitをバックアップソフトだと思っていて、
gitにないものは、gitの機能不足だと思ってるんだ。 >>557
> たかがタイムスタンプすら保持できないという話を出されただけで
タイムスタンプを保持しないのがバージョン管理ソフトとして
正常な動きですからね。 >>543
タイムスタンプを戻すのはバージョン管理とは関係ないから盛り込み過ぎだな 必死な人っていうのは、
論理的な説明ができない人だからね。
俺がいるって言ったらいるんだ！みたいなの まあ本当に必要だと思うなら git コミュニティーに投稿すりゃいい話ではある。
こんなとこでアピールするよりかは実際に入る可能性もあるんじゃないの？
あくまで本当に必要ならばだけど。 >>566
昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
絶対に入れることはない。とピシャリと言い放ったからな。
ここで愚痴るしかないだろうさｗ bazelは「同じ」ソースファイルからは「同じ」成果物が生成されて、
その再生成の必要性を徹底的にゼロにしようって意図を持って設計されてるのかな
そのために、この「同じ」にはタイムスタンプがなるべく関係しないようにしたいという感じなのか
ブランチの切り替えでmtime更新されて再ビルドが動くとかとは発想がまったく違う原理で動くわけだな
ブランチ切り替えたときにはすでにビルド済みの成果物がそこにある
bazelのドキュメントちょっと読んだだけで書いてるから真偽は不明だぞ信じるな タイムスタンプ比較した方が早いのに「ビルド時に毎回ハッシュ計算するからタイムスタンプ戻せ」って
タイムスタンプ信者が暴れてるんだろ？
ありえね〜 ファイルのビルド依存関係は完全に把握していることが前提で、
最初にファイルの更新を検知(これはタイムスタンプとかIDEから教えてもらうのかな？)すると
その依存関係にしたがって必要な部分を再ビルドしていくみたいな感じか >>568
> そのために、この「同じ」にはタイムスタンプがなるべく関係しないようにしたいという感じなのか
違う。bazelでもタイムスタンプが違えば違うとみなすが、
それに加えてファイルの中身まで見てるってことだよ タイムスタンプが違ったら違うかも？って判定して、
その後中身見て違うかどうかを確定するってことだよね？ ビルドを最小限にするにはタイムスタンプの違いだけでビルド開始してたら話にならんし
あと成果物にタイムスタンプ由来の情報が入るのが嫌なんだよね gitにタイムスタンプを入れるな派はソースファイルを考えていて
入れろ派はdiffで差分確認出来ないファイルを考えているんだよね?
Git LFSだけファイルのタイムスタンプを保存するようにして、
ファイル種別でGit LFSに入れる運用にすれば両方満足するのでは? >>567
>昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
>タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
>入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
>タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
>絶対に入れることはない。とピシャリと言い放ったからな。
それ単にリーナスの尻馬に乗って俺スゲエって言いたいだけちゃうかと
少なくとも「間違い」とか「正しい」なんて言えないだろ タイムスタンプ入れろ派も（上見ればわかるけど）それをデフォルトの動作にしてよみたい
なことは入ってないんだよね。”-t”オプションつけたらぐらいでしょ。 >>575
なんでそんなすぐバレる嘘つき続けるんだ？
それ単にFUSEを通してバージョン管理システムにアクセスするだけでファイルシステムじゃないじゃねえか。
これがファイルシステムだと主張するならgmailすらファイルシステムと言えるわ ぶっちゃけdiffしか見なくね？
いつ更新されたかとかどうでもいいわけで、何を更新しようと試みたかの内容が重要 >>574
> 入れろ派はdiffで差分確認出来ないファイルを考えているんだよね?
何も考えてないだろｗ
その証拠にタイムスタンプを入れることで
どんな問題が解決するのかを言えていない で、タイムスタンプ信者は何でタイムスタンプ入れたがるの？ さんざん上で出てんじゃん
もう引っ込みがつかないの？
みっともねーやつだ 出てなかったはずだが？
上で出てるっていうのなら、
指し示すことができるはずだよね あくまでソフトウェア開発の道具としてgitを使う層と、gitを使うのが趣味でそのために適当なテキストファイルを書いている層とがいるから話が噛み合わないんだよな 開発の道具（道具だから開発時に使う）のと
バックアップ（裏で勝手に取っていてくれれば嬉しいだけの人）との
違いだね >>588
適当なテキストファイルを書いてるとタイムスタンプがどう役に立つんだ？ >>591
>>592
え？じゃあソフトウェア開発にタイムスタンプ(を戻す機能)がどう役にたつんだよ 同じ意見同士で喧嘩すんな。
gitで管理してれば、行ごとに更新日時が記録される。
タイムスタンプ以上の正確な情報が記録されてるのに
わざわざタイムスタンプという人それぞれ違うようなものを
保持する意味がないことぐらい常識じゃないか >>594
お前とは同じ意見だけど、
>>591と>>592と同じ意見とは思えないけど なんで実装するべきかそうじゃないかで喧嘩が始まってしまうのか理解できない
実装するべきかどうかなのは置いといて、hookでなんとかできる可能性あるんだから必要だったらその方法を議論すればいいのに。
現状ではgitには実装されそうにない機能だという事実を一旦受け入れて。
それとは並行して実装するべきかどうかについて話すのは勝手にすればいいと思うけど
hookで試してみたけど上手く行かなかった、とか、hookではどうしても解決できない問題が発生するとか、そういう話が出来るはずだろ。 >>596
自分で作るという話ならば、hookでやる方法なんてすぐに思いつくので議論の余地はない >>597
hookで実現するかどうかを議論するということではなく、もし、タイムスタンプの管理が必要なのに自分でhookを書けない人が居るんだとしたら、
素直にどういうふうにhookを書けばいいか相談するなり何なりすればいいのにね、ってこと。
自分にとって必要なのに機能がない、に対して
1. ツールを工夫して使って代替する方法を考える、相談する
2. 他のツールを探す
3. ツールに追加機能を実装して採用してもらう
4. 機能がないことを盾にそのツールを頭ごなしに否定する
あたりの選択肢があるっぽいけど、どうして最も建設的でない4を採用する奴がいるのかな？って思っただけ >>596
建設的な議論をしたいんじゃなくて
ただたんに文句言いたいだけだからな。
少なくとも
git タイムスタンプ
とかでググればけっこうやり方はでてくるよ。 エクスポート時に全部同じ日時になるのって
svnもそういう仕様じゃん？ >>599
gitのhookで解決する方法がググれば出てくるのに、それでもなにか言いたいんだとしたらhookを使うことには実務上の問題があるのか、
ググって出てきたやり方には欠陥があるのか、何かしらググった結果では満足できない合理的な理由があるんだと思ったんだけどな。
嗜好品だったらともかく、実用品を実用上の問題以外で批判することが、その人にとってどういう嬉しさをもたらすのか全くわかんないわ。 >>601
この辺でも読んでみれば？
少しはヒントになると思うよ。
ttp://qiita.com/hirokidaichi/items/adccebb41f77eaa6132f いちゃもんつけられる俺スゲー君はどこにでもいるから 長文アスペ信者君を弄って遊びたい奴が一人か二人いて、
そいつらがネタを蒸し返してるだけだからあんま相手にするな >>602
ということは、タイムスタンプで管理することを仕事かなんかで強制させられて、諦めてそれに従うんじゃなくて、タイムスタンプに意味があるんだ！なんとなくだけど！って思い込んでる人がいるってことかな
言語の話なら一長一短あるだろうし具体的にこの機能はこんなに素晴らしい！とか指摘できると思うんだけど、タイムスタンプ管理のメリットってのが全然語られないし、
むしろ、メリットデメリットで主張してるのではなく、そう決まってるから従わざるを得ないというところを有耶無耶にしているような印象があるんだよな。
まぁ、>>604の言うようにバイナリかタイムスタンプネタで遊びたいやつが居るだけの可能性も高そうだけど。 単純にタイムスタンプっていうのは、ファイルを最後に変更した時間なんだから
checkoutすることで変更したのならば、その時刻になるのが正しいんだよ >>607
そのファイルをその内容に変更した時刻のことだよ。
Windowsでファイルをコピーしたことない？
タイムスタンプも一緒にコピーされる意味を考えてみようよ あと、「makeがタイムスタンプを参照するから」 という回答もおかしいよね。
思い切り自己矛盾を抱えている
『makeは、ファイルの更新日付なんか参照せず、ファイルの変更を検知すべきだ』 WindowsでもLunixでもMacでも
タイムスタンプを維持したままコピーするかどうかは選択の問題
常に維持されるのが当然っていう考え方はナイーブすぎ
makeはそういうもんだしgitから見たらコントロール外にある仕様だから
自己矛盾でもなんでもない
今後はbazelのようにコンテンツベースのビルドツールも増えてくるだろうし
gitに保存されてるハッシュを利用するようなものも出てくるだろうね
でもそれとgitがタイムスタンプを復元する機能を持つべきかどうかは関係ない gitがタイムスタンプを復元すると言うのは
・コミットした時のファイルのタイムスタンプをファイルのコンテンツに含める
・チェックアウトした時にファイルのタイムスタンプをコミット時刻に変更する
の二つが考えられる。
前者は、ファイルのタイムスタンプを変更しただけで別のファイルとみなすと言う意味だ。そういう仕様にすると、相当使い辛くなることが容易に想像できる。
例えば、一回編集したファイルを元に戻すのに必ずgitのコマンドを使わなければならなくなる。
後者は、ブランチを一度でもリベースするもコミット時刻には意味が無くなるので何を管理したいのか分からなくなる。 まぁひとつだけ言えるのは、git cloneでコミット時刻が復元されたら俺はうれしいってことかな。 >>612
bazelがファイルの内容を”その”ファイルシステムの変更検知に使うなんてどこにも書いてないんだけど、嘘つきに騙されちゃったの？それとも本人？ あーgitにタイムスタンプ復元機能があれば完璧なのにー gitがタイムスタンプを保存しないのは
「vcsはタイムスタンプを保存しないのが正しい動作」
と言っちゃうような馬鹿が至る所で巻きおこす問題の嵐を避ける為
リーナスは非常に賢明な判断をしたことがこのスレを見ているとよく分かるw >>610
> 『makeは、ファイルの更新日付なんか参照せず、ファイルの変更を検知すべきだ』
ファイルの変更を検知するためには、変更前のファイル情報を持ってないとダメでしょｗ >>609
> Windowsでファイルをコピーしたことない？
いまコピーの話はしてない。
同じ名前で内容を変えた場合の話をしている 内容を変えたのであれば、内容を変えた日時になるのは当然でしょｗ
今ファイルの内容を変えたのに、昔の日時になるのはおかしいｗｗｗ >>621
変更前のファイル情報を持ってるツール使ってないのww >>624
最初から、更新前のファイル情報がないツール前提の話でしょ？ >>623
じゃあ内容を戻したら、日付も戻せよ
という話でしてね ふう、gitにタイムスタンプ復元機能があれば完璧なのにー >>629
gitは内容を戻すことは出来ない。
任意のコミットをcheckoutするだけ では僭越ながら
ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？ はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？ 他の人はネタでバカ言ってるけど
>>634だけ普通のバカだな・・・ いや、流石にsvnでもタイムスタンプは戻せん。
コミット時刻になら設定次第だけど戻せるけど、そこもgitと同じ。 タイムスタンプ機能があればいいのに、ライナスも意地になっちゃったんだろうな 澁谷 恭正 (46歳)
千葉県立沼南高柳高等学校卒
松戸市立六実第二小学校PTA会長
小学女子レイプ殺人で逮捕
お住まい：
千葉県松戸市六実4-8-1 Mシャトレ
お子さん：
ひりゅう、あやか ※父子家庭
趣味傾向：
アニオタ 死ぬまでには出来るだろうと思ってずっと待ってると先に死んでしまう 時間は不可逆だって時をかける少女で言ってた
つまりタイムスタンプが戻らないgitは正しい 伸びたら洗うの面倒だし、髪切るのもただじゃないし時間もかかるし、夏は暑いし、ない方が楽じゃね？ gitでタイムスタンプを戻すことが出来るようになる時間線では、さらに遠い未来ではgitで時間を戻せるようになるまで拡張される。
タイムマシンで過去を改変することが可能な世界では、タイムマシンで過去を改変出来ない世界になるまで永久に時間改変を繰り返し、最終的にはタイムマシンが開発されない世界に収束する。
以上のことから、gitでタイムスタンプを戻せる世界は、実現しない。 オカルトって、初っぱなの論理の飛躍に気づかないと、
そんなもんかなって思ってしまうよね。 Gitは最近やったコミットの改変、つまり歴史改変ができるじゃん
コミットの入れ替えも可能だからコミット一覧で
日時が未来のコミットが下の方にあったりとか良くある ﾌﾟﾚﾐｱ見れない
ﾌﾞﾝﾃﾞｽ見れない
CLEL見れない
代表も見れねえちきしょう
結果知らされて見れねえちきしょうクソったれ同和のクソ野郎地獄へ落ちろ
音楽聞けねえちきしょう
テレビ見れねえちきしょう
オシムは考えて走るサッカー
アンデションズはよく(十分に)考えて(タイミング計って)車のドア閉めて車(バイク)で通る嫌がらせ
同和のクズ共死ねクソ共がざまあみろ気違い共
ほれ気違い共もっともっとドア閉めろ通れ
それしか能のない能無し共がざまあみろ地獄に落ちろ。悔しいか、ざまあみろくたばれクソ同和
お前らの恐ろしさをもっと見せてみろ。そんなんじゃなんともねえぞ
袋とじ見たぞ。悔しいか、ざまあみろくたばれクソ同和
生きる権利もねえクズ共が藁地獄へ落ちろ
嫌がらせがエスカレートするのが楽しみでしょうがない。今それだけが楽しみだ。俺の生き甲斐藁。それだけ怒ってるってことだもんな藁
ラブホ行ったのがそんなに悔しいかざまあみろチンカス共が藁。思う存分楽しんでくるぞあばよ
椎名茉莉、知っちゃったよ。ラブホに来なければ知らなかったはずだけどな。サンキューお前ら藁
超美形。嬉しくてたまらん。お前らどうしてくれる？藁ほれ赤字分を取り返すために必死になれ
ピザ食ったぞ。羨ましいだろう？藁ざまあみろ
音楽聞いたぞざまあみろ
非人が美人
お前ら音楽聞かせてくれてサンキュー。それもお前らがドア閉めて通ってくれたおかげだ
テレビも見たぞざまあみろ
同和の悪口書けば書くほどドア閉めるってことは嫌がらせしてるのは同和だって証だ
とにかくドア閉めるクソ同和藁(とにかく明るい安村風)
深谷市東方の西と高橋か死ね
サッカーの動画見たぞざまあみろ
気違いなのを常識化させるのが集ストの狙い。多いほうが正しいと考える日本人に漬け込んだわけだ。例え悪いことしてても多いんだから正しいと錯覚するように。上手く法律の盲点を突いた嫌がらせだな。法律で取り締まれないことをイイことにやりたい放題
ラルクがライブやるのが悔しいかざまあみろ
メル友出来たぞざまあみろ悔しがれクソ野郎共藁 すいません。分からないので教えてください。
githubでプルリクを送って、まだマージされてない状態で
そのプルリクのコミットの上に、別のコミットを積んで別のプルリクを作成した場合に、
後者のプルリクのFile Changedの中に最初のプルリクの修正分も表示されてしまうんですが、
後者の修正分だけ表示されるようにするにはどうしたらいいですか。
未マージのプルリクを前提としてコミットを積んでいった場合のプルリクはどうするのが正しいんでしょうか。 >>671
その方法ほしいよな。マージの順番に依存関係をもたせたい プルリクがマージされるまでは、そのプルリクのコミットを前提にしたコミットはプッシュしたら駄目なんでしょうか。 プルリク出した修正や追加を前提としたプルリクは最初のプルリクがリジェクトされたときに同時にダメになるわけだからよくない。 先のプルリクがマージされたら、後のプルリクのFile Changedが変わるかと思ったけど変わらなかった
pullしてマージしてpushし直したら後のプルリクのFile Changedだけの表示になった
gitてむつかしい >>676
じゃあもうプルリクがマージされるまで手元に大事に置いておかないと駄目なんすね いや全然違う部分の修正なのでコミットは分けたい
開発初期段階なのにレビュー必須になってるから糞面倒臭い 違うけど先のプルリクの内容がないと成り立たない内容
開発初期段階なので
ていうか起動画面があって、その次の画面を作るとして
起動画面のコードが入らないと次の画面が出せない
起動画面と次の画面の開発はプルリク分けるべきでしょどう考えても
レビュー必須ｔっていうのも考え物じゃないんか プルリクしたのに反応がありません。
どうしたらいいですか >>682
レビューが100%通ると仮定して、自分のリポジトリに対してどんどん作業を進めれば良いじゃ無いか
プルリクは一度に一つずつ作成して、それが通ってから次のコミットを使って次のプルリクを作る
多分問題はレビュー必須であることじゃなくて、プルリクを受け付けてもらえないと何か出来ないことがあるせいなんじゃ無いかな？ ブロッカーになってるレビュアーに仕事しろって言うだけでいいだろ ファイルの所有者情報がgitに保存されないんだけどなんで？ >>690
そんなくだらない情報をGit様は保存しない >>694
ファイルの日時が保存されないのはmakeを使う人用の制限で
しかたないと聞いたことがあるけどowner情報すらなくなるのは
ちょっと不便でしょう？ >>695
例えばOSがLinuxだとして、そのサーバに存在しないユーザがownerだとして、fetch/pullしたときにどうなるのを期待してるの？ >>697
存在しないownerなら別にそのままでいいんじゃね？
その程度の矛盾は臨機応変に対応すればいいよ こういうのにアドホックに対応するのやめようぜ
「〇〇の情報がgitでは管理されない。具体的にこれこれこういう状況で困る。解決策はないか」だったら考えようがあるからOKだけど、
「〇〇の情報が保存されない。なんで？臨機応変にやればいいのに」とかって言うのは自分の抱えている問題がなんなのか明確になってないのに
思いつきで色々注文付けてくる発注者と一緒で相手すると時間を無限に消費されるだろ
>>698
ということで、困ってるならどういう状況で困ってるのか説明してくれない？困ってないなら保存されなかろうがどうでもいいよね そうだよ。Windowsだと所有者は世界で唯一のUUIDになる
だから個人を特定できる そういやさ、githubでブラウザからマージする時の
名前/メールアドレスって変更できないの？ あなたがコミットしたのだから、そのコミットの所有権はあなたに有ります
あなたがチェックアウトしたのだから、そのコミットの所有権をあなたに移すことが出来るようになります
ファイルシステムでの所有権？
それはあなたが使ってるファイルシステムに要望してください 所有者情報ってのはOSで管理されてるものだからそういうのはgitは見てないんじゃないの
バイナリエディタでファイル開いても所有者情報とか編集日時とか格納されてないでしょ 例えば所有者情報を、特定の誰かにしてしまえば
意図的にそのユーザーのデータを壊せるでしょ？
便利じゃね？ >>706
例えばtarで圧縮したときはファイルの日付や所有者まで全部保存される
WindowsでもLinuxでもね
ファイルの中身と同じくらい重要な情報で、だからきちんと管理されてる
いらないってんなら全部Cドライブ直下にでも/直下にでもずらりと置けばいい >>706
あとね、バイナリエディタでファイル開いてもファイル名とか格納されていないよ
だから格納されてるされてないで重要度は判断はできない >>708
だからtarを使えば良いのでは？
ソースコードのバージョン管理をしたい時に
tar使っても過去の履歴がないのは、tarの機能が低いんじゃなくて
アーカイブツールだから。専用のソフトを使うのが一番適切 所有者やアクセス権整理するスクリプト書いて一緒にコミット汁 >>708
Linux で作成して Windows で展開しても所有者が保存される？ >>708
/直下にファイルをずらずら置いておいても困らない例なんていくらでもあるけど
Gitを何に使いたいのかな？具体的な利用方法を言ってみてよ
他のツールでできることがGitでは出来ない、ではなく、ユースケースで言ってみて
言えないならさようなら tarでファイルに他人に所有権のファイルが有った時、
自分のホームディレクトリ以下に展開した時
他人のファイルが出来ちゃうの？
それって危険だよね。tarの脆弱性か tarはファイルの所有者情報を記録するけど
普通は、展開するときに所有権情報まで一緒に展開しない
展開したユーザの所有権で展開される
システム管理者がスーパーユーザ権限で作業するときぐらいだよ
記録された所有者情報を使うのは >>714
なんのためにディレクトリがあるのかわかってる？
gitはディレクトリ情報は保存するぞ >>718
そうやって煽ってもいい加減つまんないぞ タイムスタンプと寸分違わず同じ流れでよく飽きませんね そういうことに、したいのですね。
ヘ＿ヘ
ミ・・ ミ
（ ）〜 あさから よかいち error: The branch 'void' is not fully merged.
If you are sure you want to delete it, run 'git branch -D void'. rebaseして失敗したら追加したファイル全部なくなったんですが、復旧できないですか？ rebase --abortすりゃいいだろ
すげー楽だよ。gitは失敗が怖くない。 >>698
例えば、creatorがWindowsユーザだったらどうすんの？ どうすんの？じゃなくて、なんですんの？を誰も言わない所が共通してるね。 そうだね
タイムスタンプはどうでもいいけど
アクセス権は元に戻ってほしい ownerとpermissionをごっちゃにしてるんすかね >>738
所有者を復元するという事の何を知りたいの？実装方法？手段が目的な人？ 「どうしてそうしたいの？」とやたらに理由聞きたがる人が出てくるけど
彼らはなにがしたいんだろうか。
第三者が理由を聞きたがる理由がわからない >>741
何言ってるんでしょう、この人
誰も目的を聞かないというから、目的は明確でしょうと言ってるのに そんなことしても何の役にも立たないのになんでやりたがるんだ？
って言うのをちょっとオブラートに包んだだけだろｗ >>743
「〇〇の機能が欲しい」というのは、大抵「□□という差し迫ったシチュエーションで問題を解決したいから、〇〇の機能が欲しい」という形に言い直せて、
そして、「□□での問題解決するには、実は〇〇という機能でなく△△という機能を使ったほうがもっと良い」ということが往々にしてあるから。
というか、「〇〇の機能」の実装にあたって、実際には〇〇の機能をただ追加するだけじゃ済まなくて、既存の☆☆機能との整合性はどうするか、とかそういう部分も考えなくちゃいけないから、
仮に新機能を実装するとしても、「どうしてそうしたいの？」という問いは重要であろう
建築家が「トイレが10個ある家にして」と注文されたら、どうして10個必要なのか聞くでしょ。そして理由によって10個をどのように配置するか、トイレの内装なり便器なりを細かく決めていくでしょ。
それと同じことだよ。
自分にとっては自明だと思っているのかもしれないが、普通にどういう状況でその機能が欲しいかわからないから聞いているだけなんだけどな。
Gitはファイルシステムとかアーカイバ、バックアップツールとしてデザインされているわけじゃないから、それらの代替として使おうとしたら色々問題があって当たり前
それでもGitを使いたいんだとすれば、それらの用途にGitを使う意味を何か見出しているんだと思うんだけど、そこをどういう風に把握しているのかわからなければ解決策も考えられないよ
Git以外のもっと便利なツールを紹介できるかもしれないし。
Git含めどんなツールも銀の弾丸ではないんだからあらゆるものにケチつけようと思えばケチ付けられるわけで。だけどそれは生産的な行為だとは思えない。 >>747
gitが本気で便利なら３行でまとまるはず > gitが本気で便利なら３行でまとまるはず
どういう理屈で？ >>747
ファイルごとに履歴を先頭まで遡れば誰がaddしたのかわかるわけで、家にトイレ10個レベルの違和感わない >>747
ケチをつけずに質問にだけ答えろよ
お前の方が口先ばかりで生産性無いぜ >>751
マージした内容は行単位で辿れるのに所有権はファイル単位なのは整合性が取らなくないか？
またgitのlogはファイルの履歴ではなくファイルの内容の履歴を追う
この機能ともファイルの所有権の管理はそぐわない >>752
第三者が理由を知りたがるのは何故か？という質問に見事に答えてるだろ >>754
> またgitのlogはファイルの履歴ではなくファイルの内容の履歴を追う
git logでは"Author"が表示されるが？
> この機能ともファイルの所有権の管理はそぐわない
管理しようという話じゃない
念のため言っておくが、「ファイルの所有権」の定義の話をしたいわけでもないぞ
git commitの日付を復元したいとか、ファイルの最終更新日を復元したいとかいろいろ
人によって異なるだろうが、それは単にそれを知りたいからだ
なんで人がそうしたいのか、お前の好奇心を満たさなきゃらなないんだ？ >>757
そのAuthorはファイルの所有者じゃないだろう >>758
えーと、git cloneしたら、ファイルの「所有者」は自分になるとかそういうこと言いたいんでしょうか
そういうつまんない議論したくないんですが >>759
git log で表示されるauthorはファイルのownerでは無くて
コミットした人のconfigで設定されていたauthorが表示されますよね？ >>759
ファイルの所有者の話から始まっているんですよ
口をはさむなら最初から読んでください >>761
おまえファイルの内容の履歴の意味がわかってないだろ >>757
git blame
してごらん
各行毎にどのコミットに由来するかが表示される
gitにとってコミットが責任の単位なんだよ >>339
重い
調べたらgitkrakenっていう別ソフトがあるのでこれから試してみる
https://www.gitkraken.com SourceTree2.0になって軽くなったんじゃなかったっけ バージョン管理で重要なのはファイルの所有者じゃなくて
コミットした内容の所有者というか修正者である。
そのソースコードを誰にあげましたとかいらない。
誰が修正しましたかが重要。しかもメールアドレス付きでね。
重要ならば署名までつけられるしすごいことだよ。
という事で話は終わりじゃね？ >>767
運用によるgit flowとかgithub flowとかでググれ >>757
好奇心ではない、適切な解決策を見つけるために理由を聞いているのだ、と明確に書いたつもりなのだけども。
所有者を保存しておきたい理由が一般的なソースコードのバージョン管理の必要性からはわからず、なぜ保存したいのかわからなければ適切な解決策が提案できないとも書いているんだけども
目的の為に手段を考えるべきで、所有者の保存というのは手段にすぎない。そしてその手段は特にソースコードのバージョン管理を行うという観点からして素直に実装できるものではない。
その目的が「人によって異なる」時点で適切な設計を定義するのが難しくなるだろ。ツールの機能として実装するには、どんな人でも大抵同じ理由でその機能が欲しい、とならなければ細部まで設計できない。 sidやuidのことなら、それはマルチユーザー環境やファイルサーバーなんかでアクセス制御に関連して備わっているもなので、趣旨の異なるgitで保持してもゴミ情報
単なる数字列を見て何ができるんだか >>766
で問題解決したようですね。
バージョン管理で重要なのはファイルの所有者じゃなくて
コミットした内容の所有者というか修正者である。 rebaseが強力すぎて、昨日は1日中コミットコメントの修正やってたわ 誰がコミットしたファイルか
なんて情報は開発中にしか使わないでしょ？
デプロイ時にはパーミッションや所有者情報のほうがずっと大事だし
それらがいつよ間にか黙って消えて無くなるのは辛いことだよ >>777
所有者とパーミッションは設定スクリプトを書けばいい Unixじゃパーミッションやグループやオーナはデプロイ時に設定するのが一般的だな
特にオーナとグループはデプロイするローカルな環境に依存していてパーミッションの効果に影響するから
ソース管理でファイルが保持している情報をそのままデプロイするとかありえん >>779
そのままデプロイするとかありえんって……
いつの時代の人なんですかね >>780
開発するときにはお前自身は書き込み可能なオーナーとパーミッションになってないと行けないけど、
それがデプロイされた環境でそのまま書き込み可能な状態になってたらクビだよお前 そういやどうして実行権限だけ保持できるようになってるんだろう >>783
そう言う風に作ってるから
git update-index --chmod=(+|-)x
なので指定できるのは実行権限だけ gitに代わる最強のソースコード管理システム作ってくれてもええんやで Git使い方入門
https://www.amazon.co.jp/dp/4863542178/
お前らが喧嘩している間にGit入門書の決定版が発売されていたな >>789
今更入門書なんかいらないよ
卒業編を持ってこい ファイルの属性が無くなるのは仕様？
setuidしてたやつが動かなくなっちまったぞ 俺スゲエ、って自慢したいだけのネタさがしで本当はだれもGitなんて興味ない ということにしたいんだけど、どう？うまくいったかな？ >>794
デフォルトの仕様ってことはわかった
設定で回避したいんだけど、どうしたらいい？ タイムスタンプはコミット時間で補完出来たけど
setuidの情報とかどこにもないから自分で保存して設定する仕組み作るしかないな setuidはデプロイするシステム側でつけるんじゃないの？ >>802
テスト環境では直接gitでモリモリしてたけど良くないのか？
めったにいじらないファイルだったから気づかなかった >>803
setuidの目的から考えると、gitの情報から復元するのは危険だろうね Windows上にリモートリポジトリ置いて、別PCにローカルリポジトリ（リモートのクローン）を置いたときに、
リモートへのpushができなくて困っています。
pull、fetchはできたのでパス設定は誤ってないのと思うのですが。。もし対処が分かる方いましたら教えてください。
------------------------------------------------------------------------------------
remote: error: object directory (リモートリポジトリ)/objects does not exist; check .git/objects/info/alternates.
remote: fatal: unresolved deltas left after unpacking
error: unpack failed: unpack-objects abnormal exit
To (リモートリポジトリ)
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to '(リモートリポジトリ)'
------------------------------------------------------------------------------------ 一部解決。
別PC上のgitをバージョン上げたら、TortoiseGitからのpushに成功しました。
が、VisualStudioからのpushができない。。 修正用にブランチを作成してから他人のリポジトリにプルリクエストしたんですけど
masterじゃなければpush -fしても大丈夫ですか？ push -fって、他の人が折角作ったリポジトリを破壊したいのか >>810
push -fするのは他人のリポジトリって言ってませんよね？
自分のリポジトリの自分のブランチですよ？
まったくgit初心者ってバレバレなんだから
無理してレスするな >>812
誤解されるような書き方をするほうが悪い 1日頑張ったけど解決しなかった。
わっかんねー。
>>811
Git for Windowsを許可しても、TCP9418を許可してもダメでした。 unpack failed: unpack-objects abnormal exit
でググったが分からんな .gitignore
task.php
password.txt
これら3つのファイルのみ管理したいんですが
initial commitしてから2回目以降からはpassword.txtの変更をgit add -Aとかでaddされたりコミットしないようにしたいんですけど
どうしたらいいのでしょうか？
毎回git add task.php .gitignoreみたいに手打ちするのが面倒くさいです .gitignoreに
*して
例外に
task.php
password.txt
入れろ .gitignoreの内容をこうするんですか
*
!task.php
!password.txt
でもこうするとpassword.txtを編集した時にpassword.txtもステージングされてしまいコミット対象になってしまいます .gitignoreに
password.txt
でいいんじゃないの >>817
git update-index --assume-unchanged [filepath] 週末に自宅でプログラミングしていくつかコミット作った後で、
月曜日に会社に出社してからコミットの日付を月曜日の時間に変えたいんですがどうしたらいいですか rebaseしてみましたが、sourcetreeだと、日時とコミットした...の二つが表示されていて、
日時の方に最初にコミットした時間が残っていますね。。 コマンドじゃなくてsourcetreeで簡単にできないんすかね 週末に作ったコミットと同じ内容のコミットを手作業でコーディングしていって新しくコミット作るしかないんでしょうか 環境がよくわからないのだけれど、別のディレクトリにgit cloneして、週末に作業した分で上書きしちゃえば良くない？
そもそも作業日時を偽装すんなって話だが 家からは別ブランチにプッシュしといて出社してから家でやったコミットをmasterにチェリーピックすればいいのでは cherry-pick もオプション無しだと元のコミットの AuthorDate を引き継ぐね
コマンドラインからなら -n 指定してそのあとコミットすれば更新されると思うけど
それなら rebase --ignore-date HEAD^ で書き換えたほうが早い >>831-832で思ったけど、戻りたいところまでgit reset --softで戻ってaddしてコミットし直しが一番簡単かな？
SourceTreeだけでもできるし git rebase -i HEAD~
pick->edit
vi README.md
git add README.md
git commit --amend
git rebase --continue 会社のソースコードを持ち出して自宅で作業してるってバレたら嫌じゃないっすか コミットログを改竄しないといけないなんて大変ですね もはや何の為のソース管理なのか分からんようになっとるなｗ gitで管理されていないソースセットがあるとします。
それをgitに取り込んでV1というタグを打ちます。
その後修正して完成します。これをV2とします。
V1とV2の差分をpatch形式で出すには
どういう方法をとると楽ですか？ なるほどありがとう。
一長一短感がありますが、いろいろ試してみます。 ヒカル TV出演「年間5億は稼ぐ勢いですね」
https://www.youtube.com/watch?v=G7qL6ftpets
第１回案件王ランキング！YouTuberで１番稼いでるのは誰だ！
https://www.youtube.com/watch?v=asF2wQ2xhjY&;t=61s
ユーチューバーの儲けのカラクリを徹底検証！
https://www.youtube.com/watch?v=FUSb4erJSXE&;t=504s
【給料公開】チャンネル登録者4万人突破記念！YouTuberの月収公開！
https://www.youtube.com/watch?v=Y7DAQ0RKilM&;t=326s
誰も言わないなら俺がYouTuberのギャラ相場を教えます
https://www.youtube.com/watch?v=E4q-vaQh2EQ&;t=118s
YouTuberになりたいのは馬鹿じゃない！YouTuberになる方法
https://www.youtube.com/watch?v=Fr0WXXZRMSQ
最高月収5000万円だとさ。年収じゃなくて「月収」な
おまえらもyoutubeに動画投稿したほうがいいぞ。副業にぴったしだ
やろうと思えばスマホがあればできるぞ
最低2年はやらないとここまではいかないだろうけど才能とアイデアと
企画力と継続力があればが大儲けできる可能性がなくもない
まだまだ他の職種に比べれば競争率は低いからオススメ
顔出したくないならラファエルみたいに仮面つければいい
ハロウィン用でいろいろな仮装マスク売ってるからオヌヌメ githubでマージされずにクローズされたプルリクを削除したいんですが、どうやったらいいでしょうか うちのプロジェクトにもそんなのあるわ
勝手にissue作って自己解決でcloseしやがった
スレ汚し >>848
方法がないっぽいけど、あったら誰か教えて。 >>849
そんなことで文句言われる方がかわいそう 間違ったcommitを消しちゃうかどうかって議論と通じるものがあるな。 >>853
作業履歴であれば残しておくべきだし、
アプリのバージョン履歴であればリリースしてないものは不要 わかばちゃんと学ぶGit使い方入門
を読んでいます。
コンフリクトの定義は何でしょうか？
上の本では、同じ行に同時に別々の修正が加えられたときに発生すると
書かれています。
オリジナルのファイル：
1 A
2 B
Xさんがオリジナルのファイルを以下のように修正。
1 A
2
3 B
Yさんがオリジナルのファイルを以下のように修正。
1 A
2 B
3 C
この場合 2行目および3行目が異なるため、コンフリクトが発生したことになるのでしょうか？
新しいファイルを以下のように更新すれば問題ないようにも思えます。
1 A
2 B
3 C というか、
同じ行に同時に別々の修正が加えられたときにコンフリクトが発生すると
したら、同時に複数人が同じ内容のファイルを修正なんてほぼ不可能で
あるように思えます。
ですので、コンフリクトの定義は、もっと柔軟なのではないかと思うのですが。 1 A
2 B
上のファイルをXさんが
1 A
2 C
3 B
と変更。
Yさんが、
1 A
2 B
3 D
と変更。
うーん。不可能なように思えます。 A
B
↓
A
C
という変更と
↓
A
D
という変更だよ >>856
(1)
1 A
2 B
3 C
なら、ダメ
Xの保存が先なら、Yは、この状態を取得し直して、
1 A
2
3 B
1 A
2
3 B
4 C
となるはず
とにかく、(1)には出来ないので、後の人は、やり直し。または、
1 A
2 B
まで戻して、Yが(1)の状態にして保存。
次に、Xが(1)を取得して、それを変更する >>857
3行のサンプルで考えたらそうだけど、実際ソースコードの変更をする場合は同じ行に同時に別々の修正が加えられることはあまりないと思うんだけども。
あるとしたら大抵はそもそも複数人での作業の段取り自体がまずいケースなんじゃないかな。 gitがタイムスタンプを更新してくれたおかげで
どのファイルをアップロードすればいいのか分からなくなった 更新されたファイル全部アップロードして問題があるならそれはgit以前の問題のような。 >>863-864
ある種のdeployツールとは相性悪いかもね makeはタイムスタンプが更新されたソースをビルド対象にすればいいし、デプロイも同じような
ものだと思うんだが。
「ある種のdeployツール」ってどんなのを想定しているんだろう。 自分がタイムスタンプ更新したくせにgitのせいと言い張る すいません。教えて下さい。
Windows 10のHyper-VにCentOS7を入れて、git 2.13.1とgit-lfs 2.1.1をインストールして、Smart HTTPを設定しました。
Git Bash (Windows 10 )から、git cloneやpushができるところまできたのですが、
リポジトリにgit lfs install、git lfs track、バイナリファイルを追加してpushすると、以下のメッセージが出ます。
batch response: Repository or object not found: http://[CentOS ip]/git/lfstest.git/info/lfs/objects/batch
Check that it exists and that you have proper sccess to it
何が原因考えられるでしょうか？
よろしくお願いします。 〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ またタイムスタンプの話の相手してくれよ
｀ヽ_つ ⊂ノ ひまなんだよ
ジタバタ タイムスタンプ復元機能は元々は将来的にgitに導入する予定だったけど
あまりにもクソクソうるさいタイムスタンプ厨にキレたリーナスが絶対に入れないと決めた gitがタイムスタンプを復元機能してくれたおかげで
どのファイルをアップロードすればいいのか分からなくなった make, maven, gradle などは、ファイルAが更新されていたら、
Aに依存している、ファイルBも更新・再コンパイルされる
それが、gitに反映されるから、おかしく感じる
Aしか更新していないのに、何で、Bも更新されているのか？ >>875-876
普通はバージョン管理するソースファイルとビルドで動更新されるファイルを区別して
後者は.gitignoreに登録してバージョン管理しないようにする
でもVisualStudioとかの糞は今だにこの二つの情報がひとつのファイルに共存してたりして、管理が難しかったりするけどね
そのためにgit update-indexとか使わねばならない config.hをリポジトリに入れるかどうかってのと同レベルの話と想像。 >>878-879
C#のResources.Designer.cs >>881
それは自動生成されるんだから
入れる必要ないでしょ >>883
消さなくていいだろ？
リポジトリ管理しなければいいだけ >>884
自分で編集したときにはコミットする必要がある
でも他人が編集した場合、その変更をpullしてきた後ビルドすると何故ファイルの内容が変更されてしまう
その変更はコミットすべきじゃない >>885
消すとビルドできなくなるってことは自動生成できないってことだろ？
そのファイルをリポジトリ管理しないと、cloneしたときに消した状態になるんだからビルドできないじゃん 普通にこの件でググると
https://stackoverflow.com/questions/22619935/resource-designer-cs-under-git
Resource.Designer.cs.in 作って手動コピーしろとか、
git update-index --assume-unchanged しろとでてくるんだが、
これ間違いなの？ >>888
読んだけど本質的にバージョン管理しないのと何が違うの？ >>889
バージョン管理されてないと、cloneしてビルドができない タイムスタンプの件は
gitの使用を強制されているのでなければ他のツールを使うことを勧めたいところだが
そういうことに適した他のツールを知らないので何一つ勧めることができず申し訳ない FTPでソースコードをサーバーにアップロードしました。
今までは日付が新しいものだけアップロードしていればよかったんです。
でもあるとき古いバージョンに戻したいと言われました。
どうすればいいでしょうか！
gitにタイムスタンプが保存されていれば
こんなこと悩まなくて住んだのに・・・ >>892
古いバージョンのブランチをcheckoutして
日付の新しくなったファイルをアップロードすればいい という話に持っていくにはどうすればいいっすかね？
gitにタイムスタンプが保存されていれば
問題が解決するというロジックが思いつかんのですよ。
普通に考えればgitでチェックアウトしても内容が変わらければ
日付は変わらないし、変わってしまったとしても、新しいとか古いとか関係なく
変わったものだけアップロードすればいいだけですし >>893
あ、さーせんｗ
こんな時間にこんなに早くレスくると思ってなかったっす
トイレ言ってる間に書き込まれたけど、>>894が本当に言いたかったことっすｗ >>893
> 古いバージョンのブランチをcheckoutして
> 日付の新しくなったファイルをアップロードすればいい
gitにタイムスタンプを入れたら、古い日付になるじゃないですか！ >>886>>887
csprojに適切な設定(デフォルト)がされていればビルド時に生成されるはず。
生成されたファイルには「手で編集すんな」って注意書きがある。
>>888
Xamarinの人は自動生成できないからResources.designer.csをリポジトリに入れたら困った。
って話じゃないの？Xamarin知らんから想像だけど。 >>897
なるほどXamarineの場合にだめなのか
C#はXamarineしかやってないから勘違いしてた
糞なのはXamarineなのな MSも csproj とかはわりとマージしやすくなってちょっと Git フレンドリーになったと思ったけど
Xamarinの Resources.designer.cs はダメだな
レイアウト変更で直接 Resources.designer.cs を編集するんじゃなくて
別のxmlファイルでも編集するようにして
ビルド時にそれから Resources.designer.cs を生成してくれるようになれば管理しやすくなるのだが gitでメタ情報の差分を見る方法を教えてください
パーミッションが違うっぽいんだけど、どう違うかがわかりません
ファイルの内容は同一です >>902
$ git diff HEAD^1
diff --git a/hoge b/hoge
old mode 100644
new mode 100755 要するにメルカリで情報流出させるようなDeployしてるのか君らは 特定の拡張子を除いてpullする方法、もしくは特定の拡張子だけpullする方法はありますか？
.dbや.logファイルで毎回コンフリクトが起こるので、.dbや.logを除いてpullしたいです 自分用のgitignoreに＊.db,＊.logを登録する すでにレポジトリ管理化にあるファイルはgitignoreに入れても意味ないんやで
なので git update-index なんてものがある
http://qiita.com/usamik26/items/56d0d3ba7a1300625f92 何で中途半端にﾜｯﾁｮｲしてんだよ
次スレからIDも表示させようぜ gitlabのmerge requestをsource treeでダウンロードしたいんですがどうしたらいいですか サーバー側のバージョンをクライアントから知るコマンドってある？ >>916
サーバへの接続手段にsshを使ってるんだったらわかる git のフローを保つために、間違ったコミットしたりすると物凄く時間をかけて正しくするんだけど、時間の無駄としか思えない。
どこもこういうもの？ >>919
「さっきの間違ってたので訂正」 というコミットをしろ。
間違いをなかったことにするな。 絶対にだ 読む時のノイズにしかならない
汚いコミットログを残す方が悪 テストがあれば汚いコミットログは不要かな。
テストがなければそのまんま。 何のためにコミットログを残すか考えれば自ずと答えは出る
レビューのためならレビューアが見やすいように整えるべきだし、自分の為だけなら最低限でも構わない
単なる自己満足ならそれこそ気が済むまでやれば良い >>923
間違ってないコミットを間違って修正する可能性がある方が悪だよ
言うまでもないことだけど >>922
それはmasterとか継続的に共有するブランチの話だろ。
逆に、masterにマージするならきれいにしてから持って来い。 2.13.3 と 2.14 が立て続けに出そうな予感 >>934
今頃どしたの？ ｗ
いくらなんでも情弱すぎでしょｗｗｗ あるファイルいっこだけブランチする ってことはできないの？ 2.13.4 が出る模様。
2.14 も、そろそろ出る模様。 git checkout ref/tags/タグの名前
これで作ったブランチのソースコードをコンパイルするとmasterブランチのときよりもコンパイル時間が約２倍伸びるようになったんですがこういうものですか？ gcc にパッチ投げようと
git clone --depth 1 git://gcc.gnu.org/git/gcc.git
したけどクソ重いでやんす
sparce-checkout も試してみたけどこれ fetch はツリー全部 fetch してるのかな？
効果があるように思えない
subtree だけ clone する方法ってないもんですかね >>939
既存のブランチからヒストリがそのファイルしか含まないブランチを作りたいなら
git filter-branch --tree-filter "find -not -name hoge -print0 | xargs -0 rm"
でできるけどそういうことでなく？ masterにマージの終わったブランチを
適宜リポジトリから消していっています。
メンバーのローカルにあったブランチが再プッシュされて
消したブランチが復活してしまったのですが
運用としておかしいですかね？ そのメンバーがmaster以外のブランチをpushしてるのが悪いので責任とらせて消させれば良い。
面倒で気をつけるようになる。 >>953
ありがとうございます。
運用考えます。 別に運用問題ないと思うんだけど。
単に間違ってpushしたってだけでしょ？
マージ済みなんだから、マージされてるってことはわかるし Git 2.14 Released
http://www.phoronix.com/scan.php?page=news_item&;px=Git-2.14-Released
PCRE v2がデフォになった模様。
submodule 関連の新機能が中に入ってきているみたいだけど、よくわからん コマンドのヘルプはどうやって見ればいいのでしょうか？
例えばlog
git help log
git --help log
git log --help
どれもヘルプが表示されません 環境は？
git help log
でどういう動作になる？ git log --help で git log のヘルプが見れるのか！
知らなかったがこれは便利だな
man git log と同じ動作になるのか ＞＞９６０
ubuntuです
git-log というマニュアルはありません 「Git 2.14」リリース、細かな変更が多数加えられる
2017年8月7日15:15 末岡洋子
https://mag.osdn.jp/17/08/07/151500 >>962
Ubuntuにgit-man パッケージあるだろ？ あるブランチの、あるブランチ（例えばmaster）との差分が
わかる方法ってないですかね？
今は別ディレクトリにクローンしてディレクトリの差分を見ています git diffをスタイリッシュに表示させたいのですが 今まで全然使ってなかったけど
rebase時のautosquashって便利ね index.htmlだけをgitで管理してるんですけど
履歴って変更されたファイルの内容全てが記録されていくんでしょうか？
それとも変更された差分だけが記録されていくんでしょうか？ >>975
blobの中身はほぼファイルそのものだけど、何を気にしてるか知りたい wikiを作ってて履歴はどうやって管理したらいいのか気になってgitを参考にしようかなと思ってました >>977
wikiに履歴管理の機能あるでしょ？git使うより楽なんじゃ？ 980踏んだので次スレ立てようと思ったが、ワッチョイとか言うのがよく分からないのでどなたか代わりにお願い いいよ立てますよ
普段ここにいないので次スレのテンプレをここに貼り付けてもらえますか
そのとおりコピペするので このスレと同じワッチョイで立てていいですか？
＞デフォルトの名無しさん (ｴｰｲﾓ)
一応IDを表示させることもできますけど
デフォルトの名無しさん (ｴｰｲﾓ abcd-efgh) 何の意味もない
リモートホスト名強制表示でもいいくらいだよ ワッチョイとか設定できるのって2chに課金してる人だけだっけ？ うまい履歴・ブランチの作り方がまとまっている本かサイトある？
どの粒度でコミットしたらいいんだか迷って時間を無駄にしてしまう >>988
あんたがコミットする目的・理由は何なの？
その目的を達成するのは今だ、と思った時にコミットすればいいじゃん そのコミットする目的・理由はなにかって聞いてるんだろ だから自分は使ってないけど
他人はどういう理由で使ってるか聞いてるんだろ コミットは１行変更毎でもいいし
毎日寝る前でもいい
席を離れる前でもいい コミット粒度のトレードオフは
・細かくコミットすると、意味のあるコミットメッセージを付けるのにコストがかかる
・大きくコミットすると、後で分割したくなった時にコストがかかる
ってことを意識したら良い。
ちょうど良いコミット粒度は、習うより慣れろとしか言えないな。 このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 196日 10時間 10分 37秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
