◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:Git 15©2ch.net YouTube動画>8本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1486239735/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
ソースコード管理を行う分散型バージョン管理システム、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を使いこなして初めて
rebaseの使い途がそんなにないんじゃね
>>7 コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね？
そのどでかいブランチから、小さく機能を抜き取って
小さなブランチにしてマージするべきだよ。
そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う
エスパーすると
>>7 は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね
何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか？
>>8 なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている
>>10 masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ
>>12 あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい
最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
>>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扱いになってました
>>19 中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ
毎日仕事が終わったら、その日作ったソースコードを
コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな
>>24 ごめん、プッシュね。
マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。
細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
>>26 突っ走った後にgit add -p 使って複数のコミットを作る
>>26 一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う
>>28 そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ
エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ
>>31 数分おきにエディタに :wq! を送るスクリプトを作ろう
そもそもコミットは成果毎に行うのであって細かくすればいいというものではない
プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？
個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね
ショートカットキーctrl+Sで保存は便利でよく使う
>>37 チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね
>>39 ない
svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある
チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/ それに対するLinusの見解
http://marc.info/?l=git& ;m=148787047422954
hashの衝突は元から想定済っしょ
ファイル数が20万〜30万個あるプロジェクトをgitで管理できる？
gitで管理できなかったら、他の何を使っても出来ないと思うｗ
gitを使うのが目的じゃないけど結果的にgitを使ってるな
gitの使い方を覚えられないおっさんも世の中には居るんだ
使える人が使わないなら、それはいいんだよ。
なんでもいいから自分のソースくらい自分でコミットしろ。
面倒臭いのでだいたい
git merge --abort
AにコミットしてA'
git checkout 好きなコミットID
A->A''の方にはB(A')が無かったことにしたいのですが
説明がわかりにくすぎだろw
cherrypickでA''からAにパッチ当てりゃいいだけじゃね？
>>71 git branch B A'
をする
git rebase A -i
でA'の行を消す
ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み
適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね
せっかくローカルにあるんだし、どんどんコミットしたら？
rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫
rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください
> rebase怖いならブランチ切るなりタグつけるなりして
ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。
(1)git checkout -b hoge コミットID1 でhogeブランチを作る
>>88 コミットIDでcheckoutすりゃいいだけじゃね
(1)git checkout コミットID1
(2)git checkout コミットID2
>>88 git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと
resetは困ります。。。。
>>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 のやり方がスルーされるからやりたいことと違うんだろうなあ
みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
>>103 細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？
git add -p のこと？
git add -pの存在がsvnからの移行を決定づけた
俺もよく使うな。
git add -pなら使う。行単位でステージングする機能、だよね？
>>108 SVN 使いだけどこの機能とローカルコミットはマジで欲しい
行単位使ってる人多いんだな
>>111 何となくだけど git は性に合わない
stash, cherry-pick, rebaseのないコーディングなんてもう考えられない
試行錯誤のあととかノイズでしかないからな。
行単位とかやりすぎだろ。。
作業者が独りだから、同じファイルを複数行編集するんだろｗ
まとめてコミットするつもりで編集中だったワークツリーから
ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？
はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？
もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ
>>120 svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう
gitはOSSなんだからHACKするなり自分で手を加えればいいのでは？
>>123 コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ
タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの？
>>130 あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか？
そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな
Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
>>131 今時そんな事してる現場なんてあるわけないじゃん？
>>129 記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。
ファイルの日付どころか行単位で
修正日時が記録されているので必要ない
>>133 > Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
Aというブランチでファイルを追加します。
Aブランチから派生したBというブランチでそのファイルを修正します。
Bというブランチでコンパイルしてオブジェクトファイルを作ります。
Aというブランチに戻ります。
Bというブランチでコンパイルしたオブジェクトファイルが残っています。
ファイルの日付はリポジトリに入れないのでAの方が更新日付が新しくなります
そのためコンパイルするとBのオブジェクトファイルは使用されません。
という素晴らしい仕組みはgitだけの特典だとでも？
あんたはどうしてもほしいの？
流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
>>135 ごもっとも
だけどFAQでこの文章みた記憶がない
>>138 commit時の日時だっけ？
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が一覧できるのは便利。
タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
>>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
結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ？
お前が面白いとかつまらんとかほんとどうでもいい
>>150 > それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する
gitの思想じゃない。ソフトウェア開発の思想。
最新のタイムスタンプのものだけビルドするという考え方は
gitができるよりはるか昔からのやり方
gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ？
>>174 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 なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな
>>189 そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。
普通に考えて日付が違っていてもコンパイルすれば
>>188 いや
>>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが
>>191 そもそも具体的に何のためにそんなことしたいのかが分からないな
>>192 じゃあバックアップツール使え馬鹿で終わりだなｗ
意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw
じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
>>182 まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。
つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ？
>>196 gitでタイムスタンプを管理しないのは失敗だったかも
（でも今更だし悪い仕様でもこのまま乗り切るわ）
と講演で言っていたよね
>>196 やっすいことで満足できんだなあお前って
悲しくない？
>>200 なんだライナスも悪い仕様ってみとめてんだ
プロジェクトを作り直してコードもファイル構成も全部作り直す場合は
>>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は進化したってことだな（爆笑）
>>207 あ、ぶっちゃけさ、お前
gitでタイムスタンプを管理しないのは失敗だったと
リーナスが言ったと嘘を言ったのがバレたから、
調べてきたろ？ｗ
git logからコミット日時引っ張ってくるシェルスクリプト書きゃいいだけなのに、標準で入れるまでもないだろう
>>210 わざわざ自分で書かなくてもGitHubとかで誰かがその手のツール作ってるだろうからそれ使えばよくね？
Linus教はLinusが言ったことは全て真理というドグマで洗脳されているのか。
Linusが言ったとデマ飛ばして、それを否定したら
>>213 コレ
議論したいやつには全く見えない
>>167 >git for windows ならいける
そういやこれ試してみたがちゃんと日本語ディレクトリや空白いりディレクトリでもちゃんと動作するな。
なんで公式のGUIツールはあんなクソがいつまでもほったらかしなんだ？
メンテナの出来が悪いのか？
>>217 彼らにとってWindows版が必要ないからかな
git gui普通に日本語ディレクトリ名を表示できたけど・・・？
>>203 新しいリポジトリ作るほうがいいと俺個人は思う
gitでコードを管理している分にはタイムスタンプを戻すのは愚策だと思う
ExcelとかビットマップまでGitで管理しようと主張するマヌケが会社にいて困るわ。
>>223 決めの問題だからそう決めたなら、Gitで管理すればいい。成果物によって数ヶ所に置き分けないといけないよりまし。
>>224 決めの問題ならなおのこと 決めたやつがおかしい という話では
実際のところ、テキストベースではないドキュメントの管理は
gitでやる価値が半減すると思う
もちろんcvsやsvnでもあまり意味はないけど
>>223 困るならちゃんと説明してあげるか転職して会社変わったほうがいいよ
節目節目のあるリリースに関連付けられた形での
>>227 説明しても聞かないって話だろ
盲信ってことばも知らんのか？
なんだGitに向き不向きがあるよって話だけでここまで怒り狂うのか
diffが取れない程度でべつにエクセルのファイルを管理してもいいと思うけどね。
ここでもめてるgitの話題って英語圏のフォーラムとかでも似たようなやりとりあったりすんのかな
実質的にタイムスタンプ復元する方法が提示されて終わりじゃない？まともなフォーラムなら
>>229 知らなかったから辞書で調べてから書き込んだんだけど…
なにか気に触ったのならゴメンな
>>234 Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
WindowsでGUIのものを使おうと思ったら・・・・
git archiveで作ったzipのタイムスタンプって
>>231 Excelはxmlになってからdiffとれるでしょ
見やすいdiffが必要なら専用のツールが必要
そういや最近TortoiseSVNでexcelやwordファイルのdiff見たら、Office自体の
>>241 あのさ、差分機能で更新箇所を確認するのは仕事のやり方としては下策で、仕方なくやるものなんだけどな。
プログラミングにかかわらずドキュメントの類は差分ベースで仕事を進めることで効率が著しく向上する
Excel仕様書なんか捨ててMarkdownとかで書いた方がいいこと多いよね
おまえらどこをどう変えたのか毎回忘れて差分比較して仕事してんのかよw
>>248 お前の所は作った本人しかドキュメント読まないのか？
わざと忘れたりするわけじゃないが
>>249 共同作業の場合は更に効果倍増だな
でも、おれは一人でも作業する場合も、差分ベースで作業を進めることが劇的に効率を上げると思ってる
>>247 個人的には AsciiDoc 使ってるんだけど他にお勧めある？
>>252 あんたにとってはgitもレベルが低い仕組みなんだろうな
でもこれが普及して他のツールを駆逐してしまった意味をよく考えてみた方がいいぞ
全然駆逐してないんだけどな
もうgit以外を使ってるのは普通じゃない
>>259 で、gitのことはどう思ってるの？
差分を編集する機能を重視してるのがgitなんだけど
差分機能で更新箇所を確認するのが下策だと思ってる人はこれを受け入れちゃうわけ？
>>260 gitやその他vcsのことを何もわからずに煽ってるだけなんだから、
そんなに難しい質問してやるなよ。無視するしかなくなるだろ。
>>237 亀はだめ
Explorereが劇重になる
>>258 新しいプロジェクトに配属されて、バージョン管理がSVNだったらガッカリするからな
>>236 > Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
ファイルのタイムスタンプだろ？
保存してないよ。
嘘だと思うのなら、ファイルを修正してから次の日にコミットしてみ
ファイルのタイムスタンプじゃないものが保存されるから
>>260 Office製品の変更履歴機能の失敗も知らない世代なのか？
バイナリファイル系は適切なツールを使えば
officeのドキュメントを差分管理ベースで作業できるようにするなら
複数のブランチを切ることがそもそもない環境なら、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の山になって事実上無理ぽそう。
ここで言うことでもないけど
早く画面キャプチャをExcelに貼る作業にもどるんだ
>>275 > それでもXMLだから差分は一目瞭然かなと
え？ お前OfficeのXMLのタグを知ってるの？
XMLのタグを知っていないと、差分は分かっても
その意味はわからないよね？
>>280 > 差分見えてもmergeはconflictの山になって事実上無理ぽそう。
XMLのタグの整合性、つまり閉じタグの対応まで
ちゃんとやらないとだめだからねｗ
タグの意味、属性、誰か解説してる人いる？
Excelファイルのバージョン管理なんて実質タイムスタンプで管理するしかないのに、とにかくGiｔ真理教の信者は
gitがバイナリに弱いのは誰もが認める話だと思うけど、タイムスタンプで管理するのは無くない？
>>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 それじゃファイルの管理しか出来ないじゃんｗ
どうやってアプリのバージョンの管理をするんだよｗ
新しいバージョンへ追加する機能をマージしていくのが
バージョン管理というものなのに
せっかくのボケに対してマジレスしてどうする。
マジレスすると、馬鹿がムキーってなるだろ？ｗ
>>294 なんか勝手にレベルの低い敵を想定して、それをバカにすることで勝ったつもりってのが新しいなw
情けないにも程があるw
>>302 そうじゃないよ。もっと面白いことを言ってみせろってことだよｗ
>>294 ぐらいの内容は想定済みだからさ
>>296 そんな間抜けな機能を実装してどうする w
svnはバックアップツール的な役割で当分生き続けると思う
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なのだ
gitに限らずコイツらの布教活動が成功したためしなどただの一度もないけどなｗ
>>323 自分がいいと思ってる、使っているものが正しいという阿呆がなんにでもある。
世界を自分(たち)にとって都合の良い方向へ変えようとする活動が布教
VCSは頭の良い奴にしか使いこなせない
言ってもいいんじゃね。
>>332 わかる
特定のflowを絶対正義だと信じて「git pull --rebaseしないのは馬鹿」とか言い切ってくる奴とかなー
あるある大事典：
gitの話ばかりしてるから、(gitに対して嫉妬してる)svn(ユーザ)のスレかと思ったら、git(信者がのさばってる)スレだった…
SourceTreeって重くね？
branchだけしてcheckoutし忘れ
>>342 つgit checkout -b new_branch
git stash popは危険なコマンドだと思いませんか？
マージ失敗したらdropされずに残るので、やり直せる
大抵の手違いは元に戻せるのがgitのいいところなんだけど
ファイルスタンプは手違いで発生するものじゃないからねｗ
いつまでタイムスタンプの話続けるの？
リーナスにタイムスタンプ入れるとかアホって言われたのが
インターネットみてると「マスターをチェックアウトして」とか
自分がブランチに出たり入ったりするというのは斬新な見方だな。ホテルかよ。
>>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&*
"マスターへチェックアウト"との一致はありません。
ごめん、結構いたわ。
コンフィグのここで疑問なんだけど
ブランチを切る ってどっちの意味？
もしかしてrefs/heads/masterはローカルを指していて
refs/heads/masterはリモートを指してるらしい、
>>368 refs/heads/masterが、masterという名前のブランチの正式表記で、originのリモートリポジトリの別名表記ってだけじゃないの？
tagにも同じ名前を付けられるからコンフィグは正式名称の方が都合がいいし、
リモートリポジトリは参照するサーバーやリポジトリパスが変わることもあるし、同時に同じリモート名は付けられないから別名表記の方が都合が良い
ってことだと思うけど。
ホテルから出ることをチェックアウトと言う
SVCとかSubversionとかVSSだとリポジトリからファイルがチェックアウトされて
>>373 おっさんは色んな環境・用語に晒されてるから、VCSみたいな同じような機能にそれぞれのアプリケーションで別の用語を割り当てるシステムだと、ごっちゃになるんだよ
gitのタイムスタンプは記録されてないけれど
>371
>>375 実行権限のみ
いろんな人がいろんな環境でチェックアウトするのだから
グループやその他のパーミッションは記録する意味がないし、
umaskの設定に従えば十分
また自分自身がチェックアウト（＝書き込む）ファイルなのだから、
リードオンリーにすることもできない。
よって実行権限のみ記録するのが
バージョン管理ソフトとして正しい仕様。
gitもそれに従っている。
正しい仕様、みたいにすぐドグマ化しちゃう人って柔軟な発想ができなくて開発者としてはポンコツなんだろうなあ
>>380 これわかるわ
正しいとか正解とかそういう言葉を頻繁に使う人は状況に応じた選択ができない
>>380 同意
明確に条件が限定された状況で、考え抜いた上に「正しい」とか言うのならわかるけど、バージョン管理なんてソフトウェアのソースコードに限ったとしても
ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに、自分の知ってる範囲だけで決めつけちゃうのってダメだよね
お客さんの要求の本質を汲み取ろうとせず勝手に自分の都合で判断してそう
>>378 > 所有者くらいは記録してほしかったよね
所有者とは？ 会社名？ｗ
一行ごとに誰が修正したかは記録されている。
その話をしていないということはお互い理解しているという前提で
なんのために所有者を記録するの？
>>384 > ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに
ぜんぜん違うと言うものの具体的な例を
君はこれから言わなくてはいけないということになったんだが、
できるかい？
それができるまでは、ゲーム、組み込み、Web、業務システムで
求めるものに違いはないという今までの常識通りでいくからさｗ
信者というと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標準のバックアップ機能でもできるよ
ソースの版とリンクしてる
>>423 結局これが一番困るよな。
テキスト以外なくても困らない開発だったらいいんだろうけど、そうじゃないものも多い。
大きなバイナリファイルのバージョン管理が本当に必要ならべつにリポジトリに入れてもいいんじゃね？
>>423 そんなもんファイル名、もしくなディレクトリ名を別にしておいて
参照先の名前を変えれば済む話だろう？
>>427 済まないから困るんだろ、勝手に問題ないケースに置き換えて話するのはおかしいでしょ
画像リソースまでソース管理から除外するのかよw
俺はできる限りはリポジトリに入れるけど。
>>427 参照先の名前変えるってなにそれ？
管理したいバージョンごとにファイル名やディレクトリ名を変えるの？
>>432 ファイル名やディレクトリ名は最初に作ったまま固定変えたりしない。
ファイルサーバーは原則として追加するだけ。
そして新しいリソースに更新したければ、
ソースコードの設定ファイルをいじって、
参照するファイル名（ディレクトリ名）のパスを変更する
パスを変更するってことはディレクトリ名かファイル名かは変わってるんじゃないの？
>>434 ファイルは追加するだけなんだから、最初から別の名前にするしかないだろ。
中身が違えば、それは別のものだ。
結局ファイル名に日付入れて管理しろと言い出すわけだな。
ソースコードはGitで管理して
>>436 > 結局ファイル名に日付入れて管理しろと言い出すわけだな。
> gitいらないじゃん。
だからバージョン管理システムは、ファイルの版ではなく、
ソースコードのバージョンを管理するものだから、
バイナリにはgitいらないって言ってる。
人の話聞けやｗ
gitはソースコードを管理するためのものだ
ソースコードじゃないものを管理するものじゃない。
巨大なバイナリファイルをいれんなｗ
Git LFSはすでにVersion2.0.2でGitHubもGitLabもGit LFSに対応済みなのに
Git LFSは "別のツール" だぞｗ
>>442 別サーバーにする必要はないよｗ
同じサーバーで2つのツールを動かせばいいだけ
gitサーバーとファイルサーバーの2つ
何がありえないのかわからん。
>>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 バージョン管理ソフトはソースコードを管理（＝マージなど）するもので
それができないのなら入れる必要はない。
入れてもいいけど入れる必要はない。
大きいバイナリなど入れることで問題が起きるのなら
入れないほうが良い
画像リソースなんてソースファイルみたいなもんなのにいちいち分離してられるかよ
バイナリはファイル名でバージョン管理したい人みたいだからもうほっといて差し上げろ
ファイルを管理するためにgitを使うんじゃなくて、
>>383 >ファイルを管理するためにgitを使うんじゃなくて、
>gitを使うためにソースコード入れてるだけの人だよね。
>開発してるわけじゃないんだよ、git使ってるだけ。
こいつバカかw
好きに使え。
バックアップツールとして使いたいなら
プログラムに内蔵されるリソースの話をしてるのに、
画像リソースで話が通じないんだもん
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. ファイルの更新日付が変わってないのにウイルスに感染していた。
これでわかる？
なんか知らんけどいちいちアーカイブ作ってんの？
>>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に求めるもんじゃないだろう。
>>510 > もともとタイムスタンプが保持される方が便利な用途もある。
ソースコードにおいてはタイムスタンプは、便利便利じゃない以前に
ファイルを更新した時間でなければいけない。
ソースのコミット時間であってはならない。
これはMUST、絶対的な要件だ
checkoutなどでファイルを変更したならば、
その変更した時間（つまり現在日時）にならないといけない。
そうしないとソースコードは適切にビルドできないし、
ビルドを必要としないスクリプト系でもソースコードが
修正されたタイミングで内部的に再コンパイルするものがある。
今あんたが気づくべきは、俺がソースコードに限定した話をしているってところだ。
ソースコードを管理するツールだから、そういう設計になっている。
メタデータをコミット時に保存してチェックアウト時に復元できるような別ツール使えばいいんじゃね
ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
>>524 ビルドの度に全ファイルハッシュ計算して保持とかわざわざ遅くなる割にメリット殆どないような事をするわけがない。
メリットがあるのであればそんなに難しい事じゃないんだし既に存在して知られてるよ。
>>524 >ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
そんな話どこにあるんだ...ビルド時間が無駄に増えるだけに思えるんだけど、何かメリットがあるのだろうか
>>525 > どこにハッシュ値を保持しろと？
全くそのとおりだなｗ
ビルド前のファイル ・・・の日付
ビルド後のファイル ・・・の日付
両方共ファイルの日付という情報を持っているからこそできること
お前ら必死だな
それは違う
>>529 IDEのビルトインも含めてビルドツールいままでどれだか作られてると思ってんの？
で、それらすべて素人が作ってると？
素人が作ったって言ってんじゃないよ
おまえらがバカにしてる納品物のタイムスタンプを気にしてるやつと考え方が同じだって言ってるの
Googleはタイムスタンプベースじゃないビルドツール使ってるけど
「何かメリットがあるのだろうか？」って聞いてこいよ
https://bazel.build/versions/master/docs/bazel-user-manual.html#correctness むしろタイムスタンプで十分なものをわざわざ遅く無駄にメモリとストレージとIO帯域を浪費するような実装しようとするほうが余程のマヌケか素人
>>532 タイムスタンプを使わないとは書いてないぞ？
タイムスタンプとファイル内容と書いてあるぞ？
>>532 それ、デフォルトでタイムスタンプ使うと書いてるけど？
>>534 ファイル内容というかファイルの依存関係だね。
既存の大抵のビルドシステムとやろうとしてることは同じ
bazelを含めたビルドツールがタイムスタンプに依存しているのは
だってファイルシステムのエントリに保存されてるもの
ビルドに依存関係のあるファイル（中間成果物も含む）をすべて最新のソースに反映済みかビルドツールは確認しなくちゃまずいと思うんだけど、
>>520 タイムスタンプを保存したり復元するツールはそれなりに使い所があるかもしれないが、gitに含めない方が良いよな
ひとつのツールに機能を盛り込みすぎない方が良い
「Gitを部内で普及させた方がいいですよおー」
>>541 今でさえいい加減多機能すぎなのに、タイムスタンプを戻すスイッチのオプションが増える
ことが「機能盛り込みすぎ」と言えるだろうか？
バックアップからコピーしても
>「Gitを部内で普及させた方がいいですよおー」
>>539 話は簡単。
ファイルのハッシュを使ったほうが完璧だが、
それはタイムスタンプを戻す理由にはならない。
信者が納品にまでgitを使わすことを強制しててワロタ
>>548 git archiveといって、納品とかに使える機能すら
gitは用意してくれているよ。
そういう意味ね。納品にgit強制＝git archiveを使う
あ、一応説明しておくか。
知らんけど
>>534 タイムスタンプにだけ依存してるツールと
最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
Bazelはファイルシステムでハッシュ持ってる場合はハッシュ比較を先にしてmtimeの比較はしない
mtimeで比較する場合もその後ハッシュで比較する
Google内部ではカスタマイズしたファイルシステムを使ってハッシュを保存してるからタイムスタンプに依存しない
>>525-528 この辺のやつは既存の慣習や制約の枠内でしか物事を捉えられない脳みそだから
タイムスタンプ君と同類 いい反面教師
>>552 デタラメばかり言ってんじゃねえよ
だいたいファイルの内容量のハッシュを保持するファイルシステムがどこにあんだよ
>>552 > 最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
一緒にしてないぞ？
最適化のためにタイムスタンプは、コミット日時ではなく
最後に変更した日時になるべきだって話をしてる
>>553 内容量？
Googleが使ってるのはクローズドソースだよ
>>554 は？
タイムスタンプ君？
>>555 ファイル内容のハッシュを
そんなファイルシステムがGoogle社内に存在しているという根拠ぐらい貼れよ
ソースを管理するためじゃなくてgitを使うためにgitを使う信者が、
>>557 そんな話をしてる奴居るか？
ちなみに俺は一度もgitの話なんてしてない。スレ違いのビルドツールの話をしてるぞ
gitは完璧である
>>555 > は？
> タイムスタンプ君？
なんだそりゃｗ
反論の一つも言えなかったのかよｗ
>>559 マヌケだなｗ
こちとらgitはソースコードのバージョンを管理するためのツールで
バックアップソフトが欲しければ、そっち使えという、
すごく当たり前の前提において、
ソースコードのバージョン管理ソフトはどうあるべきかを語っているだけなのに、
そうか。あのバカ、gitをバックアップソフトだと思っていて、
gitにないものは、gitの機能不足だと思ってるんだ。
>>557 > たかがタイムスタンプすら保持できないという話を出されただけで
タイムスタンプを保持しないのがバージョン管理ソフトとして
正常な動きですからね。
>>543 タイムスタンプを戻すのはバージョン管理とは関係ないから盛り込み過ぎだな
必死な人っていうのは、
まあ本当に必要だと思うなら git コミュニティーに投稿すりゃいい話ではある。
>>566 昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
絶対に入れることはない。とピシャリと言い放ったからな。
ここで愚痴るしかないだろうさｗ
bazelは「同じ」ソースファイルからは「同じ」成果物が生成されて、
タイムスタンプ比較した方が早いのに「ビルド時に毎回ハッシュ計算するからタイムスタンプ戻せ」って
ファイルのビルド依存関係は完全に把握していることが前提で、
>>568 > そのために、この「同じ」にはタイムスタンプがなるべく関係しないようにしたいという感じなのか
違う。bazelでもタイムスタンプが違えば違うとみなすが、
それに加えてファイルの中身まで見てるってことだよ
タイムスタンプが違ったら違うかも？って判定して、
ビルドを最小限にするにはタイムスタンプの違いだけでビルド開始してたら話にならんし
gitにタイムスタンプを入れるな派はソースファイルを考えていて
>>567 >昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
>タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
>入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
>タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
>絶対に入れることはない。とピシャリと言い放ったからな。
それ単にリーナスの尻馬に乗って俺スゲエって言いたいだけちゃうかと
少なくとも「間違い」とか「正しい」なんて言えないだろ
タイムスタンプ入れろ派も（上見ればわかるけど）それをデフォルトの動作にしてよみたい
>>575 なんでそんなすぐバレる嘘つき続けるんだ？
それ単にFUSEを通してバージョン管理システムにアクセスするだけでファイルシステムじゃないじゃねえか。
これがファイルシステムだと主張するならgmailすらファイルシステムと言えるわ
ぶっちゃけdiffしか見なくね？
>>574 > 入れろ派はdiffで差分確認出来ないファイルを考えているんだよね?
何も考えてないだろｗ
その証拠にタイムスタンプを入れることで
どんな問題が解決するのかを言えていない
で、タイムスタンプ信者は何でタイムスタンプ入れたがるの？
さんざん上で出てんじゃん
出てなかったはずだが？
あくまでソフトウェア開発の道具としてgitを使う層と、gitを使うのが趣味でそのために適当なテキストファイルを書いている層とがいるから話が噛み合わないんだよな
開発の道具（道具だから開発時に使う）のと
>>588 適当なテキストファイルを書いてるとタイムスタンプがどう役に立つんだ？
>>591 >>592 え？じゃあソフトウェア開発にタイムスタンプ(を戻す機能)がどう役にたつんだよ
同じ意見同士で喧嘩すんな。
>>594 お前とは同じ意見だけど、
>>591 と
>>592 と同じ意見とは思えないけど
なんで実装するべきかそうじゃないかで喧嘩が始まってしまうのか理解できない
>>596 自分で作るという話ならば、hookでやる方法なんてすぐに思いつくので議論の余地はない
>>597 hookで実現するかどうかを議論するということではなく、もし、タイムスタンプの管理が必要なのに自分でhookを書けない人が居るんだとしたら、
素直にどういうふうにhookを書けばいいか相談するなり何なりすればいいのにね、ってこと。
自分にとって必要なのに機能がない、に対して
1. ツールを工夫して使って代替する方法を考える、相談する
2. 他のツールを探す
3. ツールに追加機能を実装して採用してもらう
4. 機能がないことを盾にそのツールを頭ごなしに否定する
あたりの選択肢があるっぽいけど、どうして最も建設的でない4を採用する奴がいるのかな？って思っただけ
>>596 建設的な議論をしたいんじゃなくて
ただたんに文句言いたいだけだからな。
少なくとも
git タイムスタンプ
とかでググればけっこうやり方はでてくるよ。
エクスポート時に全部同じ日時になるのって
>>599 gitのhookで解決する方法がググれば出てくるのに、それでもなにか言いたいんだとしたらhookを使うことには実務上の問題があるのか、
ググって出てきたやり方には欠陥があるのか、何かしらググった結果では満足できない合理的な理由があるんだと思ったんだけどな。
嗜好品だったらともかく、実用品を実用上の問題以外で批判することが、その人にとってどういう嬉しさをもたらすのか全くわかんないわ。
いちゃもんつけられる俺スゲー君はどこにでもいるから
長文アスペ信者君を弄って遊びたい奴が一人か二人いて、
>>602 ということは、タイムスタンプで管理することを仕事かなんかで強制させられて、諦めてそれに従うんじゃなくて、タイムスタンプに意味があるんだ！なんとなくだけど！って思い込んでる人がいるってことかな
言語の話なら一長一短あるだろうし具体的にこの機能はこんなに素晴らしい！とか指摘できると思うんだけど、タイムスタンプ管理のメリットってのが全然語られないし、
むしろ、メリットデメリットで主張してるのではなく、そう決まってるから従わざるを得ないというところを有耶無耶にしているような印象があるんだよな。
まぁ、
>>604 の言うようにバイナリかタイムスタンプネタで遊びたいやつが居るだけの可能性も高そうだけど。
単純にタイムスタンプっていうのは、ファイルを最後に変更した時間なんだから
>>607 そのファイルをその内容に変更した時刻のことだよ。
Windowsでファイルをコピーしたことない？
タイムスタンプも一緒にコピーされる意味を考えてみようよ
あと、「makeがタイムスタンプを参照するから」 という回答もおかしいよね。
WindowsでもLunixでもMacでも
gitがタイムスタンプを復元すると言うのは
まぁひとつだけ言えるのは、git cloneでコミット時刻が復元されたら俺はうれしいってことかな。
>>612 bazelがファイルの内容を”その”ファイルシステムの変更検知に使うなんてどこにも書いてないんだけど、嘘つきに騙されちゃったの？それとも本人？
あーgitにタイムスタンプ復元機能があれば完璧なのにー
gitがタイムスタンプを保存しないのは
>>610 > 『makeは、ファイルの更新日付なんか参照せず、ファイルの変更を検知すべきだ』
ファイルの変更を検知するためには、変更前のファイル情報を持ってないとダメでしょｗ
>>609 > Windowsでファイルをコピーしたことない？
いまコピーの話はしてない。
同じ名前で内容を変えた場合の話をしている
内容を変えたのであれば、内容を変えた日時になるのは当然でしょｗ
>>621 変更前のファイル情報を持ってるツール使ってないのww
>>624 最初から、更新前のファイル情報がないツール前提の話でしょ？
>>623 じゃあ内容を戻したら、日付も戻せよ
という話でしてね
ふう、gitにタイムスタンプ復元機能があれば完璧なのにー
>>629 gitは内容を戻すことは出来ない。
任意のコミットをcheckoutするだけ
では僭越ながら
はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？
他の人はネタでバカ言ってるけど
>>634 だけ普通のバカだな・・・
いや、流石にsvnでもタイムスタンプは戻せん。
タイムスタンプ機能があればいいのに、ライナスも意地になっちゃったんだろうな
澁谷 恭正 (46歳)
死ぬまでには出来るだろうと思ってずっと待ってると先に死んでしまう
時間は不可逆だって時をかける少女で言ってた
伸びたら洗うの面倒だし、髪切るのもただじゃないし時間もかかるし、夏は暑いし、ない方が楽じゃね？
gitでタイムスタンプを戻すことが出来るようになる時間線では、さらに遠い未来ではgitで時間を戻せるようになるまで拡張される。
オカルトって、初っぱなの論理の飛躍に気づかないと、
Gitは最近やったコミットの改変、つまり歴史改変ができるじゃん
ﾌﾟﾚﾐｱ見れない
すいません。分からないので教えてください。
>>671 その方法ほしいよな。マージの順番に依存関係をもたせたい
プルリクがマージされるまでは、そのプルリクのコミットを前提にしたコミットはプッシュしたら駄目なんでしょうか。
プルリク出した修正や追加を前提としたプルリクは最初のプルリクがリジェクトされたときに同時にダメになるわけだからよくない。
先のプルリクがマージされたら、後のプルリクのFile Changedが変わるかと思ったけど変わらなかった
>>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はファイルの所有者情報を記録するけど
>>714 なんのためにディレクトリがあるのかわかってる？
gitはディレクトリ情報は保存するぞ
>>718 そうやって煽ってもいい加減つまんないぞ
タイムスタンプと寸分違わず同じ流れでよく飽きませんね
そういうことに、したいのですね。
error: The branch 'void' is not fully merged.
rebaseして失敗したら追加したファイル全部なくなったんですが、復旧できないですか？
rebase --abortすりゃいいだろ
>>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 今更入門書なんかいらないよ
卒業編を持ってこい
ファイルの属性が無くなるのは仕様？
俺スゲエ、って自慢したいだけのネタさがしで本当はだれもGitなんて興味ない
ということにしたいんだけど、どう？うまくいったかな？
>>794 デフォルトの仕様ってことはわかった
設定で回避したいんだけど、どうしたらいい？
タイムスタンプはコミット時間で補完出来たけど
setuidはデプロイするシステム側でつけるんじゃないの？
>>802 テスト環境では直接gitでモリモリしてたけど良くないのか？
めったにいじらないファイルだったから気づかなかった
>>803 setuidの目的から考えると、gitの情報から復元するのは危険だろうね
Windows上にリモートリポジトリ置いて、別PCにローカルリポジトリ（リモートのクローン）を置いたときに、
一部解決。
修正用にブランチを作成してから他人のリポジトリにプルリクエストしたんですけど
push -fって、他の人が折角作ったリポジトリを破壊したいのか
>>810 push -fするのは他人のリポジトリって言ってませんよね？
自分のリポジトリの自分のブランチですよ？
まったくgit初心者ってバレバレなんだから
無理してレスするな
>>812 誤解されるような書き方をするほうが悪い
1日頑張ったけど解決しなかった。
わっかんねー。
>>811 Git for Windowsを許可しても、TCP9418を許可してもダメでした。
unpack failed: unpack-objects abnormal exit
.gitignore
.gitignoreに
.gitignoreの内容をこうするんですか
.gitignoreに
>>817 git update-index --assume-unchanged [filepath]
週末に自宅でプログラミングしていくつかコミット作った後で、
rebaseしてみましたが、sourcetreeだと、日時とコミットした...の二つが表示されていて、
コマンドじゃなくてsourcetreeで簡単にできないんすかね
週末に作ったコミットと同じ内容のコミットを手作業でコーディングしていって新しくコミット作るしかないんでしょうか
環境がよくわからないのだけれど、別のディレクトリにgit cloneして、週末に作業した分で上書きしちゃえば良くない？
家からは別ブランチにプッシュしといて出社してから家でやったコミットをmasterにチェリーピックすればいいのでは
cherry-pick もオプション無しだと元のコミットの AuthorDate を引き継ぐね
>>831-832 で思ったけど、戻りたいところまでgit reset --softで戻ってaddしてコミットし直しが一番簡単かな？
SourceTreeだけでもできるし
git rebase -i HEAD~
会社のソースコードを持ち出して自宅で作業してるってバレたら嫌じゃないっすか
コミットログを改竄しないといけないなんて大変ですね
もはや何の為のソース管理なのか分からんようになっとるなｗ
gitで管理されていないソースセットがあるとします。
なるほどありがとう。
ヒカル TV出演「年間5億は稼ぐ勢いですね」
VIDEO 第１回案件王ランキング！YouTuberで１番稼いでるのは誰だ！
VIDEO ;t=61s
ユーチューバーの儲けのカラクリを徹底検証！
VIDEO ;t=504s
【給料公開】チャンネル登録者4万人突破記念！YouTuberの月収公開！
VIDEO ;t=326s
誰も言わないなら俺がYouTuberのギャラ相場を教えます
VIDEO ;t=118s
YouTuberになりたいのは馬鹿じゃない！YouTuberになる方法
VIDEO 最高月収5000万円だとさ。年収じゃなくて「月収」な
おまえらもyoutubeに動画投稿したほうがいいぞ。副業にぴったしだ
やろうと思えばスマホがあればできるぞ
最低2年はやらないとここまではいかないだろうけど才能とアイデアと
企画力と継続力があればが大儲けできる可能性がなくもない
まだまだ他の職種に比べれば競争率は低いからオススメ
顔出したくないならラファエルみたいに仮面つければいい
ハロウィン用でいろいろな仮装マスク売ってるからオヌヌメ
githubでマージされずにクローズされたプルリクを削除したいんですが、どうやったらいいでしょうか
うちのプロジェクトにもそんなのあるわ
>>848 方法がないっぽいけど、あったら誰か教えて。
>>849 そんなことで文句言われる方がかわいそう
間違ったcommitを消しちゃうかどうかって議論と通じるものがあるな。
>>853 作業履歴であれば残しておくべきだし、
アプリのバージョン履歴であればリリースしてないものは不要
わかばちゃんと学ぶGit使い方入門
というか、
1 A
A
>>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はタイムスタンプが更新されたソースをビルド対象にすればいいし、デプロイも同じような
自分がタイムスタンプ更新したくせに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が更新されていたら、
>>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してビルドができない
タイムスタンプの件は
FTPでソースコードをサーバーにアップロードしました。
>>892 古いバージョンのブランチをcheckoutして
日付の新しくなったファイルをアップロードすればいい
という話に持っていくにはどうすればいいっすかね？
>>893 あ、さーせんｗ
こんな時間にこんなに早くレスくると思ってなかったっす
トイレ言ってる間に書き込まれたけど、
>>894 が本当に言いたかったことっすｗ
>>893 > 古いバージョンのブランチをcheckoutして
> 日付の新しくなったファイルをアップロードすればいい
gitにタイムスタンプを入れたら、古い日付になるじゃないですか！
>>886 >>887
csprojに適切な設定(デフォルト)がされていればビルド時に生成されるはず。
生成されたファイルには「手で編集すんな」って注意書きがある。
>>888 Xamarinの人は自動生成できないからResources.designer.csをリポジトリに入れたら困った。
って話じゃないの？Xamarin知らんから想像だけど。
>>897 なるほどXamarineの場合にだめなのか
C#はXamarineしかやってないから勘違いしてた
糞なのはXamarineなのな
MSも csproj とかはわりとマージしやすくなってちょっと Git フレンドリーになったと思ったけど
gitでメタ情報の差分を見る方法を教えてください
>>902 $ git diff HEAD^1
diff --git a/hoge b/hoge
old mode 100644
new mode 100755
要するにメルカリで情報流出させるようなDeployしてるのか君らは
特定の拡張子を除いてpullする方法、もしくは特定の拡張子だけpullする方法はありますか？
自分用のgitignoreに＊.db,＊.logを登録する
すでにレポジトリ管理化にあるファイルはgitignoreに入れても意味ないんやで
なので git update-index なんてものがある
http://qiita.com/usamik26/items/56d0d3ba7a1300625f92 何で中途半端にﾜｯﾁｮｲしてんだよ
gitlabのmerge requestをsource treeでダウンロードしたいんですがどうしたらいいですか
サーバー側のバージョンをクライアントから知るコマンドってある？
>>916 サーバへの接続手段にsshを使ってるんだったらわかる
git のフローを保つために、間違ったコミットしたりすると物凄く時間をかけて正しくするんだけど、時間の無駄としか思えない。
>>919 「さっきの間違ってたので訂正」 というコミットをしろ。
間違いをなかったことにするな。 絶対にだ
読む時のノイズにしかならない
テストがあれば汚いコミットログは不要かな。
何のためにコミットログを残すか考えれば自ずと答えは出る
>>923 間違ってないコミットを間違って修正する可能性がある方が悪だよ
言うまでもないことだけど
>>922 それはmasterとか継続的に共有するブランチの話だろ。
逆に、masterにマージするならきれいにしてから持って来い。
2.13.3 と 2.14 が立て続けに出そうな予感
>>934 今頃どしたの？ ｗ
いくらなんでも情弱すぎでしょｗｗｗ
あるファイルいっこだけブランチする ってことはできないの？
2.13.4 が出る模様。
git checkout ref/tags/タグの名前
gcc にパッチ投げようと
>>939 既存のブランチからヒストリがそのファイルしか含まないブランチを作りたいなら
git filter-branch --tree-filter "find -not -name hoge -print0 | xargs -0 rm"
でできるけどそういうことでなく？
masterにマージの終わったブランチを
そのメンバーがmaster以外のブランチをpushしてるのが悪いので責任とらせて消させれば良い。
>>953 ありがとうございます。
運用考えます。
別に運用問題ないと思うんだけど。
Git 2.14 Released
http://www.phoronix.com/scan.php?page=news_item& ;px=Git-2.14-Released
PCRE v2がデフォになった模様。
submodule 関連の新機能が中に入ってきているみたいだけど、よくわからん
コマンドのヘルプはどうやって見ればいいのでしょうか？
環境は？
git log --help で 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をスタイリッシュに表示させたいのですが
Git v2.14.1
v2.7.6, v2.8.6, v2.9.5, v2.10.4, v2.11.3, v2.12.4,
and v2.13.5.
https://public-inbox.org/git/[email protected] /T/#u 今まで全然使ってなかったけど
index.htmlだけをgitで管理してるんですけど
>>975 blobの中身はほぼファイルそのものだけど、何を気にしてるか知りたい
wikiを作ってて履歴はどうやって管理したらいいのか気になってgitを参考にしようかなと思ってました
>>977 wikiに履歴管理の機能あるでしょ？git使うより楽なんじゃ？
980踏んだので次スレ立てようと思ったが、ワッチョイとか言うのがよく分からないのでどなたか代わりにお願い
いいよ立てますよ
このスレと同じワッチョイで立てていいですか？
何の意味もない
ワッチョイとか設定できるのって2chに課金してる人だけだっけ？
うまい履歴・ブランチの作り方がまとまっている本かサイトある？
>>988 あんたがコミットする目的・理由は何なの？
その目的を達成するのは今だ、と思った時にコミットすればいいじゃん
そのコミットする目的・理由はなにかって聞いてるんだろ
だから自分は使ってないけど
コミットは１行変更毎でもいいし
コミット粒度のトレードオフは
ID:X3LbZrz10のレス一覧： git merge --abort
AにコミットしてA'
git checkout 好きなコミットID
A->A''の方にはB(A')が無かったことにしたいのですが
説明がわかりにくすぎだろw
cherrypickでA''からAにパッチ当てりゃいいだけじゃね？
>>71 git branch B A'
をする
git rebase A -i
でA'の行を消す
ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み
適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね
せっかくローカルにあるんだし、どんどんコミットしたら？
rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫
rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください
> rebase怖いならブランチ切るなりタグつけるなりして
ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。
(1)git checkout -b hoge コミットID1 でhogeブランチを作る
>>88 コミットIDでcheckoutすりゃいいだけじゃね
(1)git checkout コミットID1
(2)git checkout コミットID2
>>88 git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと
resetは困ります。。。。
>>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 のやり方がスルーされるからやりたいことと違うんだろうなあ
みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
>>103 細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？
git add -p のこと？
git add -pの存在がsvnからの移行を決定づけた
俺もよく使うな。
git add -pなら使う。行単位でステージングする機能、だよね？
>>108 SVN 使いだけどこの機能とローカルコミットはマジで欲しい
行単位使ってる人多いんだな
>>111 何となくだけど git は性に合わない
stash, cherry-pick, rebaseのないコーディングなんてもう考えられない
試行錯誤のあととかノイズでしかないからな。
行単位とかやりすぎだろ。。
作業者が独りだから、同じファイルを複数行編集するんだろｗ
まとめてコミットするつもりで編集中だったワークツリーから
ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？
はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？
もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ
>>120 svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう
gitはOSSなんだからHACKするなり自分で手を加えればいいのでは？
>>123 コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ
タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの？
>>130 あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか？
そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな
Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
>>131 今時そんな事してる現場なんてあるわけないじゃん？
>>129 記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。
ファイルの日付どころか行単位で
修正日時が記録されているので必要ない
>>133 > Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります
Aというブランチでファイルを追加します。
Aブランチから派生したBというブランチでそのファイルを修正します。
Bというブランチでコンパイルしてオブジェクトファイルを作ります。
Aというブランチに戻ります。
Bというブランチでコンパイルしたオブジェクトファイルが残っています。
ファイルの日付はリポジトリに入れないのでAの方が更新日付が新しくなります
そのためコンパイルするとBのオブジェクトファイルは使用されません。
という素晴らしい仕組みはgitだけの特典だとでも？
あんたはどうしてもほしいの？
流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
>>135 ごもっとも
だけどFAQでこの文章みた記憶がない
>>138 commit時の日時だっけ？
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が一覧できるのは便利。
タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
>>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
結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ？
お前が面白いとかつまらんとかほんとどうでもいい
>>150 > それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する
gitの思想じゃない。ソフトウェア開発の思想。
最新のタイムスタンプのものだけビルドするという考え方は
gitができるよりはるか昔からのやり方
gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ？
>>174 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 なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな
>>189 そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。
普通に考えて日付が違っていてもコンパイルすれば
>>188 いや
>>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが
>>191 そもそも具体的に何のためにそんなことしたいのかが分からないな
>>192 じゃあバックアップツール使え馬鹿で終わりだなｗ
意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw
じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
>>182 まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。
つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ？
>>196 gitでタイムスタンプを管理しないのは失敗だったかも
（でも今更だし悪い仕様でもこのまま乗り切るわ）
と講演で言っていたよね
>>196 やっすいことで満足できんだなあお前って
悲しくない？
>>200 なんだライナスも悪い仕様ってみとめてんだ
プロジェクトを作り直してコードもファイル構成も全部作り直す場合は
>>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は進化したってことだな（爆笑）
>>207 あ、ぶっちゃけさ、お前
gitでタイムスタンプを管理しないのは失敗だったと
リーナスが言ったと嘘を言ったのがバレたから、
調べてきたろ？ｗ
git logからコミット日時引っ張ってくるシェルスクリプト書きゃいいだけなのに、標準で入れるまでもないだろう
>>210 わざわざ自分で書かなくてもGitHubとかで誰かがその手のツール作ってるだろうからそれ使えばよくね？
Linus教はLinusが言ったことは全て真理というドグマで洗脳されているのか。
Linusが言ったとデマ飛ばして、それを否定したら
>>213 コレ
議論したいやつには全く見えない
>>167 >git for windows ならいける
そういやこれ試してみたがちゃんと日本語ディレクトリや空白いりディレクトリでもちゃんと動作するな。
なんで公式のGUIツールはあんなクソがいつまでもほったらかしなんだ？
メンテナの出来が悪いのか？
>>217 彼らにとってWindows版が必要ないからかな
git gui普通に日本語ディレクトリ名を表示できたけど・・・？
>>203 新しいリポジトリ作るほうがいいと俺個人は思う
gitでコードを管理している分にはタイムスタンプを戻すのは愚策だと思う
ExcelとかビットマップまでGitで管理しようと主張するマヌケが会社にいて困るわ。
>>223 決めの問題だからそう決めたなら、Gitで管理すればいい。成果物によって数ヶ所に置き分けないといけないよりまし。
>>224 決めの問題ならなおのこと 決めたやつがおかしい という話では
実際のところ、テキストベースではないドキュメントの管理は
gitでやる価値が半減すると思う
もちろんcvsやsvnでもあまり意味はないけど
>>223 困るならちゃんと説明してあげるか転職して会社変わったほうがいいよ
節目節目のあるリリースに関連付けられた形での
>>227 説明しても聞かないって話だろ
盲信ってことばも知らんのか？
なんだGitに向き不向きがあるよって話だけでここまで怒り狂うのか
diffが取れない程度でべつにエクセルのファイルを管理してもいいと思うけどね。
ここでもめてるgitの話題って英語圏のフォーラムとかでも似たようなやりとりあったりすんのかな
実質的にタイムスタンプ復元する方法が提示されて終わりじゃない？まともなフォーラムなら
>>229 知らなかったから辞書で調べてから書き込んだんだけど…
なにか気に触ったのならゴメンな
>>234 Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
WindowsでGUIのものを使おうと思ったら・・・・
git archiveで作ったzipのタイムスタンプって
>>231 Excelはxmlになってからdiffとれるでしょ
見やすいdiffが必要なら専用のツールが必要
そういや最近TortoiseSVNでexcelやwordファイルのdiff見たら、Office自体の
>>241 あのさ、差分機能で更新箇所を確認するのは仕事のやり方としては下策で、仕方なくやるものなんだけどな。
プログラミングにかかわらずドキュメントの類は差分ベースで仕事を進めることで効率が著しく向上する
Excel仕様書なんか捨ててMarkdownとかで書いた方がいいこと多いよね
おまえらどこをどう変えたのか毎回忘れて差分比較して仕事してんのかよw
>>248 お前の所は作った本人しかドキュメント読まないのか？
わざと忘れたりするわけじゃないが
>>249 共同作業の場合は更に効果倍増だな
でも、おれは一人でも作業する場合も、差分ベースで作業を進めることが劇的に効率を上げると思ってる
>>247 個人的には AsciiDoc 使ってるんだけど他にお勧めある？
>>252 あんたにとってはgitもレベルが低い仕組みなんだろうな
でもこれが普及して他のツールを駆逐してしまった意味をよく考えてみた方がいいぞ
全然駆逐してないんだけどな
もうgit以外を使ってるのは普通じゃない
>>259 で、gitのことはどう思ってるの？
差分を編集する機能を重視してるのがgitなんだけど
差分機能で更新箇所を確認するのが下策だと思ってる人はこれを受け入れちゃうわけ？
>>260 gitやその他vcsのことを何もわからずに煽ってるだけなんだから、
そんなに難しい質問してやるなよ。無視するしかなくなるだろ。
>>237 亀はだめ
Explorereが劇重になる
>>258 新しいプロジェクトに配属されて、バージョン管理がSVNだったらガッカリするからな
>>236 > Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
ファイルのタイムスタンプだろ？
保存してないよ。
嘘だと思うのなら、ファイルを修正してから次の日にコミットしてみ
ファイルのタイムスタンプじゃないものが保存されるから
>>260 Office製品の変更履歴機能の失敗も知らない世代なのか？
バイナリファイル系は適切なツールを使えば
officeのドキュメントを差分管理ベースで作業できるようにするなら
複数のブランチを切ることがそもそもない環境なら、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の山になって事実上無理ぽそう。
ここで言うことでもないけど
早く画面キャプチャをExcelに貼る作業にもどるんだ
>>275 > それでもXMLだから差分は一目瞭然かなと
え？ お前OfficeのXMLのタグを知ってるの？
XMLのタグを知っていないと、差分は分かっても
その意味はわからないよね？
>>280 > 差分見えてもmergeはconflictの山になって事実上無理ぽそう。
XMLのタグの整合性、つまり閉じタグの対応まで
ちゃんとやらないとだめだからねｗ
タグの意味、属性、誰か解説してる人いる？
Excelファイルのバージョン管理なんて実質タイムスタンプで管理するしかないのに、とにかくGiｔ真理教の信者は
gitがバイナリに弱いのは誰もが認める話だと思うけど、タイムスタンプで管理するのは無くない？
>>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 それじゃファイルの管理しか出来ないじゃんｗ
どうやってアプリのバージョンの管理をするんだよｗ
新しいバージョンへ追加する機能をマージしていくのが
バージョン管理というものなのに
せっかくのボケに対してマジレスしてどうする。
マジレスすると、馬鹿がムキーってなるだろ？ｗ
>>294 なんか勝手にレベルの低い敵を想定して、それをバカにすることで勝ったつもりってのが新しいなw
情けないにも程があるw
>>302 そうじゃないよ。もっと面白いことを言ってみせろってことだよｗ
>>294 ぐらいの内容は想定済みだからさ
>>296 そんな間抜けな機能を実装してどうする w
svnはバックアップツール的な役割で当分生き続けると思う
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なのだ
gitに限らずコイツらの布教活動が成功したためしなどただの一度もないけどなｗ
>>323 自分がいいと思ってる、使っているものが正しいという阿呆がなんにでもある。
世界を自分(たち)にとって都合の良い方向へ変えようとする活動が布教
VCSは頭の良い奴にしか使いこなせない
言ってもいいんじゃね。
>>332 わかる
特定のflowを絶対正義だと信じて「git pull --rebaseしないのは馬鹿」とか言い切ってくる奴とかなー
あるある大事典：
gitの話ばかりしてるから、(gitに対して嫉妬してる)svn(ユーザ)のスレかと思ったら、git(信者がのさばってる)スレだった…
SourceTreeって重くね？
branchだけしてcheckoutし忘れ
>>342 つgit checkout -b new_branch
git stash popは危険なコマンドだと思いませんか？
マージ失敗したらdropされずに残るので、やり直せる
大抵の手違いは元に戻せるのがgitのいいところなんだけど
ファイルスタンプは手違いで発生するものじゃないからねｗ
いつまでタイムスタンプの話続けるの？
リーナスにタイムスタンプ入れるとかアホって言われたのが
インターネットみてると「マスターをチェックアウトして」とか
自分がブランチに出たり入ったりするというのは斬新な見方だな。ホテルかよ。
>>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&*
"マスターへチェックアウト"との一致はありません。
ごめん、結構いたわ。
コンフィグのここで疑問なんだけど
ブランチを切る ってどっちの意味？
もしかしてrefs/heads/masterはローカルを指していて
refs/heads/masterはリモートを指してるらしい、
>>368 refs/heads/masterが、masterという名前のブランチの正式表記で、originのリモートリポジトリの別名表記ってだけじゃないの？
tagにも同じ名前を付けられるからコンフィグは正式名称の方が都合がいいし、
リモートリポジトリは参照するサーバーやリポジトリパスが変わることもあるし、同時に同じリモート名は付けられないから別名表記の方が都合が良い
ってことだと思うけど。
ホテルから出ることをチェックアウトと言う
SVCとかSubversionとかVSSだとリポジトリからファイルがチェックアウトされて
>>373 おっさんは色んな環境・用語に晒されてるから、VCSみたいな同じような機能にそれぞれのアプリケーションで別の用語を割り当てるシステムだと、ごっちゃになるんだよ
gitのタイムスタンプは記録されてないけれど
>371
>>375 実行権限のみ
いろんな人がいろんな環境でチェックアウトするのだから
グループやその他のパーミッションは記録する意味がないし、
umaskの設定に従えば十分
また自分自身がチェックアウト（＝書き込む）ファイルなのだから、
リードオンリーにすることもできない。
よって実行権限のみ記録するのが
バージョン管理ソフトとして正しい仕様。
gitもそれに従っている。
正しい仕様、みたいにすぐドグマ化しちゃう人って柔軟な発想ができなくて開発者としてはポンコツなんだろうなあ
>>380 これわかるわ
正しいとか正解とかそういう言葉を頻繁に使う人は状況に応じた選択ができない
>>380 同意
明確に条件が限定された状況で、考え抜いた上に「正しい」とか言うのならわかるけど、バージョン管理なんてソフトウェアのソースコードに限ったとしても
ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに、自分の知ってる範囲だけで決めつけちゃうのってダメだよね
お客さんの要求の本質を汲み取ろうとせず勝手に自分の都合で判断してそう
>>378 > 所有者くらいは記録してほしかったよね
所有者とは？ 会社名？ｗ
一行ごとに誰が修正したかは記録されている。
その話をしていないということはお互い理解しているという前提で
なんのために所有者を記録するの？
>>384 > ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに
ぜんぜん違うと言うものの具体的な例を
君はこれから言わなくてはいけないということになったんだが、
できるかい？
それができるまでは、ゲーム、組み込み、Web、業務システムで
求めるものに違いはないという今までの常識通りでいくからさｗ
信者というと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標準のバックアップ機能でもできるよ
ソースの版とリンクしてる
>>423 結局これが一番困るよな。
テキスト以外なくても困らない開発だったらいいんだろうけど、そうじゃないものも多い。
大きなバイナリファイルのバージョン管理が本当に必要ならべつにリポジトリに入れてもいいんじゃね？
>>423 そんなもんファイル名、もしくなディレクトリ名を別にしておいて
参照先の名前を変えれば済む話だろう？
>>427 済まないから困るんだろ、勝手に問題ないケースに置き換えて話するのはおかしいでしょ
画像リソースまでソース管理から除外するのかよw
俺はできる限りはリポジトリに入れるけど。
>>427 参照先の名前変えるってなにそれ？
管理したいバージョンごとにファイル名やディレクトリ名を変えるの？
>>432 ファイル名やディレクトリ名は最初に作ったまま固定変えたりしない。
ファイルサーバーは原則として追加するだけ。
そして新しいリソースに更新したければ、
ソースコードの設定ファイルをいじって、
参照するファイル名（ディレクトリ名）のパスを変更する
パスを変更するってことはディレクトリ名かファイル名かは変わってるんじゃないの？
>>434 ファイルは追加するだけなんだから、最初から別の名前にするしかないだろ。
中身が違えば、それは別のものだ。
結局ファイル名に日付入れて管理しろと言い出すわけだな。
ソースコードはGitで管理して
>>436 > 結局ファイル名に日付入れて管理しろと言い出すわけだな。
> gitいらないじゃん。
だからバージョン管理システムは、ファイルの版ではなく、
ソースコードのバージョンを管理するものだから、
バイナリにはgitいらないって言ってる。
人の話聞けやｗ
gitはソースコードを管理するためのものだ
ソースコードじゃないものを管理するものじゃない。
巨大なバイナリファイルをいれんなｗ
Git LFSはすでにVersion2.0.2でGitHubもGitLabもGit LFSに対応済みなのに
Git LFSは "別のツール" だぞｗ
>>442 別サーバーにする必要はないよｗ
同じサーバーで2つのツールを動かせばいいだけ
gitサーバーとファイルサーバーの2つ
何がありえないのかわからん。
>>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 バージョン管理ソフトはソースコードを管理（＝マージなど）するもので
それができないのなら入れる必要はない。
入れてもいいけど入れる必要はない。
大きいバイナリなど入れることで問題が起きるのなら
入れないほうが良い
画像リソースなんてソースファイルみたいなもんなのにいちいち分離してられるかよ
バイナリはファイル名でバージョン管理したい人みたいだからもうほっといて差し上げろ
ファイルを管理するためにgitを使うんじゃなくて、
>>383 >ファイルを管理するためにgitを使うんじゃなくて、
>gitを使うためにソースコード入れてるだけの人だよね。
>開発してるわけじゃないんだよ、git使ってるだけ。
こいつバカかw
好きに使え。
バックアップツールとして使いたいなら
プログラムに内蔵されるリソースの話をしてるのに、
画像リソースで話が通じないんだもん
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. ファイルの更新日付が変わってないのにウイルスに感染していた。
これでわかる？
なんか知らんけどいちいちアーカイブ作ってんの？
>>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に求めるもんじゃないだろう。
>>510 > もともとタイムスタンプが保持される方が便利な用途もある。
ソースコードにおいてはタイムスタンプは、便利便利じゃない以前に
ファイルを更新した時間でなければいけない。
ソースのコミット時間であってはならない。
これはMUST、絶対的な要件だ
checkoutなどでファイルを変更したならば、
その変更した時間（つまり現在日時）にならないといけない。
そうしないとソースコードは適切にビルドできないし、
ビルドを必要としないスクリプト系でもソースコードが
修正されたタイミングで内部的に再コンパイルするものがある。
今あんたが気づくべきは、俺がソースコードに限定した話をしているってところだ。
ソースコードを管理するツールだから、そういう設計になっている。
メタデータをコミット時に保存してチェックアウト時に復元できるような別ツール使えばいいんじゃね
ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
>>524 ビルドの度に全ファイルハッシュ計算して保持とかわざわざ遅くなる割にメリット殆どないような事をするわけがない。
メリットがあるのであればそんなに難しい事じゃないんだし既に存在して知られてるよ。
>>524 >ビルドの件はビルドツールがタイムスタンプじゃなくハッシュ使えばいいっていう話もある
そんな話どこにあるんだ...ビルド時間が無駄に増えるだけに思えるんだけど、何かメリットがあるのだろうか
>>525 > どこにハッシュ値を保持しろと？
全くそのとおりだなｗ
ビルド前のファイル ・・・の日付
ビルド後のファイル ・・・の日付
両方共ファイルの日付という情報を持っているからこそできること
お前ら必死だな
それは違う
>>529 IDEのビルトインも含めてビルドツールいままでどれだか作られてると思ってんの？
で、それらすべて素人が作ってると？
素人が作ったって言ってんじゃないよ
おまえらがバカにしてる納品物のタイムスタンプを気にしてるやつと考え方が同じだって言ってるの
Googleはタイムスタンプベースじゃないビルドツール使ってるけど
「何かメリットがあるのだろうか？」って聞いてこいよ
https://bazel.build/versions/master/docs/bazel-user-manual.html#correctness むしろタイムスタンプで十分なものをわざわざ遅く無駄にメモリとストレージとIO帯域を浪費するような実装しようとするほうが余程のマヌケか素人
>>532 タイムスタンプを使わないとは書いてないぞ？
タイムスタンプとファイル内容と書いてあるぞ？
>>532 それ、デフォルトでタイムスタンプ使うと書いてるけど？
>>534 ファイル内容というかファイルの依存関係だね。
既存の大抵のビルドシステムとやろうとしてることは同じ
bazelを含めたビルドツールがタイムスタンプに依存しているのは
だってファイルシステムのエントリに保存されてるもの
ビルドに依存関係のあるファイル（中間成果物も含む）をすべて最新のソースに反映済みかビルドツールは確認しなくちゃまずいと思うんだけど、
>>520 タイムスタンプを保存したり復元するツールはそれなりに使い所があるかもしれないが、gitに含めない方が良いよな
ひとつのツールに機能を盛り込みすぎない方が良い
「Gitを部内で普及させた方がいいですよおー」
>>541 今でさえいい加減多機能すぎなのに、タイムスタンプを戻すスイッチのオプションが増える
ことが「機能盛り込みすぎ」と言えるだろうか？
バックアップからコピーしても
>「Gitを部内で普及させた方がいいですよおー」
>>539 話は簡単。
ファイルのハッシュを使ったほうが完璧だが、
それはタイムスタンプを戻す理由にはならない。
信者が納品にまでgitを使わすことを強制しててワロタ
>>548 git archiveといって、納品とかに使える機能すら
gitは用意してくれているよ。
そういう意味ね。納品にgit強制＝git archiveを使う
あ、一応説明しておくか。
知らんけど
>>534 タイムスタンプにだけ依存してるツールと
最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
Bazelはファイルシステムでハッシュ持ってる場合はハッシュ比較を先にしてmtimeの比較はしない
mtimeで比較する場合もその後ハッシュで比較する
Google内部ではカスタマイズしたファイルシステムを使ってハッシュを保存してるからタイムスタンプに依存しない
>>525-528 この辺のやつは既存の慣習や制約の枠内でしか物事を捉えられない脳みそだから
タイムスタンプ君と同類 いい反面教師
>>552 デタラメばかり言ってんじゃねえよ
だいたいファイルの内容量のハッシュを保持するファイルシステムがどこにあんだよ
>>552 > 最適化のためにタイムスタンプを使うことがあるツールを一緒にするなよ
一緒にしてないぞ？
最適化のためにタイムスタンプは、コミット日時ではなく
最後に変更した日時になるべきだって話をしてる
>>553 内容量？
Googleが使ってるのはクローズドソースだよ
>>554 は？
タイムスタンプ君？
>>555 ファイル内容のハッシュを
そんなファイルシステムがGoogle社内に存在しているという根拠ぐらい貼れよ
ソースを管理するためじゃなくてgitを使うためにgitを使う信者が、
>>557 そんな話をしてる奴居るか？
ちなみに俺は一度もgitの話なんてしてない。スレ違いのビルドツールの話をしてるぞ
gitは完璧である
>>555 > は？
> タイムスタンプ君？
なんだそりゃｗ
反論の一つも言えなかったのかよｗ
>>559 マヌケだなｗ
こちとらgitはソースコードのバージョンを管理するためのツールで
バックアップソフトが欲しければ、そっち使えという、
すごく当たり前の前提において、
ソースコードのバージョン管理ソフトはどうあるべきかを語っているだけなのに、
そうか。あのバカ、gitをバックアップソフトだと思っていて、
gitにないものは、gitの機能不足だと思ってるんだ。
>>557 > たかがタイムスタンプすら保持できないという話を出されただけで
タイムスタンプを保持しないのがバージョン管理ソフトとして
正常な動きですからね。
>>543 タイムスタンプを戻すのはバージョン管理とは関係ないから盛り込み過ぎだな
必死な人っていうのは、
まあ本当に必要だと思うなら git コミュニティーに投稿すりゃいい話ではある。
>>566 昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
絶対に入れることはない。とピシャリと言い放ったからな。
ここで愚痴るしかないだろうさｗ
bazelは「同じ」ソースファイルからは「同じ」成果物が生成されて、
タイムスタンプ比較した方が早いのに「ビルド時に毎回ハッシュ計算するからタイムスタンプ戻せ」って
ファイルのビルド依存関係は完全に把握していることが前提で、
>>568 > そのために、この「同じ」にはタイムスタンプがなるべく関係しないようにしたいという感じなのか
違う。bazelでもタイムスタンプが違えば違うとみなすが、
それに加えてファイルの中身まで見てるってことだよ
タイムスタンプが違ったら違うかも？って判定して、
ビルドを最小限にするにはタイムスタンプの違いだけでビルド開始してたら話にならんし
gitにタイムスタンプを入れるな派はソースファイルを考えていて
>>567 >昔gitコミュニティーに投稿して、いろんな人がバージョン管理ソフトに
>タイムスタンプを保持するのは間違いだって丁寧に説明しているのに話を聞かず、
>入れろ入れろとあまりにもしつこいから、リーナスがブチ切れて
>タイムスタンプを保持する理由も言えないようなヤツとは話にならん。
>絶対に入れることはない。とピシャリと言い放ったからな。
それ単にリーナスの尻馬に乗って俺スゲエって言いたいだけちゃうかと
少なくとも「間違い」とか「正しい」なんて言えないだろ
タイムスタンプ入れろ派も（上見ればわかるけど）それをデフォルトの動作にしてよみたい
>>575 なんでそんなすぐバレる嘘つき続けるんだ？
それ単にFUSEを通してバージョン管理システムにアクセスするだけでファイルシステムじゃないじゃねえか。
これがファイルシステムだと主張するならgmailすらファイルシステムと言えるわ
ぶっちゃけdiffしか見なくね？
>>574 > 入れろ派はdiffで差分確認出来ないファイルを考えているんだよね?
何も考えてないだろｗ
その証拠にタイムスタンプを入れることで
どんな問題が解決するのかを言えていない
で、タイムスタンプ信者は何でタイムスタンプ入れたがるの？
さんざん上で出てんじゃん
出てなかったはずだが？
あくまでソフトウェア開発の道具としてgitを使う層と、gitを使うのが趣味でそのために適当なテキストファイルを書いている層とがいるから話が噛み合わないんだよな
開発の道具（道具だから開発時に使う）のと
>>588 適当なテキストファイルを書いてるとタイムスタンプがどう役に立つんだ？
>>591 >>592 え？じゃあソフトウェア開発にタイムスタンプ(を戻す機能)がどう役にたつんだよ
同じ意見同士で喧嘩すんな。
>>594 お前とは同じ意見だけど、
>>591 と
>>592 と同じ意見とは思えないけど
なんで実装するべきかそうじゃないかで喧嘩が始まってしまうのか理解できない
>>596 自分で作るという話ならば、hookでやる方法なんてすぐに思いつくので議論の余地はない
>>597 hookで実現するかどうかを議論するということではなく、もし、タイムスタンプの管理が必要なのに自分でhookを書けない人が居るんだとしたら、
素直にどういうふうにhookを書けばいいか相談するなり何なりすればいいのにね、ってこと。
自分にとって必要なのに機能がない、に対して
1. ツールを工夫して使って代替する方法を考える、相談する
2. 他のツールを探す
3. ツールに追加機能を実装して採用してもらう
4. 機能がないことを盾にそのツールを頭ごなしに否定する
あたりの選択肢があるっぽいけど、どうして最も建設的でない4を採用する奴がいるのかな？って思っただけ
>>596 建設的な議論をしたいんじゃなくて
ただたんに文句言いたいだけだからな。
少なくとも
git タイムスタンプ
とかでググればけっこうやり方はでてくるよ。
エクスポート時に全部同じ日時になるのって
>>599 gitのhookで解決する方法がググれば出てくるのに、それでもなにか言いたいんだとしたらhookを使うことには実務上の問題があるのか、
ググって出てきたやり方には欠陥があるのか、何かしらググった結果では満足できない合理的な理由があるんだと思ったんだけどな。
嗜好品だったらともかく、実用品を実用上の問題以外で批判することが、その人にとってどういう嬉しさをもたらすのか全くわかんないわ。
いちゃもんつけられる俺スゲー君はどこにでもいるから
長文アスペ信者君を弄って遊びたい奴が一人か二人いて、
>>602 ということは、タイムスタンプで管理することを仕事かなんかで強制させられて、諦めてそれに従うんじゃなくて、タイムスタンプに意味があるんだ！なんとなくだけど！って思い込んでる人がいるってことかな
言語の話なら一長一短あるだろうし具体的にこの機能はこんなに素晴らしい！とか指摘できると思うんだけど、タイムスタンプ管理のメリットってのが全然語られないし、
むしろ、メリットデメリットで主張してるのではなく、そう決まってるから従わざるを得ないというところを有耶無耶にしているような印象があるんだよな。
まぁ、
>>604 の言うようにバイナリかタイムスタンプネタで遊びたいやつが居るだけの可能性も高そうだけど。
単純にタイムスタンプっていうのは、ファイルを最後に変更した時間なんだから
>>607 そのファイルをその内容に変更した時刻のことだよ。
Windowsでファイルをコピーしたことない？
タイムスタンプも一緒にコピーされる意味を考えてみようよ
あと、「makeがタイムスタンプを参照するから」 という回答もおかしいよね。
WindowsでもLunixでもMacでも
gitがタイムスタンプを復元すると言うのは
まぁひとつだけ言えるのは、git cloneでコミット時刻が復元されたら俺はうれしいってことかな。
>>612 bazelがファイルの内容を”その”ファイルシステムの変更検知に使うなんてどこにも書いてないんだけど、嘘つきに騙されちゃったの？それとも本人？
あーgitにタイムスタンプ復元機能があれば完璧なのにー
gitがタイムスタンプを保存しないのは
>>610 > 『makeは、ファイルの更新日付なんか参照せず、ファイルの変更を検知すべきだ』
ファイルの変更を検知するためには、変更前のファイル情報を持ってないとダメでしょｗ
>>609 > Windowsでファイルをコピーしたことない？
いまコピーの話はしてない。
同じ名前で内容を変えた場合の話をしている
内容を変えたのであれば、内容を変えた日時になるのは当然でしょｗ
>>621 変更前のファイル情報を持ってるツール使ってないのww
>>624 最初から、更新前のファイル情報がないツール前提の話でしょ？
>>623 じゃあ内容を戻したら、日付も戻せよ
という話でしてね
ふう、gitにタイムスタンプ復元機能があれば完璧なのにー
>>629 gitは内容を戻すことは出来ない。
任意のコミットをcheckoutするだけ
では僭越ながら
はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？
他の人はネタでバカ言ってるけど
>>634 だけ普通のバカだな・・・
いや、流石にsvnでもタイムスタンプは戻せん。
タイムスタンプ機能があればいいのに、ライナスも意地になっちゃったんだろうな
澁谷 恭正 (46歳)
死ぬまでには出来るだろうと思ってずっと待ってると先に死んでしまう
時間は不可逆だって時をかける少女で言ってた
伸びたら洗うの面倒だし、髪切るのもただじゃないし時間もかかるし、夏は暑いし、ない方が楽じゃね？
gitでタイムスタンプを戻すことが出来るようになる時間線では、さらに遠い未来ではgitで時間を戻せるようになるまで拡張される。
オカルトって、初っぱなの論理の飛躍に気づかないと、
Gitは最近やったコミットの改変、つまり歴史改変ができるじゃん
ﾌﾟﾚﾐｱ見れない
すいません。分からないので教えてください。
>>671 その方法ほしいよな。マージの順番に依存関係をもたせたい
プルリクがマージされるまでは、そのプルリクのコミットを前提にしたコミットはプッシュしたら駄目なんでしょうか。
プルリク出した修正や追加を前提としたプルリクは最初のプルリクがリジェクトされたときに同時にダメになるわけだからよくない。
先のプルリクがマージされたら、後のプルリクのFile Changedが変わるかと思ったけど変わらなかった
>>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はファイルの所有者情報を記録するけど
>>714 なんのためにディレクトリがあるのかわかってる？
gitはディレクトリ情報は保存するぞ
>>718 そうやって煽ってもいい加減つまんないぞ
タイムスタンプと寸分違わず同じ流れでよく飽きませんね
そういうことに、したいのですね。
レス：1-200 201-400 401-600 601-800 801-1000 ALL
このスレへの固定リンク： http://5chb.net/r/tech/1486239735/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Git 15©2ch.net YouTube動画>8本 ->画像>1枚 」 を見た人も見ています：・Git 13 Git 16 Git 17 Git 18 Git 20 Git 19 【PC】Dead by Daylight Part831【全スレ転載禁止】 Epic Games Part12 乃木坂8頭身選手権 ひとり用wikiソフト ラヴィット！part3 Epic Games Part17 Git 17 (IPなし) 矢沢永吉 Part254 DIYソフトウェア Google Pixel・Pixel XL Part10 Epic Games Part20 Epic Games Part35 ラヴィット！part2 Epic Games Part27 UMIDIGI F2 Part1 Flightradar24★42 ラヴィット！Part2 ラヴィット！part2 Epic Games Part40 ラヴィット！part1 Twitter吹奏楽界隈 Epic Games Part39 GOT(girls on top) Timeworn Clothing UMIDIGI F1 Part23 ラヴィット！part1 ラヴィット！Part4 ラヴィット！part4 ラヴィット！Part.2 ラヴィット！Part.3 ラヴィット！Part.1 FITGRNDOD部リ ★14 Java 高速GUI SWT 3 ラヴィット！Part.2 UMIDIGI F1 Part13 ラヴィット！Part.2 .NET MAUI HighSchool フィギュアスケート★男子シングル Part1012元ID無 田舎者なのですが、秋葉原・池袋・新宿・渋谷は今どうなってるんですか？ ゴーストタウン？それとも普段どおり？ こんなソフト作って！【その１】 Microsoft Silverlight その9 C++/TemplateMetaProgramming 【イマージュ】Image総合スレPart1【最高】 【2023】MotoGP総合560周目【オランダGP】 Windowsタブレット総合 Part82 C++触っていればUnityはすぐ理解できる Microsoftが作った言語かなり優秀な模様 サイトを作ったんやがSEO対策って具体的になんや？ How to do Math in programming 【VR】SteamVRソフト総合 Part57【Vive/Rift/WinMR/Pimax】(ﾜｯﾁｮｲ有) BrainFuck Part.3 <[+-.,]> 【TDD】テスト駆動開発【TestFirst】 オブジェクト指向ってクソかよPart5 MacでもLinuxでも使えるVisual Studio Code 大学生になったらIT企業でバイトしたいんだけど GPT3.5を使って何か面白そうなAIを作りたいんやが Cygwin + MinGW + GCC 相談室 Part 8 ブックマークレット【 JavaScript】
19:32:25 up 9 days, 9:54, 0 users, load average: 83.86, 95.16, 97.29
in 0.14769697189331 sec
@[email protected] on 110108
ブックマークへ