Git 18
レス数が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 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured フライドポテトやポテトチップを指でつまんで食べてたら
指がもう油で git git あーめんど(amend)くさいからな、箸でつまむの gitの使い方は分かったけど、何をコミットすればいいの コミットってのはな、生半可な気持ちでできるもんじゃねぇんだよ
絶対に達成するという強い思いが必要なんだ >>10
コミットの時点ではいくらでもやり直し可能 >>9
ハロワしか書いたことなんですが、そんなのもコミットしたほうがいいですか
ブラキリしたほうがいい？ スクリプトからhttps urlをgit cloneしたいんだけど、この条件を満たせるパスワードの渡し方ってないのかな？
- 実行時にユーザー入力を求めない
- コマンドラインにパスワードが見えてしまわない
- ユーザー側の credential.helper 等の設定は変えない >>12
コード変更して動作がおかしくなってしまっても簡単に元に戻せるからコミットしたほうがいい >>14
expectとかパイプ使って渡したらどう。
スクリプトにもパスワードとか残したくないなら、
opensslでも使って一段階暗号化したら。 github使ってたらprivateでもmsには丸見えで、パクられる可能性ある？ パクられるかどうかはともかく、中身は見られると考えておくべき 企業が使いたがらないわけだ
うちの会社もシステム管理部がサービス提供してるからGitHubは使ったことないわ >>19
>>12 でハロワしか書いたことないと言ってるけどなにコミットしてるの？ >>14
ありがとう。
やっぱりgit自体には機能はなくて外部でどうにかする形になっちゃうか。 >>22
環境変数あたりに設定できないのかと思って調べたら無くて、その代わりにGIT_ASKPASSという環境変数の存在を知って
これ使えば環境変数に設定した情報でログインできるんじゃなね？と思って調べたらこんなのが有った
https://stackoverflow.com/questions/68344358/git-askpass-with-user-and-password
ホントに使えるかどうかは試していない スクリプトから動かすこと前提なのに、他のツールに依存するのが嫌なのかい？
bashなのかpsなのか分からないけど、問題はなんだろう。 >>23のシェルスクリプトの中から exec printf $PASSWORD とか exec echo $PASSWORD やるとコマンドラインにパスワード書くのと一緒かな？その辺も確認必要かも rebaseしろとか言うガイジ会社たまにあるよなｗ
こんな機能そもそも要らないだろｗ
強制プッシュも気持ち悪い rebase 無しで git 使うとか頭おかしい。
何のために git つかってるんだろう？ rebase -i
でsquashできるのは必要だろ rebaseにもいろいろあるけど -i が有用なのは間違いない
ある程度神経質な人でもマメにコミットする習慣を促進してくれる
実際に rebase -i を使うかどうかは無関係に コミットしておけばよかった、しなければよかった
これがなくなる
迷わずコミット等をすぐ実行すればいい
訂正したくなったらなんでも軌道修正できる
gitの中心的価値だと思う >>23
これだ！ありがとう。
でもGIT_ASKPASSに設定できるのはファイルだけでコマンドラインはダメなのか。
windows/linux両対応させようとするとちょっと面倒だな。
>>25
sh組み込みコマンドのechoを使う分には大丈夫そう。
仮にもし見えていたとしても一瞬なので問題はなさそうです。 rebase まともに使いこなせない奴は git 使えるとは認めん。svn でも使ってろ。 >>32
用途によってはこの辺も注意する必要ありそう
https://qiita.com/magicant/items/5c8346ce4781f0fe7dce
＞ Git のコンフィグで credential.helper が設定されていると GIT_ASKPASS 環境変数よりもそちらが優先される。
ユーザに使わせるのなら、ユーザがグローバルにcredential.helperを設定している可能性があるから、リポジトリ単位でcredential.helperを無効にするとかの必要があるかも >>34
credential.helperの設定がcacheの状態で試して問題なかったから、たぶんhelperの設定で
パスワードが要求されない場合はGIT_ASKPASSが使われないということじゃないかと思う。
とりあえずうちの使い方では問題なさそうだった。 mergeの代わりにrebaseするのは現実のワーキングツリーに存在したことのない状態のコミットを作り出すという点で最悪の詐称行為
push前に連続した自分のコミットをまとめる目的だけに使うならセーフ >>36
push の前にも何も、共有リポジトリを rebase するやつなんていないよ。
rebase は個人の作業リポジトリ >>37
リモートを取り込むときに可能ではあるけどするなと言っているんでしょう pull --rebase もその意味では問題ないな テストをする前か後か、公開する前か後かだけが重要
個人のローカルにおける正しき歴史的事実がどうだったかなんてどうでもいい rebase使ってるバカ結構いるんだなｗ
mergeだけで事足りるやろｗ
ツリーを一直線にしたいとかバカみたいな理由で使う奴がいるから笑えるｗ 前も君みたいな発言しているやつ居たな
問い詰めるとリベースの使い方理解する前に適当に弄って
元に戻せなくなってたアホだった 普段からやってる作業手順
1) 個人リポジトリに作業ブランチを切って試行錯誤。がんがんコミットする。
2) 完成したら機能ブランチを切って rebase
差分を統合したり分割したり順番を入れ替えたりゴミ履歴を取り除いたりコミット・メッセージを分かりやすく直したりする。
後から履歴を確認した時に何のため差分か分かるようにするのが最重要。
3) 綺麗になった機能ブランチを公開(push)して他の人にも確認・テストしてもらう。
4) 問題無さそうなら機能ブランチを現在の master の先頭に rebase して最終テスト
5) 機能ブランチを master に fast forward でマージ。
4) の rebase は機能や履歴によっては特別な意図があって rebase せずに 3way-merge することもあるけどレアケース。
2) の rebase はほぼ必須。一発で完璧なコミット作れるような単純変更以外は常に必要。 個人リポジトリにブランチ切る理由ってなんなの？
その個人リポジトリでどんな失敗してもリモートにはなんの影響もなんだし
ブランチを切る理由がわからん masterだけで作業するより便利だからじゃないかな えっと rebase どころか branch 使えないやつが湧いてきた件について。
一つ教えてやる。 git はブランチ切って損することはない。何か始める場合は常にブランチ切れ。 masterブランチだけで仕事が済むのは幸せなことだよ
頭使わなくてもいい簡単なコードしか書く必要がないか、非効率にダラダラコード書いても怒られないか、もしくはすごく優秀で完璧なコードをサクッと仕上げられるとか >>44
ローカルでブランチ切って少しずつコミットすれば、部分的に失敗しても成功した部分は救えるだろ。
実装中に他の実装・機能を試してみたくなっても、新しくブランチ切れば今までのコードの開発履歴を残しておけるだろ。 >>46
強いて言えばgot branchの結果がウザくなるから定期的に消すかcloneしなきゃならんことがデメリットかな ブランチむっちゃ作る
コミット1つ作るたびにブランチ1つ作る勢い >>49
clone するのは知らないけど、名前の付け方を工夫することで branch がたくさんになっても --sort とか <pattern> match (複雑なら grep でも) とかで何とかなるよ。
正しい名前になるように頻繁に名前変えてる。作業ブランチだと名前に日付入れたりもする。 >>48
それってソフトの設計の仕方間違えてない？
部分的な失敗が全体に影響を及ぼすなんてスパゲッティかよ >>53
言っている意味がわからない。
お前は複数の機能を実装するとき、機能ごとに分割して開発しないのかね？
あるいは開発途中にデバッグせざるを得なくなったとき、開発を保留してデバックしないのか？
複数の機能をごちゃごちゃに開発するほうがよほどスパゲティだろ。 今時納品先にsvnを指定されてめんどくせーって思ってたけどgit-svn使ってみたら便利だったわ
ローカルではgit、push先はsvnで快適に作業できるね >>54の理屈はもっともだけど、普通はそもそも複数の機能をローカルだけで一気に開発したりしないよ
それぞれブランチに分割できるんだったらその単位でpull requestを出して共有ブランチにマージしたらいい
そもそも長期間の巨大な変更をしないなら、一時的に開発途中でデバッグせざるを得ないようなケースはstashで十分 >それぞれブランチに分割できるんだったらその単位でpull requestを出して共有ブランチにマージしたらいい
仮にそれでできるとしても、人によってbranchの方が便利だと思うならそれを否定する理由もない。 >>55
dcommitするとツリー新しく作られるのがなー >>58
さっきdcommitしたけど新しいツリーできてないよ 「運用ルールとかどうでもいいから好きにやればいい 最後に動けば良い」
という意思を感じる >>56
pull request依存か。何らかのツールやホスティングサービスに頼る前提？
>そもそも長期間の巨大な変更をしないなら、一時的に開発途中でデバッグせざるを得ないようなケースはstashで十分
開発途中に一切コミットしないとか信じられん……
コミットに対する考えにマリアナ海溝よりも深い溝があるみたいだ。 >>55
gitのほうが面倒だろ
remoteが更新されたのが分からないし
１秒おきにfetch,diffするスクリプトを動かして、更新されたら関係者全員にラインしてるわ >>62
>>12でハロワしか書いたことないと言ってるけど、そんなレベルで更新が気になるの？ branch は機能ごとに切るもののと思い込んでるやつがいるな。
ローカルの branch は作業ごとに切るものだよ。
同じ機能でも複数の実装方法がある時に両方作って性能とかを比べてみたいとかあるだろ。
複数の作業が並行して走ることなんて普通だし、思いつきで試してみたくなることもある。
コミットの整理する時に整理前の試行錯誤とかを別に残しておくとかも普通の使い方。 >>62
1秒おきに更新が気になるとか、病院に行った方がいい
gitの方がはるかに便利だよ
>>64みたいな使い方はsvnでは出来ない >>64
思いつきで試してみたくなることなんてないよ
実際には設計が終わった時点でJOBは完了だろ
コーディングは設計とおりに行えば、いいだけだからコーダーは全く頭使わないのが普通 >>66
お前VSCodeスレでも同じこと書いてるだろ
最近TortoiseSVNをTortoiseGitに変えたメモ帳コーダーさん？ >>62
そういう用途にはhook pre-commitとか使わねえ？1秒おきとかCO2を増やした犯罪に近いな またこいつだったのか
こいつの言動には一貫して理解力の低さを感じる
svnも人の更新が勝手にローカルに降りてくるわけじゃないのにまだ分かってないのか
svnを使っていたときに更新コマンドを実行していたのと同じ契機でpullすればいい
svnはログ見たら最新分かるもん！だから最新常に見えてるってことでしょ？って感覚なんだろうが、それと同じ使い勝手がほしいならエイリアスなりショートカットなりで、ログを見る前にfetchする作業フローにすればいい お前の理解力の無さは神がかってんなー
その「更新コマンド」とやらを発行するのがいつかって話し
もちろん発行すれば、更新されているかどうかは分かる
svnの場合にはアイコンが変化するから、そのときが発行するタイミングだろ
gitは何時発行すればいいんだよ、
今ですか？ｗ アイコンが変化するｗｗｗ
一生 svn 使ってろ。お前には git はもったいない。 仕事で使ってない人はいいな
勝手に止めれるんだからなｗ 自分が今確認した範囲ではクラウド版のGitHubでもオンプレ版のGitLabでもメールやWebhooksでリポジトリの変更通知設定できるぞ まじめな話、新しい技術が理解できないんなら、それがお前の限界なので仕事辞めればいいと思うよ。そうすればお前の嫌いな git 使う必要はなくなる。
お前の同僚もみんな辞めて欲しいと思ってるよ。 アイコンが変化するってアイコンオーバーレイ機能の話でしょ？TortoiseGitでも同じ機能あった気がするけど Tortoiseのアイコン変化は他人が書き換えたことで起こるのではなく自分の書き換えで起こる
この違いすら説明しても理解しようとしない
度し難い >>75
ハロワ通いなんじゃないの？就職できたの？ >>59
あれ？まじか。
おれの環境の問題だったのか
毎度masterブランチ張り替えててダルいんだが。
dcommitするとremotes/git-svnっていうリモートブランチが、同じコミット内容で作られ直されるんだよ。
コミットメッセージが置き換えられて、svnの何番のリビジョンとして作ったっていうリンク(gitkでクリックするとhtmlブラウザが開く)が先頭につく。
なんか設定変えたりしてる？
おれはデフォルト設定のままで使ってて、
気になる点といえば、trunkレイアウトじゃないことだけだな。
ちなみにsvnでcommit(=push)しても作られ直されることはない。 そろそろ新しいソース管理のデファクトが出ないのだろうか
gitで十分だけど >>83
バイナリ差分に対応したのは欲しいね。git強化で十分だけど。 今初めてgitを使った共同開発してる。チームメンバーもあまり詳しい人いなくてみんなで手探り手探り
便利ではあるんだけど例えばこっちの環境では動くのにあっちでクローンしてきたら動かねぇぞとか結構細かいトラブルが頻発する
gitのベテランだとやっぱこういうトラブルって起きないもの？ばっちり運用体制整えればトラブルってなくなるのかな なにがどう動かないのか書いてないからさっぱり分からん 足りないのかクローン出来てないのか環境違うのか全くわからんね エスパーしてみる
Git固有の話ではなくVCSはおろか集団開発のノウハウすら怪しい状況なのかも
ignoreの使い方を理解してないから個人のローカルリソースへのフルパスがリポジトリに入ってるとか そういうトラブルを防ぐために運用体制を整えるわけで gitに限らず開発したプロジェクト一式が他の人の開発PCでもビルドできることぐらいは確認するよな？
ソース管理に不要なファイル(下のURL)に依存してたりするとそれも事故の原因だったりする
https://github.com/github/gitignore/blob/main/VisualStudio.gitignore >gitに限らず開発したプロジェクト一式が他の人の開発PCでもビルドできることぐらいは確認するよな？
と
>ソース管理に不要なファイル(下のURL)に依存してたりするとそれも事故の原因だったりする
>https://github.com/github/gitignore/blob/main/VisualStudio.gitignore
の関係性がよくわからんのだが
ビルドに必要なものはバージョン管理下におけっていうこと？ 中間生成物はリポジトリに置かずにignoreしろってことでしょ
そういえば初心者スレってないんだな
悩む初心者は結構いそうなもんだけど本でも読んでるんだろうか git使ってないとしてもソースコードを他人に渡したり納品したりするときにどうしてんのか考えて見ろってことよ ビルドに必要なものとReadmeとかの説明書は原則バージョン管理下置くことになる。
許される例外は社内で共通認識になってるライブラリぐらい
>>97
バージョン管理に必要なファイルは把握してるか？
ここに書いてるファイルはいらんのでバージョン管理から外すことになる
https://github.com/github/gitignore/blob/main/VisualStudio.gitignore
誰かが x64/Debug に必要なファイルを混ぜてないか？という話 git質問になります。
TortoiseGitのコミット後に復元、あるいはbranchのmarge時の一時的なstachを fsckで拾う事は可能ですか？
何がしたいのかと言うとコミットしていないファイルを事故ってロストしてしまいました。
コミットしていた場合、あるいはstashに退避していた場合、これらをgitから取り出せる事は理解しています。
今回の場合上記どちらも行っていません。しかし直前にブランチをリベースし、コミット後に復元を使用しています。
git的にはリベース時のstach退避も、コミット後に復元のアンカーも(多分stashですよね)、
ユーザーが意識していないだけでコミットしていて取り出せると思っているのですが、ハッシュを見つけられない状況にあります。 コミットしていないファイルをどうやったら復元出来ると思うのかｗ 自己解決しました。ありがとうございます m(_ _ )m
stashはコミットと同等なのでIDが分かれば復元は可能です。 ったく、手間かけさせやがって(なにもやってないけど 変更しようと思ったら毎回リモートからクローンしてきて
変更したらプッシュして削除
でまた、変更しようと思ったらまたリモートからクローンして。。。
めんどくせー 会社の決まりだから仕方ない
コーディング中もインターネットにつながらないパソコンを使用する必要があるし
とにかくセキュリティーが厳しい そういう運用なら普通シンクライアントなんだけどなぁ。
シンクラ運用できないくらいIT部門が駄目なのかね。 gitサーバーをオンプレに構築すりゃいいんじゃないの？ クライアントPCにソースが残る状態がその会社としては怖いってことでしょ
セキュリティは時として理論ではなく感情に基づいて生産性より最優先されるのでどうにもならない
辞めるしかない >>115
クライアントでクローン後に削除してもHDDやSSD上にはまだ残ってる訳だが
ゴミになったセクタ全部上書きも毎回やってないなら片手落ちとしか言いようがない
残念な会社 されてるわ
とにかくセキュリティが厳しい
新人が個人で購入したキーボードを刺して、顛末書書かされてたし。 コンテナみたいな開発機でやったことがあるけどあれはなかなか便利だった
暗号化された永続化領域以外は再起動すると初期化される
pushしないで再起動すると泣くけど毎日キレイに掃除されるのでスッキリ ヤフレカスが下がってるの？
何言ってるのかさっぱり分からないな 僕エスパーだからわかるんだけど、
rc報告するならスレを上げてほしいってことだと思うよ あげろよって書いてる奴がageてないんだから「（俺のために）あげろよ」と言ってるだけってよくわかる
聞く耳もつ必要ないしウザ絡みされてもやむなし 書いてる内容を考えてみろよ
おまえ、会社なんかで「一から十まで説明しないとできない？」
なんてよく言われるだろ そもそも論として rc ごときでスレ上げたりするなよ。 Gitってチームで使うなら
ちゃんと運用ルール含めて全部整備して周知しないと大変そうだな
小規模開発しかしてないからローカルでのGit使ってないけど
大規模開発だとプルリクエスト含めてどういうフローで回してるのかが気になる 世界一大規模に git を使って開発しているグループのやり方が公開されてるので見てくるといいよ。
git の発明者のとこだけどね。
参考になるかは知らん。 グループで利用する場合参加者の最低限のレベルは保つ必要があって
そのためのルール造りが必要と言うことだと思うが
逆にルールに縛られて使い難くしてしまうくらいならルール無い方が良い >>136の想像しているような「全部整備して周知しないと大変」になるようなレベルの人間は、
>>137のいう例のグループではF○ckだのSh○tだの罵倒されて追い出されるだけだから何の参考にもならんよ >>140
追い出されたりしないぞ。
あまりにもレベルが低いやつは黙って無視されるだけ。時間をかけるのすら勿体ない。
悪い言葉で罵られるのは人ではなくて技術に対してなので、本人が相手にしてくれてるのなら、かなり愛のある改善要求だぞ。超忙しい人なのでいちいち馬鹿の相手はしてない。
たいていは周りの親切な人が、丁寧な言葉で「基本を勉強して出直して来い」って言ってくれる。 クソプログラマしかいない会社だと
クソコードが量産されたりしないんだろうか クソコードだろうがガンガン生産性を上げたほうがいいだろ >>145
大昔に、上司から「こんなに短いコードで書いてくるとか許さん。1行あたりX円で見積もって仕事うけてて、ソースコードも納品するんだから、10倍の行数で作り直せ、コメント行で水増しも不許可」って言われたの思い出した。 whileで絶対通らないループ作ってステップ誤魔化した事有るなぁ 最近やたらと「生産性」って聞くけど
そもそもなにを生産してんだｗｗｗ しまった
(ﾜｯﾁｮｲ 7fdb-qJfu) == >>144 == >>150
の自演だったか 仕事でGitを使うようになった初心者ですがオススメの書籍とかってありますか？ >>154
とりあえずこれ見とけって感じですかね。ありがとうございます >>145-147
他人が納品したコードだけど
forで描ける内容がforじゃなくて
制御変数1,2,3,4...と手作業？で代入した上で
全部展開されているようなソースは観たことがある うちの会社なんてのも酷いぜ
//ここが呼ばれるはず
↑
こんなコメントがある
呼ばれるはずってなんだよ、お前が書いてんじゃねーのかｗｗｗｗ
//動的配列を使いたいところだが
↑
こんなコメントがある
「だが」で終わって何がしたいだよ
使いたいなら使えばいいし、
使いたいのに書き方が分からないならそのコメントいらねーだろｗｗｗ それだけじゃよく分からん
後半のやつは、freeの制御が難しいからスタックに置いてパラメータでやり取りせざるを得ないとかあるし、どっちも文脈があるんでないの
それもコメントに残せとは思うけど お前らってどんなソフトを開発してて、gitで管理してんだ？
晒してみろよ
どうせ、ネットに転がってるサルプルコード程度のもんだろ
そんなのフォルダコピーで大丈夫だよ サルプル？
面白いことや皮肉なことを言おうとしたときは噛んじゃダメだろ
5chもミスった書き込みのやり直しができたらいいのにね
そう、Gitみたいにね！ >>161
だからどんなもん作ってんだよ
晒してみろ
どうして自分一人しか利用してないんだろw なんか日本語あやしいやつおるな
レスをgit管理したほうがいいなｗ しょうがねーな、お前にとっておきのヤバいサイトを教えてやるよ
そこじゃ世界中のハッカーたちがソースを晒し合ってシノギを削ってる
その名も……ギフハブだ
かつて薬物で逮捕された大物ミュージシャンによって告発されたんだ
誰にも言うなよ >>165
そんな人たちとお前が同類だと思ってんのかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ え？レスをgit管理してるやつとかいんの？何のために？ ああもううるさいなー
えい
git revert 166 開発の現場でgit(hub/lab etc)が使われてる割合って感覚的にどんなもん？
未だにsvnだったりバージョン管理してなかったりそんな現場がまだまだたくさんあるような感覚なんだけれど
ウェブ系だともう100%gitだったりするのかな >>170
MacのデフォルトがGitだから、SVNからGitに流れたのと、Gitを採用する製品が多くなったのが、Gitが増えた理由。
GitとSVNを比較して決めているところは少ない。 >>170
GitHubもGitLabも仕事で使うと高いから、思っているほどは使われていない。 >>172
業務効率や人材の質と比較して月$48/userを払えない会社はさっさと潰れたほうが良い Githubなら便利なんだろうけど
ケチろうと思えば社内共有サーバーでもどうにかなるやん
リモートリポジトリをディレクトリに指定できるから
git init --bare //nas/repo/MyProject とでもすりゃいける どうにかならんよ
GitだけならいいがCI/CDもローカルで回さなきゃいけなくなる(もしくはセキュリティリスクを負って外に公開するか)から運用がクッソ面倒 gitlabをオンプレでやってるところはそこそこいると思う githubなんて使わずに
git + ssh でええやん >>177
自分たちでやるんなら、それで十二分だな。
ダメダメな WebUI とか不要。 大抵コストは実際のところ本当は問題じゃなくて、予算取るのが面倒だったとかで最初に安易に自前でやっちゃった奴が元凶だったりするんだよな
以後はそれを前提にいろいろ構築されていくから、なんでも自分達でやることになって手間がかかる割に品質が低く機動性も低い開発環境が出来上がる
差別化要因にならない余計な手間は金で解決するという決意表明として、GitHubをまず導入することは重要 後で移行しようとしたときに問題になるのを避ける意味でも、大袈裟に感じても最初からGitHubなど積極的にSaaSを使っておいた方がいい
営業が「うちはソースも自前管理で安全です！」と言って大口顧客の契約を取ってしまったら終わりだからな 外部サーバにつなげられない開発環境ってのも結構あるんだ git clone --mirror
git push --mirror
でリポジトリ全体を簡単にコピれるからオンプレからクラウドに移行するのなんて簡単だよ うーんそんなもんなのか
どこもかしこも今はgitを使っていて、自分はど底辺の現場ばかり回っているのだと思っていた git サーバーひとつまとも運用できないやつが、ちゃんと使いものになるコード書けるとか思えない。
ゴミの履歴管理する必要はないんやで。 うちに常駐してたSIerは自前のSVNを十年間使ってたが、俺がたまたまベンダーコントロールの担当になってすぐにGitHubに移行させた
俺含めプロパーは以前からみんなGitHub使ってたけど、何故か彼らはずっと外部に置いちゃいけないと思い込んでて今まで言い出さなかったらしい
底辺の現場に課せられている(なぜかそういうことになっている)制限って案外そんなもんだよ あいかわらず、GitとGitのホスティングサービスがごっちゃのスレッドw git hubなんて、マイクソからは丸見えじゃん
パクられる恐れがあるから、使用禁止されてるわ SVNからの移行度合いの質問なのにホスティングか否かの対比が論点になってる人がいるのヤバくね
ホスティングサービスを使おうがスタンドアロンで使おうが、ソース管理をSVNに固執してGit等に移行しないメリットはほぼない
でもSVN利用者がGit利用者より損してる実感がなければ新しいツールの使い方を覚えようとしない
そういうのもSIerみたいな社員の目がみんな死んでる組織ではよくあること（偏見）
さすがにファイルサーバーのフォルダ日付でバージョン管理してるのはSIerでももうないやろ 今やってるプロジェクトはsvnだから自分だけgit-svn使って凌いでるわ 尼崎USBじゃないけど
普通は依頼元と情報漏えいの契約結ぶだろ？
MSも入れて契約書作らなきゃな 組み込みもやってるタイプの会社のSVN使用率が異様に高いという経験則がある
なんでだろう？ gnuみたいなハッカー集団(でも|だから)ブランチ使ってないプロジェクトあった
お前らが関わってるプロジェクトなんてGitで管理する必要すらないんじゃないw 有名なオープンソースのソフトウェアでも、開発者が実質一人ってのも結構ある。 >>192
契約があっても心理的障壁の無い馬鹿がどこにでも居て破るので困る 最近の社給PCってUSBメモリに書き込めないようになってるだろ。 >>194
いやそれはどんなタイプでも一緒でしょう >>199
リモートデスクトップ経由だとなんでもコピーできることが多くなった。 USBストレージ禁止されたらスマホアプリ開発やりにくいな 基本的に個人所有の機器類を会社のパソコンに接続できるのんてありないだろ >>204
キーボードやマウスなんかは申請すれば自由だけどな それをやり出すとキリがないんだろうな
従業員が数百人くらいならいいけど、何千何万とかだの
面倒たがらだと思うけど、うちは一切使用禁止だな
充電するために繋いだ新人が顛末書書かされたし >>206
接続は監視するけどポートそのものは無効化しないとか糞みたいな運用だな 1社目 : SIer USBはストレージのみ不可、他は制限なし
2社目 : メガベンチャー 特に制限なし
3社目 : 非ITの大企業 Win機は1社目と同じ制限あり、エンジニアはMac支給で実質野放し
4社目 : 小規模スタートアップ 特に制限なし
俺はこんな感じだったな
Git使うような仕事ならこんなもんじゃね？ >>204
その発想は古い
とにかく古い
そんなのだから、リモートワークに移行できない。 トレンドは普通にTwitterとかでも出てくる一般語だろ
「トレンディー」なら死語代表だからわかるけど
それでもトレンディエンジェルとかでなんやかんや耳にする
20年聞いた記憶がないなら逆におじいちゃん Googleトレンドってのもあるしな
>世界中の検索トレンドをチェックしましょう 今どきtfvcなんて使ってるところにアサインされた。この前はsvnだった
gitが当たり前なんてのが遠い世界に思えてきた。俺の世界はクソだ git自体はすばらしいけど、githubがクソ過ぎて使いたくないんだよなぁ GitはよくてGitHubがクソってよくわからんな
嫌いなら単なるホスティングサービスとして使えばいいだけじゃね msにソースもろに見られんじゃん
大抵の会社はイントラネットに構築して、git hubなんか使わないだろうけど MS批判はともかくとしてだな
ルールでガチガチに縛られてGitHubすら使わせてもらえない職場と、
GitHub等のクラウドサービスを色々使える職場、どっちで働きたい？
俺は迷わず後者だなあ >>221
Enterprise Server 知らないやつって定期的に湧くよな そもそもチームでgit使って開発してます！みたいなところで働いたことすらない。githubなんて夢のまた夢
業務系でgit使ってるところって実在するんだろうか 大手で内製部隊抱えてるとこはだいたいGitHub使ってるぞ >>225
業務で使わずにどこで使うんだよwww
パソコンオタクかよ 個人用にgit使ってるわ
チームだと未だIBMの良くわからん奴つかってるが 個人でなにに使うんだ
会社で散々仕様書やらコードやら書かされて
家でもそんなことしたいなんて思ったことないわ 業務外でプログラミングするのは自分の欲しいツールが無料で見つからない時だけだな >>225
ウチの会社もgit使ってないが、啓蒙中よ
今は自分のPCにホスティングサービス立ち上げて何人かに使ってもらってる
最初はなかなか理解してくれなかったけど、使っていればだんだんメリットを理解してくれて使ってくれるようになるよ github が嫌ならgitlab使えば良くない？ セキュリティFIX
Git v2.37.1, together with v2.30.5, v2.31.4, v2.32.3, v2.33.4,
v2.34.4, v2.35.4, and v2.36.2 >>235
そんな啓蒙が必要ってどんな環境？
自社開発でさすがに今時Gitの啓蒙が必要なんて考えにくいし、客先常駐だったら客の説得が先じゃね
ハードウェア系とか？ >>238
機械制御の自社開発よ
伝統的なzipファイル管理が未だに主流
それでやってきた老人たちは新しいことを覚えるのが嫌なのか、バージョン管理ツール自体を嫌ってる 老害にどんなに啓蒙しても無駄
関わらないのが無難、自分のメンタルが壊れる まあ>>240みたいな奴は結局辞めるんだよ
240が今後十年かけてGitを普及させる間に、GitHubを使える環境にいる同期は遥か先へ進んでいる
自分の時間を無駄にしないことだ Gitの啓蒙と斬新的な改善みたいな肯定感はサラリーマンのメンタルヘルスとモラールと互いのリスペクトに良い影響を与えるので割と侮れないと思う
どうせ無駄だと諦めてる組織は目が死んでる率がより高そう >>243
gitって設定とかテキストファイル形式だから無駄が多い
12345を5バイトで保存とかありえん。
2バイトで十分だろ >>244
腐ったところからはさっさと逃げる
見切りが大事だな >>246
お前ん所って数バイトをけちらないといけないほどディスク容量厳しいの？
そういうやつはバージョン管理とか向いてないぞ。 差分データを効率的に格納してほしいという話かと思ったら設定ファイルの話だったでござる
JSONやYAMLなんかの価値も理解しない人かな
特殊性癖ならディスクまるごと圧縮しておけばよくね >>248
プログラミングしたことない人はそう感じるらしいね 最近のひとは富豪的プログラミング平気でするし悪気が無い 基準のないフワッとした話しても意味なくね
早すぎる最適化は悪って知らんの？ バイナリにはバイナリの強みがあるしXMLみたいな冗長極まるデータ形式にはそれ特有の強みがある
メリデメ考えられないのもヤバくね >>251
ファイル読み込みバッファはchar[1024]ぐらいが丁度いい >>251
組み込み開発者かゲームプログラマーならリソースケチるのはわかるけど… コンベンショナルメモリ640KBでカツカツだったころの話とか分からないだろうなぁ >>256
まあ今はそんなこと知らなくてもいい環境だからね
いい時代だよ コンパイルとリンクの違いも分からないやつばっかだよ
リンカがエラー吐いてんのに、コードやコンパイラの設定を見直してるバカとかww
基本を知らないからちょっと変わったことが起きると対応できない 「イケイケドンドン」だった頃のおじさんの自慢話始まっちゃったよ…
5バイトありえんとか言ってるのも俺の時代はナア！昔は良かったんだヨォ…とくだ巻いてるだけだった >>258
リソースケチりでおっさん扱いされたら今度は別のところでマウントする方向に切り替えるの情けなくて好き git 使ってテキスト形式に文句言う馬鹿が湧くとか世も末だなあ。 >>263
gitはバイナリを使ってるから
gitが廃れたらデータが取り出せなくなる
シェルスクリプトでバージョン管理しろと言ってる
某大学教授（笑）もいる gitは設定ファイルだけじゃなくてコミットした情報も基本はテキスト形式をzlibで圧縮したものだよ
すごく簡単な形式だからgitコマンドなくてもzlibのツールがあればデータは取り出せる
git gcとかしてpackされちゃうと少し面倒なんだけど、このフォーマットも比較的簡単で仕様明解だから、プログラムできるひとなら変換するツール書くのは楽勝 そういう召喚してしまう可能性があるような事は書かないでください >>266
UNIX哲学ではデータはすべてテキストに保存しろと言っている
バイナリを使ってないgitはUNIX哲学に準拠してないし
そのようなプログラムは将来的に淘汰されやすい
論文にもなってる
シェルスクリプトを用いたUNIX哲学に基づくリアルタイム制御
https://www.sea.jp/ss2021/download/11-SS2021.pdf テキスト形式ならgitで効率的に管理できる。
バイナリにしちゃったらgitで管理できんだろ（できなくもないけど効率が悪いという意味で） UNIXでは画像や動画とかもBASE64とかで保存するわけ？ >>269
ユニケージガイジｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
色んなところでロ論破されて今度はここに流れ着いたの？ >>269
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている >シェルスクリプト
また＊ケージ野郎か
ホンマ判りやすいな >>258
>リンカがエラー吐いてんのに、コードやコンパイラの設定を見直してるバカ
-MT や -MD でも？ >>276
そこが本質じゃないだろ
本質を理解していないから、お前みたいな書き込みになるんだよ
会社で「君、一から十まで説明しないと出来ないの？」
なんてよく言われるだろ >>277
いずれにせよコードやコンパイル設定に起因するリンクエラーはあり得るからチェクするのは間違ってない あれれー？おじさんは本質を気にするのに、設定ファイルがテキストであることによって生まれるメリットとデメリットの評価はできないんだよね？
熟練した狭い範囲の仕事を職人的に覚えただけで本質を捉えた気になってる老害さんなのかな？ あそこまで絵に書いたような老害ムーブができるのはある意味才能かもしれない
容量をケチることが今の環境だとそこまで特にならないことを指摘されると急に昔を懐かしんで、今度は全く関係ないリンカの話を持ち出して意味不明なアピール
うーん、役満 gitじゃなくてtfvcなんだけどさ、メインブランチにいろいろなプログラムで使うものを配置して、そこからブランチを切って、ブランチごとに別ソフトを作る
っていう運用してるところに配置されたんだけどこれどう思う？あっここいじってソフト作ってねーみたいな
こんなことしてるところ他にあるかね。というかバージョン管理とは一体 そのスタイルがその組織の運用実態に合ってればいいんじゃね
git subtreeやsubmoduleだってそれぞれに面倒くささやデメリットはある
それもまたバージョン管理 >>281
>>282も言ってる通り、作業のワークフローに合った合理的なバージョン管理に思える
Gitをあまり頭捻らずに使ってるチームだと既存リポジトリからフォークするだろうけど、それは実質的に281のやり方と同じ
ワークフローがそもそも適切かどうかは知らん GitHub使ってる組織なんかはリポジトリを新しく作る心理的障壁が非常に低くなりがちで、
全体的な整合性が全く考慮されないままに小さなリポジトリが乱立する傾向がある
そんな状態に比べたら>>281のやり方は余程優れている
作業セット同士の関係がVCS上で一貫した方法で管理されているわけだからな 小さなリポジトリを乱立されられないことが
大きな大問題なわけで、GitHubは素晴らしいとしか言いようがないよね なにがすばらしいんだよ
msから丸パクリ去れる可能性大なんだぞ ならオンプレでGitHub動かせばいいじゃんか
無知なやつほどうるさいな 趣味で使ってるようなヲタクならいいかもしれないが、
会社だとそういうわけにはいかないんだよ
ひきこもりには分からないかもしれないが >>290
だからMSに覗かれるのが心配ならGitHub Enterpriseのオンプレ版があるよって話 >>292
おまえが使ってるOSを作ってる会社だよｗ >>293
おまえっ？
論理追えて？
頭悪すぎて話しにならん 秀逸な流れだな
締め方も何やら貴族や殿様のような品格を感じる Githubの代替なんて山ほどあるのになんでGithubにそこまで固執して目の敵にするのかわからんね たまに異常なMS悪玉論者いるよね
ネットで変な意見にかぶれちゃったのかな 今となれば余程GoogleやAppleの方が凶悪に見えるんだが
それもAmazonからみれば雑魚に過ぎん 猜疑心と剥奪感と思い込みが強いと嫌儲みたいなルサンチマンを拗らせるんだと思う
NHKも敵視してそう
ヘタしたらビルゲイツのワクチン関係の陰謀(笑)に詳しい人かもしれない 「独立性を重視する」「今まで通り自由に使える」 Microsoftが買収するGitHub
https://www.itmedia.co.jp/news/articles/1806/12/news120.html
Microsoft傘下となっても、独立した運営を続ける方針だ。日本マイクロソフトの榊原彰CTO(最高技術責任者)は
「Microsoftは、創業当時から開発者と歩んできた。GitHubは、開発者がより多くのことをできるようにする『デベロッパーの家』。価値観をともにするGitHubと、開発者を支援する道を選んだ」
と話す。そのために「(Microsoft製のものに限らず)全てのデバイス、クラウドサービス、OSをサポートする」という。
「LinkedInや『Minecraft』開発元のMojangを買収したときも、彼らの独立性を保ってきた。今回もそのように行動で示す。開発者が今まで通り、GitHubの機能を自由に使い、安心してソースコードを蓄えられるようにすることが、Microsoftのミッションだ」(榊原さん) >>294
だからね、GitHubはMSが作ってるんだから
安心して使って良いんだよ
みんなMSを信じてる >>305
だから怖いんだろ
ぱくられるかもしれないのによくpushできるな オンプレ版から盗む機能があったら速攻見つかって非難囂々だろうな。 >>307のコードにMSがパクるほどの価値があるのならそんなブラック企業さっさと辞めてMSに転職したほうがいいぞ まさかとは思いますが、この「MS」とは、あなたの想像上の存在にすぎないのではないでしょうか。もしそうだとすれば、あなた自身が統合失調症であることにほぼ間違いないと思います。 パクられたくないコードを、WindowsやVisualStudioやVSCodeで書いてないよな？ >>307
Windows使ってるんだから結局同じだろｗ
みんなMSを信用してるってわかってないの？ >>307
これだけ論破されてるのによくそれを繰り返せるな 本当にMSがソースを盗んでるなら
なんでAppleやGoogleはいまだにGitHubを使い続けてるんだよ
https://github.com/apple
https://github.com/google >>314
まぁでもそれらはオープンソースのプロジェクトであって、
GoogleやAppleのレベルなら、社外秘なものは自社で管理してるだろ >>314
盗んでるなんて断定して無いだろ
盗める可能性があると言ってるだけで。
おまえももしかして南北どっちでもいいけど朝鮮？ Azure使ってる所も多いからウェブ閲覧はじめ
ネット関係みんなやばそうだから
回線切った方が良さそう 全くゼロリスク信仰は怖いね( ´･∀･)(･∀･` )ﾈｰ
ワクチンも打ってなさそう >>316
おまいさんは自作OSのみ使ってるの？
MSもAppleもGoogle もみんなソース盗む可能性あるぞ 実際どうなん、見られてるならコメントアウトでもstringでもひたすらテロの計画書いたら通報されてつかまるん？ GitHubの話はｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】スレでやってほしいな たしかに枝を切るって言ったら切り落とすことだよなあ
cut off branchesならむしろpruneの説明そのもの
ずっと疑問なく使ってたけど言われてみればセンスのないマヌケな表現で草
切るは多義的だから分岐開始にニュアンスが合わないわけじゃないけど、こと枝を相手には賢いチョイスじゃなかった チケットを切る、からの変形でしょ
チケットとブランチを近い意味で捉えるのはGitのベストプラクティス的にはむしろ良い傾向なのでは
生やしちゃうと長期間生存しそう チケットを切るからの転用の類だとするとやはりセンスないという感想は変わらんなあ
Git公式の訳でもブランチ切るは使われてるけど、英語原文ではissue branchみたいな表現は見当たらない
ブランチ切るはGitがリリースされるより前の時代から慣用的だったからベストプラクティスは牽強付会でしょ
この慣用句が揺らぐことはないだろうし出自の残念さを無理にフォローすることもないのでは 「舵を切る」とか「火蓋を切る」とか
cutではないな 切るは多義的だから分岐開始にニュアンスが合わないわけじゃないと書いたわけだが、伝わらないもんだね 日本語に限らず全ての自然言語は多義的なのに何を言いたいのか 多義的でニュアンスが合わないわけじゃないなら
「branchを切る」はそういう使い方ということで終わりじゃないかな 英語だと単にcreate a branchだから生やすなんていうニュアンスもないし、
日本でも「ブランチを作る」の方が多数派じゃないか？
変なニュアンスを付加しようとすると反発が生まれるので普通に「作る」と言えばよい 自ら続けてきた慣習等に否定的な発言をされると誰しも反射的に反論したくなるよな
にんげんだもの
その感情に名前がほしいと思うことがある まあ俺は言い方変えろとはこれっぽっちも思ってないけどな
枝を切るは草
というだけ 俺は「branchを切る」って使い方をしたことはないけどな
そういう使い方をしたい人は使えばいいってだけ
「切るは多義的だから分岐開始にニュアンスが合わないわけじゃない」んだろ？
草とか言っててもどうしようもない masterなんて切ったら大変なことになるだろ
ボーナス査定でマイナス評価付きそう センスが悪い出自の語句だという論点でずっと話してるので間違ってるかどうかはポイントじゃないんだけどな
メシは食えりゃいいプログラムは動きゃいいみたいなおおらかな感覚の人だったらこういう機微の話は伝わらないかもな
ギガが足りないとか俺も使うことあるけど、センスのない出自の語句である点も含めて言葉のおかしみだと思っているよ
草がお気に召さないなら「枝を切るとはいとおかし」でもいい 令和のブランチカッターと異名をとる○○。
みたいな使い方するのか。 >>338
「切るは多義的だから分岐開始にニュアンスが合わないわけじゃない」のなら
「branchを切る」はそういう使い方ということで終わりなんだから
センスが悪いとか草とか言っててもどうしようもないって話だけどな
「カードを切る」をカードを切断する以外の、カードを混ぜ合わせるとか
とっておきの手段を使うといった意味で使うことに対しても
切断以外の意味で使うなんて草とか言うのかな うんうんそうだねー
トップスにスーツを着てボトムスにステテコを履いたとしてもそういう着方ということで終わりなんだから
センスが悪いとか草とか言っててもどうしょうもないよね
一理ある
後半は何度も繰り返し伝えてるはずのことか全く伝わってないのでもういいや >>342
「ブランチを切る」を切断以外の意味で使うなんてマヌケな表現で草という話だったよね>>326
「カードを切る」を切断以外の意味で使うのは
トップスにスーツを着てボトムスにステテコを履くような着方
みたいで草ということかな すくなくとも俺にはブランチ＝枝のほうが違和感あるが
ブランチを切る で 枝を切る を連想するのが一般的か？ うちの地元だと包丁なんかでものを切ることを「生やす」と言う。 >>343
branch に 切る をくっつけ始めたやつはセンスない
なぜなら昔から枝を切るという表現はcutの意味で通っているから
英語に疎くて枝や支流のイメージがなかったのかもな
口火を切るや先陣を切るといった言葉にはそれがないので全く問題ない
もちろん既に慣用表現になっていしまった「ブランチを切る」を、慣用であるからという前提のもとに自分も使うという判断は全く問題ない（何度も言うが）
カードを切るという表現が生まれた当時の良し悪しについては昔すぎて情報不足で判断保留だが、カードを物理的に切るのはクレカ等を破棄するときくらいなので、どうあれ枝を切るほどには問題はなさそうだ >>346
その「センスのないマヌケな表現」をずっと疑問もなく使っていた ｱｳｱｳｳｰ Sa39-9B/I
>>325がなかったらその後もずっと使ってたんだろ >>347
そういうこと、そんな笑い話よ
ギガが足りないとかも使ってるわけだしな >>348
ｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケということだな
違和感がないから疑問も持たずに使い続けてたんだろうし
それは「始めたやつ」も同じこと >>349
冷静なタイプかと思ってたけど感情的になってるねw
俺はbranchを切るという使い方をしたことないとうそぶいてたけど
こりゃ実はマヌケ呼ばわりされて激昂しちゃったクチみたいだな >>352
センスのないマヌケはｱｳｱｳｳｰ Sa39-9B/I自身という自虐的な笑い話だったんだろ？
だからたしかにｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケだよねと返しただけ では幹に切り込みを入れて接ぎ木をするという視点はどうだろう
いやもうこの話題終わりにしよ >>348
別に自然だろ
「一千万不渡りの可能性」で通じるだろ
わざわざ一千万円の〜なんて言わなくね 一千万円という特定の額が足りないという例では全然ポイントが違うだろ
むしろこういう感じ
あたし食欲ヤバくて最近キロ余ってる
大きなセンチを私にください
週末にキロ出しすぎてオービス光らせた 一千万不渡りの可能性 に相当するのは 最近5キロ増えた
ギガが足りない に相当するのが 最近キロ余ってる ギガが足りないの「ギガ」は使用可能量に相当する概念だとわかるが
キロ余ってるは何？体重がどう余ってるの？ やれやれ重箱系の難癖だろそれ
3つの例文をそれぞれ否定できない時点で反論したいだけやろ
まあ余りについてあまり議論したくないから例文変えるけど「あたしキロがオーバーして最近ブスだからダイエットしなきゃ」ならどうよ
何にどうオーバーしてるんだとかこれ以上バカのフリはできまい
キロがオーバーしているというのは
体重がオーバーしていると理解できたんだよな
美容の文脈で体重オーバーといえば話者の理想体重に対して超過があるという意味だ
まだほかに難癖あるか？ スレから離れ過ぎるなら、他所で。と言いながら参戦するけど、
ブランチを切るの「切る」はチケットを切るの「切る」とは意味が違うぞ。
チケットを「切る」はチケットに挟みを入れて印をつける意味。
ブランチの「切る」は古くは「幕を切る」とか最近？だと「スタートを切る」のようなニュアンスから派生した「継続する物事を開始する」という意味。派生なので本来の「切る」の意味とは違うが広く受け入れられている表現だ。
誤解しやすいからその表現は良くないとうのも一つの見識だが、センスについては人それぞれなので、ここで議論しても結論は出ないぞ。 >>364
↑
会社にいるよな、
こういうめんどくさい奴
陰で、「またはじまった・・・」なんていわれてそうｗ きしめんやラザニア生地に切れ目入れて半分割いて
それを分枝の始まりとするイメージでいた mergeはリモート追跡ブランチからできるのに、pullとかfetchはリモートブランチじゃないといけないのなんでですか？ >>370
mergeはローカルから参照すればいいのに対して
pullやfetchはリモートを参照する必要があるからじゃね？ >>370
pullやfetchはリモートブランチからローカルに情報取得するためのコマンドだからでは >>371-372
ありがとうございます理解できました
>>373
試してみましたがリモートのブランチを指定しないとだめみたいです
origin/dev と origin devは別物でしょうか？
前者をリモート追跡ブランチとして認識しておりますが 訂正です。
引数にorigin/devを指定するとダメで、origin devならOKということがあるので
origin/dev と origin devは別物であるような気はしています。
いくつかコマンドを実行してみて得られた結果から推理したイメージは
①リモートのdevブランチと最も近い位置にあるローカルのブランチがorigin/dev
②リモートのdevブランチを指すのがorigin dev
といった感じです。
git logをした時に確認できるorigin/devは①のorigin/devと同一であり、これがリモート追跡ブランチだ
という理解であっておりますでしょうか。 origin dev は ローカルの dev ブランチが追跡している「リモート」のブランチ。
origin/dev はそれの「ローカル」コピー。コピーは最新ではない可能性がある。
という言い方をすると良いのかな。 正確に言うと違うのでややこしいな。順番が逆というか。必ずしも origin じゃなくても良いとうか。 リモートリポジトリは、origin以外を使ってみたり、ファイルシステム経由でベアリポジトリを使ってみたりすると理解が深まるね。
インターネット接続不可能な環境だと結構使う。 >>375
別物っちゃ別物だけど。
gitのヘルプを読んだほうがいいよ。
端的に言えば、origin/devは通常、リモート追跡ブランチと言っていいもので、origin devはコマンドに付けた2つの引数。
mergeはローカルレポジトリにあるrefとマージするもの。
fetchやpull(pullはfetch+mergeだから、以下fetchのみ説明する)は、リモートレポジトリにあるrefを、ローカルレポジトリにコピー/ダウンロードしてくるもの。
refは"コミットを指す参照"のこと。
つまり、refはローカルブランチ、リモートブランチ、タグなどのこと。
よく言われるように、ブランチやタグは、コミットへのポインタであるから、refはコミットを指す参照と言った。
refは、各々のレポジトリにルートにある.git/refs/**が実体。(以下.git/を省略)
refはすべてレポジトリごとに保存されている。
git branchコマンドなどでローカルブランチを作ったり、fetchやpushでリモートブランチを作ることができる。 >>380
リモートブランチという名前だけど、特定のレポジトリ(例えばorigin)のrefを、ローカルレポジトリにコピーしたもの。
リモートレポジトリoriginからfetchをすると、originにあるrefs/**をダウンロードしてきて、ローカルファイルシステムに、refs/origin/**として保存する。
fetchをしなければ、最後にダウンロードしたときのままで、リモートレポジトリが他人によって更新されてても、refs/origin/**は自動には更新されない。
いつもrefs/を付けるのは面倒だから、これは省略できる。
ローカルブランチの実体.git/refs/heads/branchAは、branchAのみで通常呼ばれる。
リモートブランチの実体.git/refs/remotes/origin/branchBは、origin/branchBのみで通常呼ばれる。 >>381
merge branchAは、merge refs/heads/branchAの省略形で、後者で書いてもマージできる。
refsであればマージできる。
上に書いたように、refsはリモートレポジトリからコピーしてきたもの(origin/...)と、自分で作ったref(ローカルブランチなど)のことだから、
merge branchAでも、merge origin/branchBでも正しい表現。
そのときそれらが指しているコミットとマージする。 >>382
fetch origin devは、fetch origin refs/heads/dev:refs/remotes/origin/devの省略形で、後者で書いてもfetchできる。
これは、originにある.git/refs/heads/devを、ローカルレポジトリの.git/refs/remotes/origin/devにコピーするということ。
だから、fetch origin develop:devと書けば、originのdevelopを、ローカルにdevという名前で保存することも可能。
ただしトラッキングブランチの設定がある場合は、もう少し前処理が入る。(説明が冗長になるので省略。ただし、ほとんどの場合はリモートトラッキングの設定しているはず。)
ここで、fetch origin/devと書くことが何をしているかは分かりますか？
何を省略しているかを考えれば想像できると思います。
答えは書きませんので、自分で実験するなり考えてみてください。
(普通このコマンドは失敗します。そのようなrefを普通は作らないからです。)
ちゃんと知りたければ、自分でヘルプ読んだほうがいいよ。
push, fetch, pull, refspecなどを読んでみて。 >>383
誤記あったので訂正。
> fetch origin/devと書くことが
→ fetch origin origin/devと書くことが
以上。
ちなみにfetch origin/devは必ず失敗すると思います。
その位置にはrefではなくてリモートレポジトリ名を書くわけだが、origin/devってい名前は作らないと(多分作れない)思うので。試したことないけど。 refspec使った例で、自分がたまにやるやつを紹介して補足すると、
pushの例になるけど、
git push origin @~2:developとかは使うかな。
update update ...っていくつかコミットしたあとに、2つ前までのやつならちゃんと作れてるから、それをpushしておこうなんてときに。
fetch方向だとそういう工夫は必要ないと思うから、追跡してるとおりに取ってきちゃうけど。 あと、上にorigin以外を...って話があるから、自分のユースケース紹介しておくと、
自分だけが使うようなコンフィグファイルの設定とかを、backupっていうリモートレポジトリの名前で、別のフォルダに向けておいて、
git push backup myconfig1とかやることあるかな。
この場合は、リモートブランチとしてbackup/myconfig1っていうのが作られるよ。
リモートレポジトリはoriginだけじゃなくてもよくて、
ローカルレポジトリに、backup/myconfig1はorigin/developと共存してる状態だよ。
ごめんね、自分語りが長くて。 gitクライアントからボタン一つクリックするだけで完了するような操作を、いちいちターミナル立ち上げてタイプしてる人は何？
しかもタイピングが遅いからまどろっこしくて仕方ないw >>387
コマンドでgitを使う=タイピングが遅い
決め付けの激しい人だな そもそも普段からキーボード打つ方が、何十倍も早いだろ。煽るにしてもレベル低すぎ。
それともマウスでプログラム組んでるとか主張するんだろうか？ >>377
origin/devはgit logで表示されるorigin/devと同一という理解であっていますか？
であれば、git logをした際にdevブランチの方がorigin/devよりも上（新しい）に表示されることがあるので
必ずしもorigin devのローカルコピー版であるorigin/devは最新ではない という説明には納得がいきます。
>>381
冒頭に書いてあることは、リモートブランチもリモート追跡ブランチと同様に、ローカルリポジトリ上に存在する という理解でよいですか？ >>388
そうとは言ってないだろ
文書が読めるようになってからレスしろよ 「タイピングが遅い」っていうのは自分のことを指していってるんじゃないかなぁ
たぶんある種の自虐かと いやよく読もう
> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw
タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件 特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ 開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い
そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね >>390
はい。わたしは>>381には、リモートブランチとリモート追跡ブランチが同じ意味で書いてます。
前半は自分にはわからなかったです。
どのorigin/devが、logのorigin/devと同じと言っているんだろう。
origin/devは普通.git/refs/remotes/origin/devの省略形として使われるのであって、
git logの引数の説明に、refspecとかrevisionとか書いてあったらそうだろうと思います。
自分はそういうつもりで使ってますが、ちゃんと知りたいなら調べてみたらどうでしょう？
文脈によっては.git/refs/heads/origin/devかもしれないですね。これは難癖ですが。（つまりorigin/devっていう名前のローカルブランチ。でもコマンドミスで、たまに作ってしまう…） >>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。 >>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。
原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。 >>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索すればリモート追跡ブランチの説明があります。
あと、git help gitで、使えるコマンドの大枠が見れます。
本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。
オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。
ただしこれはツールとしての使い方が主です。 >>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。
origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。
あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。 commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ commitコマンド実行したときにエディタ立ち上がるようにしてないの？ 環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?
ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません 呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。
（注:あくまでデフォルトなので変えることはできる…） ターミナルにコマンド入力してのがかっこいいと思ってる人いる？ >>407==>>387
どんだけコマンド敵視してんだよ 煽り耐性なさすぎだろ…
ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが >>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。 我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う 未だにSVNなんか使ってgit使ってないのはやばいなんて言う方がやばいなんて話題になってたんだけどgitに慣れた身からすると
ローカルでコミットできない、ブランチを気軽に切れない、もうそれだけであまりに不便だと思うんだけど、SVNユーザーはこれをデメリットと感じないのだろうか？ gitのことを知らないんだからsvnのデメリットにも気付かないよ ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末 >>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利 CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね >>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。 あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。 >>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん
それで回るのなら、cvsやめてzip管理でええやん 例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいいだろ、勉強する時間が無駄みたいな >>425
すまん俺が svn 糞 とかでググってるせいだわ >>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない >>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ >>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ
やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ >>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。
あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
https://richlab.org/coterie/tok.html >>440
gitを使ったシステムなんだから別物ではない repoってgithubとかgitlabみたいなもん？ >>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
複数のリポジトリを一括で操作できるのが特徴とか
ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも
個人的にはいらんなぁ 自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし
Android SDKのソース落としてくる時に使ったぐらい 個人レベルでgitを使う必要ある？
そもそも自分ひとりで書いてるなら大抵は覚えてるだろｗ 個人レベルだからこそ簡単に導入出来るgitを使う
別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし
便利だと思うのだけどね
ただバイナリ（excelのファイル)みたいなのには使わないが 新機能を実装する時は、変更前のソースを参照できるようにしておかないと面倒。
バグが発生したときは差分をすぐに参照できるようにしたいしな。 >>448
ローカルリポジトリだけでも完結できるのにgitをわざわざ忌避する理由がない >>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ >>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。
リモートリポジトリ無しってgit登場時点で普通の話だったっけ？ リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿 https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
＞ しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞ レポジトリのローカルコピーがあることと、分散マージはでかかった。 >>448
gitに限らんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ 初歩的な質問になるけれど…
異なるローカルブランチ「debug」と「genbug」が存在する。
両方のブランチに全く等しい「iam.txt」と「whoyou.txt」いうテキストファイルがあって、
どちらのテキストファイルも両ブランチの最新コミット内に存在するものとする。
「Iam.txt]の中身は"I am a dog."
「debug」ブランチで【rm whoyou.txt】と打って「whoyou.txt」を削除し、「Iam.txt」の中身を"I am a cat."に変更してステージングをしないまま、
【git checkout genbug】 と打って「genbug」ブランチに切り替え、ワークツリーを確認してみると、「Iam.txt」の中身は"I am a cat."に変更されているのに、
「whoyou.txt」は削除されていない（というより復活している）。
これはなぜなのだろうか？（whoyou.txtをgitリポジトリから消したいならrmコマンドではなくgit rm --cachedを使うべきなのはわかる）
いまいち、git checkoutをしたときのワークツリーの挙動が掴めない 「git checkout ブランチ」するとき、
checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる
つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う
ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する $ git status -sb
## debug
$ ls
iam.txt whoyou.txt
$ cat iam.txt
I am a dog.
$ echo "I am a cat." > iam.txt
$ rm whoyou.txt
$ git status -sb
## debug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.
$ git checkout genbug
M iam.txt
D whoyou.txt
Switched to branch 'genbug'
$ git status -sb
## genbug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat. >>466-467
whoyou.txtが復活するのは勘違いしていたみたい すまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。
ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな >>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる
git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示 git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る たかだかpushするだけなのに、ターミナルからやった方がエモいですか？ 興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？ ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ >>478
最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw タイムスタンプω
パソコン初心者かよωωω=2πf gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった あと、扱うファイル形式的にも難しそう
>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？ タイムスタンプみたいな信用できないものに依存するなよ https://github.com/zhlynn/zsign
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？ git clone github.com:witwall/mman-win32 >>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → https://github.com/
に読み替えてhttpsでやればいい 情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども 日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども おとなしくGUI使えよ
タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ >>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるのも過去に完全論破されたのがよっぽど悔しかったんだろうな ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？ 別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？ >>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた 気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる 気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する >>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok .gitattributesで.rcファイルをUTF-16LE-BOMに指定してから、git cloneした時にエラーが発生するようになりました
書き方が間違ってるのでしょうか？
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
.editorconfig
------------------
root = true
[*]
end_of_line = crlf
charset = utf-8
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = false
[*.rc]
charset = utf-16
------------------
.gitattributes
------------------
*.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF >error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？
そもそも、UTF-16LE-BOM を使う事ってある？
普通は、BOM 無しUTF-8 を使う >>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります >>505
使う理由があって使ってんのに難癖はやめとけ >>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？ 素直に文字コード変換ソフト使ってからpushしたほうがイイんじゃね？
文字コードの問題は結構根深いとこあるし 情報学部卒IT企業勤務1年目だけどGit難しいよ
よくみんな使いこなせるな
ブランチ切り替えとか発生した瞬間に混乱するわ とあるブランチで開発を進めていて、pushまで完了していつでもブランチ切り替えできる状態ではあるけど
新しくブランチ切ったからそこで作業してと言われた瞬間パニックになる ブランチ切り替えすると作業フォルダの中身変わるの緊張するわ 慣れないうちはコミットログやブランチ同士の関係をグラフ表示できるGitクライアントに頼ったほうがいいよ
ミスっても所詮は手元だけだから、適宜リモートにプッシュしてさえいれば操作は大胆にやればいい
ただしプッシュ前のチェックだけは入念に >>508
リモートの.editorconfigと.gitattributesでUTF-16LE-BOMを指定してるので
.rcファイルもUTF-16LE-BOMで上がっているんじゃないのかな
cloneした.rcファイルはUTF-16LE-BOMになってます
>>510
よくわからないエラーで悩むよ >>514
ありがとうなんだか設定ミスのようだ
× charset = utf-16
〇 charset = utf-16le
× *.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF
〇 *.rc text working-tree-encoding=UTF-16-LE-BOM eol=CRLF >>510
頭が良い悪いは関係なくて、単に慣れの問題だと思うよ
心配しなくても、そのうち慣れる ある程度の難しさがあるのは確かだと思うので地図を読むことの得手不得手みたいな適性は何かしらあるかもしれない けどブランチ切り替えくらいなら慣れだな
分散開発で計画やマージを任せられるとなると人によって難しい githubの質問ってここで良いのかな？
フォーク基のリポジトリをPublicからPrivateに変更したら、Publicの時にフォークしたユーザーのリポジトリに影響って出る？ c:\gittest\server\proj01
c:\gittest\client\proj01
というフォルダ作って上から下にcloneはできて下のフォルダで完結する操作はできたんだけど
下から上にpushしようとすると失敗する
To c:\gittest\server\proj01
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'c:\gittest\server\proj01'
こういう学習のためのテスト環境ってローカル同士じゃダメなんですか？ bare repositoryになってないとかmaster,developへの直接push不可になってるとか 【Git】bare リポジトリで無いならば、push を受け入れないことを知りました
https://oki2a24.com/2016/10/11/do-not-recive-push-unless-bare-repository/
学習のためだけならreceive.denyCurrentBranchを設定してもいいかもね 不可解な挙動で学習時間や意欲をロスしないためにも普通の構成にしたほうがいいと思う
俺ならserver(bare)とclient1とclient2を作る そもそもどこからcloneしてきたのか不明だし、こういう質問する奴って情報が不足し過ぎてるような
githubとかにあるようなのをcloneしてpushして失敗しましたとかなら草だがｗ 別にどこからcloneしてきたとか関係ないよ
デフォルト設定だとbareでないレポジトリへpushできないことがあるのは仕様
bareにするとかdenyCurrentBranchは危ないよとかググれば日本語の情報もいっぱいある server側をベアで作り直したらうまくいきました
ありがとうございます
なぜ入門書はここら辺を説明してくれずに
まずGitHubのアカウントを作ります。とか言い出してしまうのか 選び方が悪いね
そういう方向性の入門書ならプロジェクトリーダー濱野氏の入門Gitだ
5章「2か所で使う」でバックアップリポジトリをbareで作って云々を解説してる
githubには一切触れていない(と思う)
git clone /pub/repositories/～ みたいなローカルマシン内でのcloneを解説してる本は他にあるのかな Gitをインストールした記憶がないのに、なぜかインストール済みでした。
Git Bashを起動すると、プロンプトが変だし、フォントが小さいし、色付けもされません。
プロンプトは「~>」です。
これはどういうことでしょうか？ コミットメッセージについてです
テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が
あるみたいですが、基本的にはどっちを使うべきなんでしょうか？ 仕事や既存OSSならチームのルールがあるだろうから先輩に聞け
個人ならどっちでも自分が楽な方でいい
ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、
そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない >>535
分かりました ありがとうございます
取り敢えずVSCodeを使っておこうと思います >>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。
自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。
コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。 長文したためなくてもバグトラッカーのID書いてあればいいよ
繰り返しになるけどプロジェクト次第 >>539
まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄
コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ https://git-scm.com/docs/SubmittingPatches#describe-changes
> The log message that explains your changes is just as important as the changes themselves. Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons:
... >>539
コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが >>541
ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね >>543
vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。 コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね
ログもGUIの方が見やすいし、diffもそうだしね 今時Tortoiseはないでしょ
GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、
SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい
普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの 以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？ gitに関係ないのでこっちで質問してください
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/ >>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ >>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。 あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。 TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット TortoiseGitはシェルエクステンションの時点でインスコする気失せる git使うなら開発者が愛用してるEmacsのmagitを使おうぜ そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。 fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。 女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。 使い方が分からないという話？
それともソース管理がイマイチ分からない話？ なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。 >>565
知らんがな。
Git採用を決定したヤツに言えよ。 決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません >>565
お前はいつ、誰が、何のために変更したか全部覚えておけるの？
どの変更とどの変更が一緒の組でどれが独立した修正か、差分見ただけですぐに区別できる？
多数の変更案の中から必要なものだけをすぐに組み合わせられる？
開発人数が多くなっても同じことができる？
1万回修正したとして、その差分を全部コピーで持っておくの？
その無数のコピーの中から必要なコピーを見つけるのはどうやってやるの？ >>567
この「うちの学生」とは、あなたの想像上の存在に過ぎないのではないでしょうか。 >>569
実際に教えていますが何か？
https://richlab.org/coterie/lpf.html
そんな中，まさにその疑問や悩みに応えるような内容の講義
「シェルスクリプト言語論」を金沢地区の大学向けに、2016年から
開講してきました．ここまで4回（4年）開講し，内容が洗練されてきたところでついに書籍化しました． バイナリでも別に過去の履歴は取って来れるような
ただリポジトリは肥大化するしバイナリの管理の為に作られたものでは無いから
相性が良い訳では無いのは分かるのだが
プログラム開発の世界でバイナリと言えば大抵はエクセルなどのオフィス系のファイルだが
正直これらをgitでバージョン管理する必要は無い気はしなくもないｗ
（でも大抵の会社はバイナリだろうがgitで管理しているが） >>571
なにか勘違いしているようだな
gitはテキストデータでも保存するときに
バイナリ形式を使っているから将来データが取り出せなくなると言っておるのだ
そのようなものは使わん ん？将来？別に好きな履歴を取り出せるが？
何の話だ？ いつもの粘着荒しじゃないの
途中で句読点のスタイルが変わってるし半分コピペの創作だろ
あの手この手で相手してほしいんじゃね バイナリ形式だから将来取り出せないって、何を心配してるんだろう？ 文明崩壊後でコンピューターが使えなくなった時？ 岩に刻んでおく？ 間抜けなPOSIX原理主義者がまた論破されて敗走したのか >>563
俺もその本読んだけど、何となくGitの存在意義分かったよ
例えば会議の備忘録がこんな感じで複数あるとしたら？
・備忘録_1.txt
・備忘録_2.txt
・備忘録_1改.txt
・備忘録_最新.txt
・備忘録_3.txt
どれが最も新しいかピンとこない、どの順に更新されたのかピンとこない、
誰がどのファイルにどんな更新を加えたの分からない
そんな問題を解決してくれるのがGitのようなバージョン管理ツール(って書いてある) >>563
YouTube で「git 使い方」「git 入門 」などで検索！
山浦清透・せお丸・くろかわこうへい・しまぶーなど、色々ある >>577
UNIX哲学ではバイナリ形式は禁止されている
愚か者め >>583
話のわからんやつだな。この本を買え。全部書いとるわ。
https://techbookfest.org/product/5743917710442496
我らが一番問題だと思っているのは、リポジトリーの中身の多くが訳のわからぬバイナリーデータになって
いることだ。そのバージョン管理ソフトウェアが滅んだら復元は絶望的だ。テキストデータ形式ならば眺めれ
ば方策も見えてくるのでまだ何とかなりそうな気がするというのに。「データはテキスト形式で保存せよ」とは
UNIX 哲学でも言われてきたことだ。一体何を考えているのか。 移り行くトレンド
古参のプログラマーなら、これまでどんなバージョン管理ソフトウェアが台頭してきたか振り返ってみよ。す
ぐ思いつくものだけでも、RCS、CVS、SVN、そしてGit。これらは同時期に存在して覇権を争っていたのでは
ない。それぞれが時代を担ってきたといっても過言ではない。時代によって使うものが替わり、新しいバージョ
ン管理ソフトウェアが流行り出せば、その使い方を覚え直し、時にはリポジトリーの移行を強いられてきたこと
だろう。よくまぁ、懲りもせずにといったところだが、我らはもうたくさんだ。もしかすると、諸君は「Git を
覚えれば安泰だ」などと思っているかも知れんが、あと数年、遅くとも5 年も経てばきっと次のバージョン管理
ソフトウェアが登場し、覚え直しとリポジトリーの移行を余儀なくされることだろう。 目的を見失っったバージョン管理ソフト
バージョン管理ソフトウェアのそもそもの目的は何だったのか。開発を続け、バージョンアップしていくソフ
トウェアの維持管理に要するコストの抑制であったはずだ。これは、POSIX 原理主義を崇拝する我らがソフト
ウェアを5 年、10 年と生き長らえさせようとする、その根底に流れる目的そのものである。
ソフトウェアはバージョンアップする。新しいコードを加え、古いコードは切り捨て、時には依存するライブ
ラリーを付け替えもする。その変わる様をすべて見届けることがバージョン管理ソフトウェアの役割であり、そ
れができて初めてまともに維持管理コストの抑制が実現する。ゆえに、
バージョン管理ソフトウェアは、ライブラリーの類よりも遥かに長く生き長らえなければ意味がない。
ところが実際はそうなっていない。「バージョン管理ソフトウェアの維持管理」を強いられる。本末転倒もい
いところ。お前は何を言っているんだ。 覚え直しと移行すりゃいいじゃん
その時期がくれば便利な移行ツール（git svnコマンドのような）が出回るし、簡単なことだよ
そんなちっぽけなことを恐れて、完全無欠の理想通りじゃないからと今のベターな現実解を忌避するのはあれだ
こだわりが強すぎて社会生活に支障が出るタイプの典型的症例 >>587
何度も何度も覚え直しでお前は成長してると言えるのか
シェルスクリプトだけでなんでもできる >>587
中身がわけのわからんバイナリデータなのだから壊滅的だ
データは取り出せなくなり移行なんかできん
バージョン管理ソフトウェアが滅んだら復元は絶望的だ 中身がわからんのはお前が無能だからだろ。ソースも公開されてるし、中身の形式も公開されてるので読んどけ。プロプラな機密ソフトの基準で語ってんじゃねーよ。
中身が完全にわかっているという意味ではテキストと同等かフォーマットが決まってる分それ以上に効率が良い。 >>582
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている テキストで保存した結果
e38397 e383ad e382b0 e383a9 e3839f e383b3 e382b0 e381a3 e381a6 e4bd95 efbc9f
↓
e383 97e3 83ad e382 b0 e383 a9 e383 9fe3 83b3 e382 b0 e381 a3 e381 a6 e4bd 95ef bc
↓
繝励Ο繧ｰ繝ｳ繝溘Φ繧ｰ縺｣縺ｦ菴包ｼ >>588
成長？
最適なツールを選ぶときに成長とか関係ある？
淡々と使うだけだろ
何度も何度もっていったい何百年生きるつもりなんだ USP研究所のシェルスクリプトマガジンを購読しているけど、
こんな人がライターなのか？
いささかガッカリした。 バイナリに見えるのはgzip圧縮されてるだけでgitconfigに
compression=0
loosecompression=0
を書いておくと無圧縮のテキストになったような >>593
せっかく覚えたのにバージョン管理ツールが変わって知識が役に立たなくなると言っておるのだ
シェルスクリプトなら20年後も今の知識が通用する
https://www.slideshare.net/ShellShoccarJpn/posix-59780910 ちなみにgitのリポジトリは、ブランチ、コミット履歴、データ(ファイル)の3種類を
それぞれsha1ハッシュで繋いでいるだけのシンプルな構造
リポジトリをバラしてファイルを取り出すだけのプログラムなら大体の人は1日もあれば作れるよ >>598
さすがに1日もかからんやろ。スクリプト言語使って15分とかそんな感じでは。 >>598
ならばそのsha1ハッシュをPOSIXの範囲で作ってみよ
POSIX準拠で仕様が許されてるハッシュ化コマンドはcksumのみだ
我らはbase64コマンドをawkで作ってみせた >>602
アホはスクリプト言語で書いた。
普通の人は速度出したいのでそういう用途にはCコンパイラ使う。POSIXにC言語の規定がないとでも思ってるんだろうな。 >>604
アホはお前だ。POSIXにC言語の規定があることぐらい知っておるわ。
C言語はハードウェア依存する。そのような効率よりも移植性のほうが重要だ。
https://www.ipsj.or.jp/dp/contents/publication/32/S0804-R1601.html
POSIXに準拠したプログラムを作成することにすると，開発言語はシェルスクリプト
またはC言語（C99）に限定される．その理由は，POSIXで用意されている
プログラミング言語としてのコマンド（以下，POSIXコマンドと記す）に
PerlやRuby，Javaといった現在よく利用される高級言語は存在せず，
存在するものはBourneシェル（sh コマンド）とCコンパイラ（c99コマンド）だけだからである．
どちらを選択してもPOSIXに準拠したプログラミングができることにはなるが，
基本的にはシェルスクリプトを利用する．C言語はバイトオーダ等のハードウェア構造を
意識しなければならない．一方，シェルスクリプトであれば，そのようなハードウェア依存は
POSIXコマンドが吸収しているため，意識せずにプログラミングできることが理由である．
したがって，POSIX中心主義では，POSIXの仕様に準拠したシェルスクリプトを
中心としたプログラミングをする．シェルスクリプトを選択することには，以下に述べる3つの利点がある． >>604
シェルスクリプトが遅いなどというのも間違いだ。
それはストリーミング型の書き方を知らない愚か者の戯言だ
3.1.1 開発効率と処理効率の両立
シェルスクリプトはC言語と比べて処理の遅さを指摘されるが，それは必ずしも正しい認識ではない．
シェルスクリプトはインタプリタ型言語であるため，ステップ数が多いほど処理効率は悪化する．
また各ステップに外部コマンドを起動する記述があればそれも大きな処理効率悪化につながる．
しかし，手続き型の書き方からストリーミング型の書き方に改めるように工夫すれば，
ステップ数の増加を抑えられ，処理効率は大きく改善する． >>606
じゃあ、お前がシェルスクリプトで git 書けばいいんじゃね？
俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。 >>607
我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる
gitを書く必要などない
知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め
https://richlab.org/coterie/lpf.html >>608
ゴミを勧めんな。オライリーに訴えられてろ。 >>609
ゴミならば大学の教科書になっておらぬわ forkで2つのコミットの差分どうやって見るの？
履歴から2つ選択しても出ない。コンテキストメニューも。未実装？ 以前作ったリポジトリのmasterブランチの名前をmainに変えようとしてます 以下の手順であってますか?
リモートリポジトリは自分がSSHでログイン出来るノードにあってベアリポジトリにも入れる状態です
1. (ローカルで) git clone <リモートリポジトリ> <ローカルリポジトリ> # リポジトリを取得
2. (ローカルリポジトリで) git branch --move master main && git push origin main # ローカルでmasterをmainにリネームしてプッシュ
3. (リモートのベアリポジトリで) git symbolic-ref HEAD refs/heads/main # HEADをmainに設定
4. (ローカルリポジトリで) git push origin :master # リモートリポジトリのmasterを削除
おかしいようであれば、新しいリポジトリを作って2.でそっちにpushして古いリポジトリは退避、以後は新しいのを使うことも考えてますがどうでしょうか >>610
大学には頭おかしいのがおらんとでも？
大学全体の何割が使ってるか言ってみ。 どうせ安全じゃないだろw
>fatal: detected dubious ownership in repository at
こんなものつけるなよカス >>613
大学だけじゃないぞ
プログラマならシェルスクリプトマガジンぐらい知っておろう
そこに長期連載されているほど、普及しておる
頭がおかしいなら、こんなに長く連載されるはずがないな >>615
シェルスクリプトなぁ……簡単な作業の自動化用途だな。
なんでgitスレでこんな話題が？
NG指定したほうがいい？ >>612set-headサブコマンドが使えるみたい >>616
愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。
この間はUNIX哲学に基づいてリアルタイムカーネルなしに
シェルスクリプトだけでリアルタイム処理を実現してみせたわ
https://www.sea.jp/ss2021/download/11-SS2021.pdf >>616
gitのような目的を見失ったバージョン管理ソフトを使っているからだ
バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが
リポジトリでわけのわからんバイナリ形式を使っておるから
バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。
「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。 容れ物が古くなったら新しい容れ物に中身を移すだけ。 >>620
よくもまあ懲りもせずにといったところだな
そうやって古くなったソフトを捨て新しいものに入れ替え
せっかく覚えた知識は無駄になり移行作業で苦しむ
POSIX原理主義なら一度覚えた知識は一生使うことが出来る
新しいことを覚える必要はない 啓蒙したいんだろうけど
>新しいことを覚える必要はない
これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。 >>617
git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、
HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか >>621
いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。 啓蒙したいんじゃなくて単に荒らしたいだけだから
だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん シェルスクリプトのヤツは釣りだろ？
マジでいってんだったら頭おかしいだろw
(基地外を釣るエサ投下) >>627
いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。 >>628
勘違いしてるぞ。俺は人格者（笑）って書き込んだだけだぞ Shelling at Russian power plant leaves Belgorod without electricity
https://www.youtube.com/watch?v=n32nblVVz1g Git初心者でGit練習中の者だが、質問いい？
関数の履歴を見るコマンド
Git log -L '/function myfunction/',/},/:myFile
があり得ないほどメモリを食うのだが、これって今のところ仕様？
それとも俺の使い方がまずい？
2MB程度のファイルを2800回程度コミットしたリポジトリがあって、git gc して12MBになってる。
これに対して上記コマンドが9.4GBメモリを食う。
おかげでMINGW32bit環境では全然駄目で、MINGW64bit環境だと上記の通り。
Linux64bit環境でもスワップを増やさないとコケたので4GB以上は食ってるはず。
(windowsでの結果をふまえ、スワップを9GBに増やした環境では動作した)
Gitのバージョンは、Windowsは最新(2.38.1)で、Unixは2.20.1。
なお出力された内容には不満はない。
ただ、10-20行程度の関数が15個履歴として表示されるだけで、このメモリはあり得ない。
シェルスクリプトでも同じ物は得られるが、1GBすら行かないはず。
最初から最後までfreeしないでやってるとしか思えないが、何かそうなる理由ある？
あと、オプション等で回避する方法があれば教えて。 LooseCompressionの全展開用の領域 2MB*2800=5.6GB
git logは内部でlessにパイプでデータを渡してるから
パイプバッファも含めて約2倍だろうか
Packしなけりゃ少しはマシかもしれない(未確認) >Pack
git gcのことか？
なら実は当初はしてなくて1.2GBあったが、その時からコケてた。少なくとも2GBは食ってる。
その後gc出来ると知り、やってみたが、実際は自動で何回かやってるようだし、多分大勢は変わりない。
(実は全部新たにコミットし直すのも試してる)
なお愚直にgit show -> 切り出し -> diff を繰り返すだけのスクリプトを作って試してみた。
メモリは普段の使用と変わりなかった。
ただ問題は時間で、12分程度かかる。これでは気軽には使えない。
MINGW64だと2分程度で済む。
時間がかかるのは一々ファイルにしてるから？だから、
/dev/fd/3等で全部でパイプに出来れば短縮出来るかも？、というところ。
(システムキャッシュに完全に載るサイズだから関係ないかも？だし、
そもそも2回ずつ使うのでパイプにフィットしないが)
ただ現在でも初期画面は数分で出るし、出なければ大昔のコミットなのでどうせ問題なく、
実際の運用としては及第点ではある。でも速ければ速いに越した事はない。
Gitはおそらく速度重視なのだろう。
自動増加スワップのMINGW64環境なら現実的には大した問題にはならない。
ただ、全部メモリ上に展開する意味もメリットもないはずなので、
途中で一回もfreeしてないであろうこのコードは、コードとしては大問題だとは思うよ。
(ジョークで言われてる、Javaしか知らない奴が書いた、freeが一つもないコード、になってる) パイプへの変更は厳しいので、一時ファイルをRAMDISK上に配置してみたが所要時間は変化無し。
よってシステムキャッシュは効いてて、パイプにしても高速化予算はほぼ無いと分かった。
diffを切ったら8分、さらに切り出しを切っても8分(変化無し)、git showをgit --version に変更したら2分で終了した。
よって時間予算は gitプロセス起動が1/6(2分)、git show が1/2(6分)、切り出しはほぼ0、diffが1/3(4分)と判明。
git showを高速化する為には出来るだけ纏めて取り出すのがよく、
メモリ無限大なら全展開が一番速いのも事実だが、せめてコア数程度にして欲しい。
見てる限り特に先頭も末尾も異常に速くはならない為、
動画と同様に途中にスナップショットを適度に挟んでいるように見え、なら、全展開する必然性/妥当性はない。
(やってもそんなに速くはならないのにメモリを異常に消費する＝スワップする分余計に遅くなる)
>>636
これは開発者マシンなら最低でもRAM16GBでSSDだよね！というノリなら方針は間違ってない。
ただ、-n 100 とかで直近100コミットに絞れればいいだけなのだが、これが出来ないのが問題。
どうやってもいきなり9GB超掴みに行くのは使用勝手が悪い。そもそも最初の方の履歴なんてほぼ要らんし。 >>638
実はそこは初心者過ぎてよく知らないんだわ。
git log HEAD~100
では制限出来なかったけど、どう書くべきなの？
とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。
これが効かないのは、多分実装忘れじゃないかと。
> https://www.git-scm.com/docs/git-log
>>639
多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。 合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい
そういうもん
レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる
仕様なのでは！？と空気読んで黙ってるのは奥ゆかしいニンジャ精神 >>641
なるほどその通りだ。
ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。
> https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> https://www.git-scm.com/community 内の this guide が上記 >>640
手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので？ >>640
HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない？ >>645
-100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する
A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる） >>644
効いた！ありがとう。
何ぞそれ？と思いきや git log のdocumentの頭に書いてあるのな。
> https://www.git-scm.com/docs/git-log
gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。
やはり最初は一通り読まないと駄目だな。
これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。
これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。
再現用のスクリプトも同梱してるから気になる人はどうぞ。
https://lore.kernel.org/git/CAFOPqVXz2XwzX8vGU7wLuqb2ZuwTuOFAzBLRM_QPk+NJa=eC-g@mail.gmail.com/T/#u >>647
おつかれ。
慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。 >>648
初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。
なるほどタグを付けてgit logでは範囲指定がデフォか…
ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz
> https://www.git-scm.com/docs/gittutorial
つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。 git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ？
> https://www.git-scm.com/docs/git-diff#Documentation/git-diff.txt--p
既にフォーマッタを持っているので、
unixコマンドのdiffのデフォルト出力と同じ物が欲しい。
切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。
diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様？
-s や --no-patchでは出力そのものが出なくなる。ただし
> or to cancel the effect of --patch.
と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。 >>650
git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。 >>651
マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。
スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、
これでいいと思った奴は死ねだな。 >>652
git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。 >>653
いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。
diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。
GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。
だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。
diffを内包する事に、何のメリットもない。
この名残がexternal driverで、それが使えればいいという事なのだろうけど、
ご丁寧にこれを禁止するオプションまである。(-no-ext-diff)
多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、
禁止するのは違う。どこかでおかしな思想が混入しているよ。
そもそも、それ以外を考慮しない＝外部コマンドで十分出来る事はdllを呼ぶ、であって、
この構成だとGitがdiffも構成してるから、君は認識を間違ってる。
Gitは明らかにおかしい方向で無駄な事をやってしまっている。
そしてそれは君の価値観的にもNGなはずだよ。 >>654
Linus のこと知ってるのなら長文書く前に調べろ。
git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。
で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。 Linusも言ってたような気がするけど、気に食わなければ自分で作れ
以上 >>655
Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。
これは間違ってない。
問題は、元のdiffの形式の出力が出来なくなってる事だよ。
オプションで出来るよ、でよかっただけ。
オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。
何故君がそんな意味不明なポジショントークをするのか分からないが、
Gitが方針を間違ってるのは事実だよ。
オプション禁止なら、git diff にオプションを何一つ付けてはいけない。
(仮にこれであれば、賛同はしないが理解はする）
ただまあ、ドキュメントの雰囲気だと、
おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。
君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。 >>657
お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。
オープンソースなんだからオプション必要ならお前が自分でつくればいい。 あと −−no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。
それこそ git で調べればすぐだぞ >>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。
というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。 >>660
不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。 色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> https://qastack.jp/programming/255202/how-do-i-view-git-diff-output-with-my-preferred-diff-tool-viewer
ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。
俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！
とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。 てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。
つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。 自分でやってみればいいよ。
自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。
仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。 >>665
それが従来形式のdiffの出力をさせない理由なら、
現在のGitプロジェクトの思想は俺とまるで合わない。
今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。
multicsの再来だね。(俺は使ったこと無いけど)
自覚症状もあるみたいだし。
> Git is a fast, scalable, distributed revision control system with an unusually rich command set
> unusually
> https://www.git-scm.com/docs/git
ただまあ本当にdiffも内製しているようで、ちょっと驚きだよ。
ただwikiによると当初はローレベルエンジン＋シェルスクリプトで、これは俺の思想と合致してる。
windowsに移植する際にシェルスクリプトをCに書き換え、そこでモノリシック化したようだ。
それで環境変数を見るとか、完全に開発の方向性を間違ってる。
当初のシェルスクリプト方式ならdiffを呼ぶだけだから、シンボリックリンクで好きなのと簡単に交換出来た。
この場合、Git側にコードは全く必要ないし、ユーザー側に予備知識も必要ない。
それをモノリシックにしてしまったから、環境変数を読むコードを必要とし、
ユーザーはマニュアルを読むことを強制させられる。
お互いに完全に無駄だ。
このメンテナは、ソフトウェアアーキテクチャはどうあるべきか、全く理解出来てない。
今ですらGitは難しすぎると文句言われてるだろ。
コードを書く為にコード管理システムの勉強が必要とか、完全に本末転倒だし。
じきに巨大な躯体を支えきれなくなって、分割プロジェクトが発生すると思うぜ。
それが多分Next-gitになるのだろうよ。
つか、何でGitはモノリシックを選択してんの？全く意味ねえと思うぞマジで。
本当にdiffとかを絶対に交換させない為？ならマジで死ねでしかないね。 Simple is not easy
Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ (だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう) >>667
他よりましなだけだろ。
ただ俺が思うに、Gitはもっと簡単に出来て、
・勉強しないといけないGit(今)
・勉強しなくてもなんとなく使えちゃうGit(次世代)
に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。
実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、
(勿論見た目だけだがそれが重要)
俺はそれ作って使おうかとも思案中。
Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。
コマンド名変えるだけでも相当変わる。 >>668
それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。
今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。
3時間程度あれば、再現コード付きのバグ報告が出来てしまう。
それをマニュアルを読むのに費やしてるのだから、無駄でしょ。
世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。 それは世界中の人が俺に1円を恵んでくれたら
俺は大金持ちになっていたと言っているようなもんだな >>670
もっと良い物ができると主張するんなら作って広めてから出直してこい
もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ
linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ
そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる
お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」 gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ
なので専用のものを内製する意味はある >>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ 初歩的な質問ですが教えてください。
コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか？
具体的には、
gitでdevelopからブランチを切ったAで作業しました。
ブランチAのコミット履歴が汚くなったので
新たに作成するブランチBにブランチAで変更したファイルを
一回のコミットで整理したいです。
git cherry-pick -n fromID..toID
などで整理しているのでしょうか？ >>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、
> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。
ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。
まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。 しょう１「かけざんよりもたしざんのほうがかんたんだ！かんじよりもひらがなのほうがかんたんだ！」 >>678
> ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。 >>674
不可欠な機能ではあるが、核心的機能ではない。
事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。
Gitは方針を間違ってる。
もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、
アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。
Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。
別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。
勿論GNUdiffに入れるのがベストだが、この辺は断られてもおかしくないし。
ただこれも人間用であって、マージする為に必要な機能部分ではないから、
君らから見てもGitではなくdiffに入れておけ、となるはずだが。
まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、
我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。
Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。
MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。
ビューを分離しておくことはものすごく重要だから。 え？まさかgit diffを差分を見るだけのツールだと思ってるの？ GNU diffに依存したら、GNU diffが使われないところで
動かないってわからんかなぁ
diffは移植性低いんだよ？ ちなみに652で既に言ったが
> --output-indicator-new=<char>
> --output-indicator-old=<char>
> --output-indicator-context=<char>
> Specify the character used to indicate new, old or context lines in the generated patch. Normally they are +, - and ' ' respectively.
> https://www.git-scm.com/docs/git-diff
このオプションが相当にヤバい。
これはデフォで
diff | less
となってる部分を、
diff --output-indicator-new='>' | less
とすれば幸せになれますよ、ということだが、これは
diff | sed 's/^\+/>/' | less
とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
Cで実装すべき案件ではないから。
そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。
多分こいつらは本当にCしか書けない、Cしか知らない連中だ。
sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。
コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。
プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。
だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。 git diffはパッチファイルを作るために利用されるし、
diffは環境依存するコマンドなんだから、
そんなのに依存したら、gitの移植性が低くなる
別の環境で実行したら、diffコマンドの出力がおかしくて
正しくパッチ当てられませんとかなったら困るやろ
常識で考えろや >>685
> とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
あのさぁ、提案するのはGNUだけじゃだめだって理解してないの？ >>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。 >>682
diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ ん?
これはもしかして以前来てたPOSIX原理主義者氏か? >>688
全部同じ実装じゃねーよ
それぞれ全部細かい違いがある
すべてのプラットフォームのdiffにまで対応するなんて
大変な作業なんて誰もやろうとは思わん 例えば2004年版のdiffには-uがないからな
The Open Group Base Specifications Issue 6
https://pubs.opengroup.org/onlinepubs/009604499/utilities/diff.html >>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。
>>691
前後したが上記。
>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。 > まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？
依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ OSの標準コマンドに依存したら
移植性は低くなるんだよ
常識やろ >>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> https://ja.wikipedia.org/wiki/Diff
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。 >>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。
通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。 >>696
-u がないとハンクの精度が下がるだろ
ほんとしらんならだまっとけよ >>697
パッチファイルを受け取って
他の人がマージすることもあるだろ
ほーんと、しらんならだまっとけ >>696
他のOSで使えるとは限らんだろうが
GNUしか頭にないんか >>690
違うし、565からの議論は俺にとっては一部意味不明だが、正直相当不毛なのは分かる。
それはGitの構造が糞だからだ。
結局のところGitはファイルシステム上のblobツリーを管理するツールでしかない。
そしてblobが気に入らないのなら、テキストにしてしまえばいいだけで、それもまたGitでしかない。
これを理解出来ない馬鹿同士で議論してて空回りしてるだけのように見える。
具体的には、git cat-fileがblob読み出しで、対になる書き込みツールもあるはずだが知らないが、
それらを個別に交換出来れば何とでもなるだけ。PHPで一般的に使われてるPDO方式だが、
要は最終段のI/Oだけは各種取りそろえて、切り替えれば何でも出来る構造にする。つまり、
Git謹製の cat-file バイナリ：Git純正blob形式
オレオレバイナリかシェルスクリプト： Git謹製blobファイルの名前でディレクトリを作り、
その中に自分の好きな形式で突っ込んでおけばいいだけ。
XMLでもJSONでも、ただのテキストでもいい。
それらがssh用ならリモートリポジトリを読むし、DB用ならDBに格納されることになる。
最終段のI/Oを読み書きセットで交換してしまえば、その上のコードは全く同一でいけるんだよ。
繰り返すが、PHPやWebの連中は常識的にこれをやってる。(理由は複数のDBに対応する為)
それをsshは別に実装してるようだし、方針自体がかなり狂ってるよ。
LinusもDBに入れてるのを糞に言ってるが、保存先は本質ではないし、
適切なアーキテクチャであれば簡単に交換可能なものだ。
だから本来、こんな議論が発生する余地もないのだけど。 >>701
> それはGitの構造が糞だからだ。
結論ありきで理由を探すな
お前はクソな理由を一つも言っていない 以前来てたPOSIX原理主義者氏ではなく
また別のPOSIX原理主義者氏のようだなｗ 自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ
世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」 POSIX原理主義はWindowsでの開発がめんどくさくなるんで本当に嫌いだわ
あと今更awkやsedの読みづらい文法覚えるより他のスクリプト言語で書いた方が楽だし、POSIX原理主義はPOSIXに慣れている奴のポジショントークにすぎないと思うね >>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない >>705
POSIX原理主義者はPOSIXを理解してないよ。 >>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん >>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> https://ja.wikipedia.org/wiki/Diff
だからそれはGitのアイデアでも全然無く、Git以前からdiffとedを組み合わせれば誰でも出来る物だった。
勿論diffの出力がキモだから出来るだけ--minimumなのは目指すとしても、
それはdiffを改善すべき話で、Git本体が対応する話ではない。
てかこの辺のソフトウェア階層の話が通じないところを見ると、割と階層無しの文化＝本当にCしか知らない感じだな。
例えばJSとかでは、扱うデータの先がDBなのか、ローカルファイルなのか、メモリ上のStringなのかを
上位のコードは区別しないで済むようにコーディングすることが普通で、
と言うか実際はそうしか出来なくて、強制的にそうさせられるわけだが、
形式的には、ネットワークでもローカルファイルでもメモリ上のStringでも、
プログラミングモデル側からは全部読み書き出来る状態になってから制御が渡される。
(メモリ上に展開し終えてから渡されるイメージ、なおこれをRubyでは上手いこと遅延読み出しにしてたりするが)
CでI/Oを分離するにしても普通はそうするし、実際、Gitでもそうなってる。
でないと git log -L で全展開の倍ほどメモリ食うとかあり得ないし。
最終段のI/Oは普通はそうやって上位のコードと分離するもので、Gitもcat-fileでそうなってる。
ただ、それを交換出来ないので、テキストやDBに保存したい奴に対応出来てないだけ。
これはGitの構造の問題だよ。
それでsshを別に実装しますとか、かなり馬鹿げた方針だ。
少なくともJS知ってればそうはならない。 Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。 >>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
edとdiffを使ったようなVCSは眼中になかった >>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。
ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
https://www.sqlite.org/fasterthanfs.html >>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな >>712
ただそれはedとdiffが問題だったわけではないだろうし、
仮にそうだったとしても、正しくソフトウェアを構成していればすぐに交換可能で、全く問題にならないんだよ。
その辺がソフトウェア階層の意識がないなあと思うところだよ。
Cはそういう世界でもあるけどさ。
edとdiffで展開するのが駄目なら、他方式の cat-file 階層に交換してしまえば何とでもなるんだよ。
Gitの方式が優れていれば、他VCSがGitの末端階層のI/Oコードを取り込めば済むだけ。
だからそこを問題にする時点でズレてる。
例えばgzipの様なストリーミング方式の cat-file にしてもう動作するし、7zipでも何でもいいんだよ。
(バージョン管理システムの場合は個別ファイルではなくファイルセットでの圧縮なので実際はこれらは適切ではないが)
それでLinusが言ってるように、キモは
> 問題はコード量ではなくて、どのようにデータを扱うかだった。
> 初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。
であって、要はツリーコントロールであって、I/Oではないだろ。 >>714
ああ、ファイルと勘違いしていたのは事実だが、それでも意味は同じだよ。
> gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
勿論その通りだが、つまりこれはファイルシステムであって、その先に隠蔽出来るんだよ。
NTFSかext4かbitlockerを使ってるか圧縮DISKかをアプリは気にしないだろ。
それはOSがファイルシステムの違いを隠蔽してくれるから。これと同じ。
同様に、 cat-file で末端のファイルの形式の違いは隠蔽出来て、
ファイルシステムドライバ（とでも言うべきか？)で、ツリー詳細構造の違いは隠蔽出来るんだよ。
そしてそれは当然Gitにも入ってる。
だからその上位からはGit形式のファイルツリー/オブジェクトツリーを
普通のファイルシステム/オブジェクトと同じように見せることは可能なんだよ。
そして実際にそうしてるはずだよ。
だからな、自分が管轄してる階層以外の所は、はっきり言って関係ないしコードからも見えないんだよ。
Cの場合はその辺の階層意識が希薄で、実際君との空回りもこれだが、Gitもこの辺は正しく実装されてるはず。 >>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ >>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。 >>717
> 逆をやるblobを作るコマンドが用意されてるわけじゃない
ではなくて、用意するんだよ。
そうすれば何でも簡単に出来るようになるだけ。
実際は内部的には持っててコマンドとして公開してないだけだから、実装は簡単だし。
まあ本当にソフトウェア階層の話が通じないので困るが、もう一度懲りずに繰り返してみる。
Cで言うと、printfの先はcrt.oに繋がってるだろ。
アプリはprintfまで管轄してて、crt.oの階層は知らずに済む。
そしてcrt.oをそれぞれのマシンに用意すれば、同じソースコードが動くわけだ。(勿論コンパイル必要だが)
で、そのcrt.oをネットワーク用のにしたらssh先の端末に結果が表示され、
DB用にしたらDBにデータが格納され、
普通のcrt.oを使えば画面に文字が表示される、というだけ。
階層を導入しても苦労する事はないし、
逆にC以外の言語ではI/O階層を導入する以外の方法がない程に一般的だよ。
（と言うかC以外の言語ではI/Oを直接叩くことは一般的に出来ない）
Cは上から下まで全管轄出来るんだけど、無駄にやりすぎてるコードになりがちなのも事実。
なまじ出来るものだからやっちゃうのだけど、それは正しい構成ではないんだよ。 >>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した
hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな もはや名前すらちゃんと覚えてもらえてない hg さん。 >>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。
フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。
ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。
>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが) >>724
いいからお前は自分で作れ git 使う必要はないぞ >>724
結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ
だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない
必要無いものを実装すれば余計なメンテの手間もかかる すごい勢いでスレ消費してるな…
>>676
1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？
それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？
merge squashじゃあかんかね。
連続してない部分的なコミットをまとめるならrebase squashでもいいよ。
連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。
rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。 >>726
ファイルフォーマットというか、
Gitのキモはオブジェクトをハッシュでツリーにして管理すれば全て行けたって事だろ。
そして末端のファイルはblobだけど(既に言ったが)ディレクトリやJSONでもいいし、
中間のファイルフォーマットも実はどうでも良くて、
結局はメモリ上のオブジェクトツリーをどうやってファイルシステムにマッピングするかでしかないんだよ。
traverseさえ出来れば何も問題ないわけでさ。
例えば今のGitはハッシュ上2文字でディレクトリを作って分けてるが、
実は3文字の方が速い場合とかもあるはずだが、そこで階層を正しく切ってないと対応出来ないだろ。
まあこれについてはGitはおそらく対応出来てて、traverseエンジンは多分一つしかないから、それを交換すればいいだけ。
多分DBだとフラットの方が速い。(DB内に高性能のハッシュが実装されてる、というかDBってそれがキモなので)
或いは昔のNTFS(2000かXPの頃)だと、ディレクトリ内にハッシュがなかったので、
同一ディレクトリに20,000個とかファイルを置くととんでもなく遅くなったから、上8文字とか多めにしないと死ぬ。
この辺、つまり上何文字でディレクトリ切った方が速いかは、その下の階層のハッシュの実装によるでしょ。
こういうとき、ちゃんと階層を切ってれば、簡単に切り替えられる、ということ。
そんなの変数で～#defineで～ってのがC流かもしれんが、そういう事じゃないんだよ。
そこでぶった切ることによって、その先が、ファイルシステムであっても、ネットワークであっても、DBであっても、圧縮されてても、
要はtraverseさえ出来れば何でもいい、同じコードで走行出来るし、設定も自由に変えられるし、という自由度が得られる。
代償は関数コールが一段増えることだが、今はこれは問題にされないわけでね。
まあとにかく、後日にしようぜ。
ソフトウェアの階層の切り方についてはゆっくり考えてみてくれ。
基本的には、上記の通り、関数コールが一段増えるだけで無限の自由度が得られるだけ。
Cの場合は#defineマクロで実体を呼ぶかラッパを呼ぶか簡単に切換可能なので、
実際どうするかはともかく、ソースコードはメンテしておくべきだよ。 >>728
現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている
すでにこの共通I/Fに沿っていろいろな実装が存在している
結果これを変更するための内部的なI/F階層が必要とされていない
内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる
切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない
そんなくだらないことに割く労力は無い 長いからまとめたよ。
「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」 なんでgitの話でフレームワークの話が出て来んのかな 無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな
確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。
ファイルシステムみたいなものでは。 あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。
そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。
汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。 そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人 >>729
それも根本的に間違ってる。
ハッシュはハッシュでレイヤーを切るから、正しく構成されてるソフトウェアなら、
ハッシュを変更するのはハッシュ生成関数内だけで済むんだよ。
具体的には、全体は get_hash() を呼んでハッシュを受け取るようにしておいて、
その get_hash() 内でSHA-1かSHA-256かmd5かを変更するだけにするんだよ。
というかこんなの当たり前すぎてお前らが理解出来てないのにびびる。
オブジェクト指向では基本中の基本とされてることだぞ。
お前らプログラマじゃねえだろマジで。プログラマなら、ちょっと勉強し直さないとヤバいぜ。
ただこれは、本質的に「返ってくるオブジェクトのサイズは予想出来ない」事になり、
C的な「返ってくるオブジェクトのサイズは呼ぶ前に完全に予期出来ている（だいたい固定）」の世界にはフィットしない。
C++とかはデストラクタで、その他言語はGCで対応するのが常策だが、
これに関してはバイナリにハードコードで問題ないから#defineでいい。
ただC++だと#defineは悪とされてるから、絶対にデストラクタでやるんだ！いやスマポだ！みたいな奴も居て、
それを勧めてくるからLinusはブチ切れてるわけだが。
だけどハッシュサイズなんて動的に変化すること無いのだから、#defineで全く問題ない。
そしてそれに手こずってる時点で、#defineでの切換すら出来ない、
全体がそれぞれで勝手にSHA-1を生成してたコードになってるって事だよ。
それはマジで糞だよ。(まあ、でも直せば済む話ではあるんだけどさ) >>732,733
これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。
そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、
それで致命的に遅くなるなんて事もないよ。
というか、GitのマージってI/Oバウンドだと思ってるが違うのか？ >>735
ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ
既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ
gitの開発はリポジトリのフォーマットの継続性をとても重視してる >>737
同じだよ。
正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。
つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。
ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、
Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで
普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう）
この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。
が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、
全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。
get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、
なので一々投げ返して操作して貰いますがよろしいですね？とする。 と書くと意味不明だが、この場合は要は貰ったポインタを一々投げ返して操作してもらう。
具体的には、
Hash* hp = get_hash(myObject); // myObjectからHashを生成して貰う、Hashの実体は何か知らない
Stream* sp = traverse(hp); // hashをtraverseに投げてstraem的な何かを示している末端のポインタを貰う、traverseはtraverse出来る何か、ファイルかDBかssh先のストレージか知らんが、とにかくtraverse出来る何かをtraverseして、末端のポインタを返す
GitObject* go = cat_file(sp); // cat_fileに末端のポインタを渡して、GitObjectを貰う
とする。これをOOP文法(Cにはないが）で一般的にはメソッドにして、
Hash* hp = get_hash(myObject); // 管理するのはhashのポインタのみ、中身は知らない
GitObject* go = hp.traverse().cat_file(); // hashを手がかりに翻訳させ、GitObjectを得る
とするんだよ。結果、全体のコードは実際のHashの中身がSHA-1かSHA-256かなんて知る必要もないし、
とにかくtraverseに投げてさらにcat_fileに投げれば、欲しかったGitObjectのポインタが得られる、という構造にする。
こうすれば、本体のコードはハッシュの種類(SHA-1かSHA-2576か)とは依存しなくなる（＝どちらでも全く同じバイナリで動かせるようになる）
そして travserseする実体がDBであったり、末端ファイルの中身がJSONであったりしても、
本体のコードはそれに依存しないから、何でも自由に選べるようになる。
本体のコードは、自身が使う GitObject の中身は知っているが、
それ以外はhashを手がかりに、treeはtraverseに翻訳させ、末端の何かはcat_fileに翻訳させ、その具体的な実体は何か知らない状態で記述するんだよ。
これは拡張性ではなく保守性を上げる為の方策だが、マジで、あおり抜きで、OOPでは基本中の基本だ。
だからフレームワークとかはこうとしか書けないように構成されてるから、一回使ってみれば上手く矯正されると思うぞ。
とにかく、このレベルが理解出来ないのはヤバイってもんじゃない。
多分OOPの授業では1日目とかのレベル。
もっとも、1日目で意味を理解出来る奴は居ないが。
だからOOPって何？みたいな質問が掲示板上でもやたらでてくるわけでさ。 補足。
分からなければ「OOP 抽象化」でググって色々読んでみてくれ。
死ぬほどでてくるはず。マジで基本中の基本だから。
ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない）
ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。
正しく構成すれば、Hash変更なんて簡単に出来るし、
そもそもそうなってないコードなんてOOPでは存在を許されてない。
（そうとは書けないように構成されてる。
それを強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが） 長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ >>741
俺は以下記事の理解書いてる。
俺が書いた事の意味が分からないのは君の問題。
https://www.infoq.com/jp/news/2020/11/git-2-29-sha-256/#:~:text=%E3%81%A4%E3%81%BE%E3%82%8A%E3%80%81Git%E3%81%AF%E3%80%81%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E5%90%8D%E3%81%A8%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%81%AE%E4%B8%A1%E6%96%B9%E3%81%ABSHA-256%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E6%96%B0%E3%81%97%E3%81%84%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E5%BD%A2%E5%BC%8F%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%80%82,%E3%81%93%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E5%BD%A2%E5%BC%8F%E3%81%AF%E3%80%81%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%81%A7%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%9FSHA-256%E5%90%8D%E3%81%A8SHA-1%E5%90%8D%E3%81%AE%E9%96%93%E3%81%AE%E5%8F%8C%E6%96%B9%E5%90%91%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0%E3%82%82%E3%83%97%E3%83%AD%E3%83%93%E3%82%B8%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E3%80%82
ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。
でも、君は確実に老害扱いされてると思うよ。 なんだか知らんけど5chでうだうだ言ってて何になるの >>742
君はその記事の意味することを理解できてないね
コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない >>744
そう思いたいんだろうけど、残念ながらそうじゃない。
少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。
だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。
俺は君に何も強制することは出来ないが。
確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。
でも、ハッシュの中身や長さが変わったり混在したところで、
正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。
そして君と同様の人達によってGitが作られているのであれば、
そりゃそうなってなくて苦労するんだろうさ。
まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。 > GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています
こう書いてあるのになんで無視するんだろう >>745
数行で対応ｗ
それが出来ないgithubは無能集団なんですねｗ
糞MSに買われちゃうぐらいだから仕方ないか Git初心者に語らせると頓珍漢な文章が生まれるという好例 >>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
お前みたいなのが目的と手段を取り違えるタイプの典型
OOPとかアホなプログラマでも理解できる単純なことなわけないだろ
そんなんで済むならとっくに終わってる
まずは常識で考えろ
できないなら黙って勉強しろ >>749
どうであれ同じだよ。
複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。 んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。
>>747
数行ってのは誇張ではなく、実際にそんなもんなんだよ。
例えばMMDは3DVision対応に20-30行と言ってるが、
> そのため、樋口氏がMMDの3D Vision対応に要したのは、20～30行程度の簡単なコーディングのみだった。
> https://pc.watch.impress.co.jp/docs/topic/feature/415525.html
この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが)
確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」
とか言ってたはず。
これは特殊ケースではなく、こうなるように設計するんだよ。
これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。
ソフトウェア工学はそんなのは20年前にクリアしてて、今は、
A. どうすれば変更に対して強くなるか（仕様変更があってもソースコードを変更せずに済むか）
B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する)
C. どうすれば出来るだけ早い段階でバグを検出出来るか
とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、
ABはちゃんとやらないと話にならないよ。
だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、
実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、
今のGitプロジェクトからはこれは出てこないだろう。
となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。
ちょうどGNU/Linuxの形に似てるが。
あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。 > これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ > 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する
シェルスクリプトで頑張るものじゃない git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる シェルでラップw
USPから悪い影響でも受けたか？ OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。
関数指向やクロージャがある言語も同様で
もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。 OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？
結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった
もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね 今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ
それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？
WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。
SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？ 何でもかんでもシェルでやろうとするやつは病気
名前を呼んではいけないあの開発手法とか推してそう >>755
それはどのプラットフォームで問題になったの？
賢い選択とは思えないけどね。
具体的なデメリットは既に666で挙げたとおり。
俺はシェルの互換性問題なんて有ったとは思えないけど、
(昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。
互換性がC化で達成出来るのなら、
既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
なんかやっぱり無能の働き者を地で行ってる気はする。
仕事を減らす努力をしてないよね。 >>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。
で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
(ただこれも想定内っぽいし、
リークしたところでアプリとしては大した問題でもないのも事実だが)
彼等は、バグを直す努力はしているが、
バグが出にくいコードにする努力は全くしてない。
OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、
美味しいところだけ貰えばいいのにとは思うよ。
OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう) ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。 これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)
しかしこのアプローチでは、絶対に浄化はしない。
自分の糞を片づけるのは仕方ないとして、
他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。
しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。
はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。
そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？
（NGにかかったので分割した） それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される >>768
それは無理だね。
仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。
(使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何？でしかない)
GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。
俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。
ただ実際はLinusもこれで、みんな乗り換えて来たから同じ問題を抱えていたんだろ、
という解釈らしいが、いずれにしても使い込んでる奴じゃないといい仕様には出来ないんだよ。
そして例のブランコ問題
> 顧客が本当に必要だったもの
> https://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%A0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE
もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。
そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？
それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。
ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、
ここも手数で勝負だ！と来られたら、為す術もない。
ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。
なるほどエンジニアリングの天才だというのも納得ではある。
だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。
ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、
そもそもあれはどう使う為に設計されたものなのだ？
多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。
今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。 index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。 indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す >>771
> index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。
いや普通に出来るよ。曖昧だったが、俺は git add -u; git commit -m "message"; で使ってる。
以降はワークフローの話だからどちらが正しいとかいう事ではないが、
> コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
これは若干邪道というか基本的に全部commitするものだろうし、commitしてから前に進めばいいだけで、
> どのcommitを取ってきてもちゃんと動く状態にするのが普通だから
これは俺の場合はちょっと違ってて、動かないのもcommitしてるしそれでいいと思ってるんだよ。
master/developブランチでは全部動くべきだけど、
featureでは途中のは動く必要ないし、動くようになったらdevelopにマージして消滅するんだろ？
なら特に問題ない気がする。
途中経過を記録してないことの方が問題で、記録しすぎてたら出力から間引けばいいだろ、というノリ。
だからdiffが画面１枚に収まらないようならcommitする感じ。
実際はbanchを使うのはこれからで、git flow を真似して上記のようにするつもりだが、何かまずいかな？ git分からない思想も理解できないならSVN使えば？ >>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。 適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS >>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。 >>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
他にも、作業中に全然関係ない typo 直したりするのにも使える。 index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。 >>778
> N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
(tutorial2を読んだだけの理解だから間違ってるかもしれんが、)
669で言ったように、Gitが分かりにくいのは業務プロセス名がコマンドに付いてるからだよ。
実際には、git add でスナップショットを取ってて、(←これが直感的に認識出来ない）
git commit でツリーの頭にそれを付け加えてるだけ。
だからaddしてないと付け加えるべきスナップショットがないからコケる。
それで、>>103-107、stashしてたら何処かに存在してるし、
実はaddした時点で保存されてるから、こちらもgcが行われる以前ならhashさえ分かれば引っ張ってくることが可能。
ただし次のaddでindex先が切り替えられてダングリングになり、gc対象になるから、
存在してるかどうかはgcの動作具合による。
(だから初心者向けには、git add でスナップショットが取れてるなんて死んでも言えないし、余計に分かりにくくなってる）
俺が粒度を上げるのなら、commitせずに複数回addする事になり、
2回以上前のはツリーから外されてるのでHEADからでは辿れない。(git fsckなら探せるはずだが)
だから動かない物もcommitしてHEADから辿れるようにしようとしている。
まあちょっと書き方が悪かったかもしれんが。
なので、実際の動作は git add 改め ss (take SnapShot)、git commit 改め relinkなのだけど、
ついでに relink もリストラして ss (git add -u; git commit) と ss -m "message" (git add -u; git commit -m "message")でいい。
これなら alias ss='git add -u; git commit' で済むし、
直感的になってアホでも使える。コミットメッセージが空なら動かない。
これが俺流の「勉強しなくていいGit」だよ。Indexよさらば。アホ向けGitこんにちは。
> マージ前のブランチをレビュー対象とする開発では push の際に整理することになるから
本体リポジトリとルールが違うと収まりが悪いのは了解した。
> 他にも、作業中に全然関係ない typo 直したりするのにも使える。
なるほどこれは微妙に便利かも。
(しかし俺流アホ向けgitでもこれは問題なく出来る。何せgitコマンドはスルーだからな) >>779
いやレビュー対象はcommit済みで、index上ではないだろ。 うんうんわかった
大人しくSVN使え
その方が君には向いている >>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ >>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
FreeBSDにはbash入っとらんぞ >>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！ >>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ >>784
macもbsahやめたんだよね
GPLから逃げるために あと実は、masterの意義も分からないのだが。俺の場合は、
master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード
と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。
と思ってたら、俺にはサル先生方式位が適切な気がしてきた。
> ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。
> https://backlog.com/ja/git-tutorial/stepup/02/
サル先生方式の統合ブランチにタグ打つだけと比べて、
masterとdevelopとして別に持っておいたら何が嬉しいの？ >>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが… >>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ .gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？ >>788
なんだやっぱりブランチのことすら分かってなかったのか logフォルダ作ってそれを無視することにしました
>>794
ごめんなさい！ >>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。 >>796
今自分で「必要だ」って言ったってこと理解してるかい？ >>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。
> また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。
> https://docs.freebsd.org/ja/books/handbook/basics/
自分でインストールしろよ。 だからなんでgit使うだけで
bash＋たくさんコマンド入れなきゃならんのだよ >>797
必要なのはポインタであってブランチではないんだ。
というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。
fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、
git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、
どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。
まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。 >>799
逆に一体どんな環境でやってるのさ？
普通のunixコマンド一式すら入ってないのか？
そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。 >>800
今話をしているのはお前が言ったこと
> 逆に言えば、同時開発する気がなければ要らないわけだな。
if (同時に開発する気がある) {
いる
} else {
いらない
}
自分で同時に開発する気があればいるって言っただろ自分で >>802
ん？どこを誤解されてるのかは分からんが、
俺は複数バージョンを同時開発する気はない。
ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。 >>801
普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。 >>788
少なくともCIで回すときは楽だろ。
Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、
そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？
勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。 >>798
以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない
macOSはbash,gcc,sambaをベースシステムにいれるのをやめた
これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由
linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い
GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね
他のOSSに依存するとこういうのもあるから気を付けないといけない > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
頭おかしい まあdevelopはいらないかな
mainブランチで開発すりゃいいよ
リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい >>798
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
gitの都合でbashに迷惑をかけるな
お前のやりそうなことだな
自分の都合で関係ないやつに迷惑をかける >>808
初心者のお前の感想なんかどうでもいいよ GPLに賛同せずにGNU製品を使ってたってことだろね。
結局Linusもタダ乗り爺ってことでしょ。 ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え
git のブランチは全部等価
デフォルトで main / master 作られるけど
これも使いたくなけりゃ使わなくて良いし名前変えても良い >>805
そんなガキみたいなことはしないが、
どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。
ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね？
自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。
> 少なくともCIで回すときは楽だろ。
必要になったときに作ればいいだけなのと、
多分仕様か実装を間違えてて、今のGitの動作では技術的に実用性がない。
これは次の投稿で詳しく述べる。 A. 消したbranchの情報が確認出来るのって、reflogsだけ？
B. あと、branchは線だ！ってマニュアルは言ってるけど、点だよなこれ？
（ドキュメントか実装のどちらかが間違ってると思うが)
以下git-flowを真似てるとして、gitkと同様に下から上にcommitして、
impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop
としたとする。
このとき、featureXを一々作っては消させてるのだから、
何か簡単に一覧に出来るコマンドがあるべきだが、無さそう。(git log --walk-reflogsで探すことは出来るが)
正直あとから参照することはほぼ無いが、何かあってもいいと思うが？---(A) そして、どうやらGitはブランチローカルという感覚がないらしく？
どのブランチにいても同じ結果が出るのはどうなのよ？---(B)
具体的には、この場合、
masterブランチでは、HEAD~1はinitialを指し、(master上での一つ前)
developブランチでは、HEAD~1はimpl2を指すべき(develop上での一つ前)
だと思うのだが、どこにいてもHEAD~1はimpl4を指してしまう。
つまり、HEAD~Nの探索先はグローバルであり、それは.git/objects下のツリーそのものらしい。
つかね、masterブランチにいた場合、
git diff HEAD~1 HEAD で前回のリリースと今回のリリースの違い
git diff HEAD~2 HEAD で前々回のリリースと今回のリリースの違い
git log ではmasterブランチ上のリリースした物のcommitログだけに絞られて表示
じゃないと実用的な意味がないと思うんだけどさ。
masterにはmergeしかしない運用なら通常は漏れなくタグが打たれ、「点」のアクセスはタグで出来る。
よって残るは「線」のアクセスだが、ブランチは「線」になってない。
実装はよく知らんが、ブランチを切って増えるのは以下の2つで、
.git/refs/heads は先頭「点」、
.git/logs/refs/heads はlogだから、「線」の為の物が無さそう。
本来ブランチはDBで言うINDEXで、CREATE INDEX develop ON git_tree WHERE branch='develop';
みたいなもので、これが「線」だと思うんだけどさ。
実際は「点」なのでHEADしか見えておらず、HEAD~1をブランチによって切り替えられない。
と思うのだが、理解間違ってる？
ここは多分仕様変更した方がいい。(直感的でないし、意味が分からない)
けど今更出来ないだろうから、Gitの仕様の綻びの一つで、next-gitで修正されるべき案件だろうね。 >>806
MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。
> GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった
よく分からんが結局は両方ともここかな？
> プロプライエタリなドライバソフトをLinuxカーネルに読み込む際にDRMの技術を応用している件についてだと思います。
> http://japan.cnet.com/news/ent/story/0,2000047623,20095317,00.htm
> GPLv3ではDRMを実装する場合はそのDRMのアルゴリズムに加えて秘密鍵も公開することを義務付けているので、
> そのようなことをしたらプロプライエタリなドライバを提供してもらえなくなるため、賛成はできない、と。
> https://srad.jp/story/06/01/29/1119224/
ただこれって、
GPLv3のコードを使ったバイナリを配布する際、そのバイナリと同じ物を作れるソースコードも配布しろ、だから、
GPLv3のBashをGit配布zipに同梱してもBashのバイナリだから何ら問題ないはずなんだけどね。
GPLv3だからだめだ、ならGPLv2(～2007)のBashでも十分だろうしさ。
やっぱりかなり政治的だよ。勿論譲れないのだろうけどさ。 >>807
>>809
お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。
Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。
そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、
それは立派なバグだから、bashの連中に投げれば直してもらえるよ。
自分で抱え込みすぎ。それでは回らなくなる。(のが一般的だが、バザールだからなあ…)
ただGNUとは根本的にウマが合わないだろうよ。
仕様はグダグダ、ソースコードはゴミ、でも回り続けてるのだから、GNU(伽藍)から見たら何じゃあこれは！！！ってなる。
Git側にはGNUの開発速度はどうにも認められないだろうしね。 > お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
だからgitの話はgitの中で盛り上がればいいだろ
勝手に他人の家で盛り上がるな
ば～か bashがなんでも修正を入れるわけがない
それは俺の仕事じゃないと言って断られるが落ち
bashをぶくぶく太らせるな
一つ事だけやらせろ >>816
GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい
MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる >>817
GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、
GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり
たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん どのOSでメインに作業してるのかわからん感じだな。
LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも当然DISり、 Windowsなんか論外って感じだろ。
3OSぐらい使ってたらとてもシェルなんか信用できないけどな。 >>822
いやそこまでは全然見てない。
今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。
読む価値のないコードのはずだから。(物によって全然違うかもしれんが)
ただこれで回ってるのは事実だからな～。ちょっと観戦モードだ。
まず既に言ってるが仕様がグダグダ。
仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。
つまりこの辺の常識的な長期保守戦略をまるで知らない奴がやってて、止める奴もいないということ。
そして今回のメモリリークだが、確保したらそこで寿命も確定する、実装が一番簡単なタイプで、
これをリークさせるようなら話にならない。
ただそれでもミスることはあるが、出てきたパッチがこれまたグダグダで、Cのメモリ管理の基本を完全に無視してる。
レビューがあったら見た瞬間落とされるソースだ。そりゃリークするよな、としか思わない。
(ただし第２弾、第３弾も出てきて、ましになりつつあるが、それでも方向性を根本的に間違ってる。
とはいえ、展開が異常に早いのも確か)
だから、通常の開発をやっているであろうGNUでは、仕様のレビューでも、コードのレビューでも落とされる。
だけどGit側にその理由を理解出来る奴がいないからこうなわけで、当然ブチ切れる。
そして喧嘩別れ、だったら俺らで作るからいいよ、でforkして突っ走ってるだけのように見える。
若すぎる。
ただそれでも実装能力だけはあるので、diffはGNUより装飾周りが断然進歩してる。
これはやっぱりGNUdiffと一緒にやってた方がみんな幸せだったと思うよ。
上手く導ける奴がいれば、
というより普通に長期保守したことがある奴が上層部に一人でもいれば、この辺は簡単に修正出来ると思うのだけど、
それは伽藍タイプの話で、バザールだとどうにもならないのかもしれんし、
突っ走らせないとプロジェクト自体が死ぬのかもしれんし、(サメみたいにね)
よく分からん。 >>823
自分が理解できないものは全部糞
理解力が致命的に弱い
この2つが合わさると全方面Disることになる >>817
何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか？
金も貰えないのにそんなの苦行でしょう、アホらしい
それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか？ bashの方を直せって言うなら
GNU bashのプロジェクトに殴り込みをかければいいじゃん
お前が >>828
逆だよ。他人に投げられることは他人に投げろと言ってる。
bashのバグだってことになれば、勝手に直してもらえるだろ。
自分で対応するのは、直してもらえないのが確定してからでいい。
>>829
そもそも俺はbashの互換性で苦労した試しがない。
ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。
あーだから、最悪Linux/Windows/Mac用と3種類用意すればよかったんじゃね？C化よりは楽だろうよ。 > 逆だよ。他人に投げられることは他人に投げろと言ってる。
なんのために？ > bashのバグだってことになれば、勝手に直してもらえるだろ。
だからお前がbashに通報しろって
お前という他人に投げたぞｗ
さっさとやれ >>830
え、Cでプログラム書いたことないの？OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ…
考慮しなければならないのはファイルシステムと改行コードぐらいだろう。 まあおまえら落ち着け>>815とか見る限りこいつはひとりではGitを理解できない
炎上させて答えを引き出そうとしてるから餌を与えちゃいかん
ほっとけばすぐいなくなるよ >>834
ああ、@1か、これは失礼。
ただお世辞にも分かりやすいとは言えないねこれは。
まあでも、ならbranchを残す意味はあり、>>815は取り下げだな。
>>814については引き続き募集中。 >>836
@{1}に気が付くとはさすが軍師殿ｗｗｗ HEAD~1 で一つ前のリリースとか言ってて爆笑
リリースごとに一回だけコミットするつもりなのか？
永久に git 理解できそうにないな ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな
つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか そもそも一つ前ｗみたいな考え方するようなものじゃないよなｗ 自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな
POSIX原理主義者と一緒。POSIXの名前を勝手に使って
シェルスクリプトしかできないのをごまかしてる
gitを利用してシェルスクリプトしかできないのをごまかしてる >>717
ちなみに書く側のコマンドは hash-objectのようだ。
多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。
そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。
>>821
って、ふと気づいたが、俺が使ってるのはGitBashだったわ。
現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。
Macは政治的だとして、Linusはその辺実務的に見えるから、
GPLv3をボロカス言って自分はGPLv3には参加しないが、(これは正当な権利で全く問題ない)
GPLv3を殺す為にGPLv3のプロダクトの同梱すらしない、みたいなことはしないのだろうよ。 >>814
公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。
つまり熟知してる公式からみても面倒な作業だと認めているわけだ。
解決というよりは諦めと納得だが、これも質問を閉じる。
> https://zenn.dev/yoichi/articles/git-restore-branch
ちなみに、branchを『後から追加』は出来るか？
いやそんな使い方はおかしい！禁止だ！かもしれんが、
やはり俺にはbranchはただの(DBにおける)INDEXで、
随時落としたり作ったり復活させられないと使いづらい。(のではないかと予想している)
ただ、要はreflogを偽造すればいいだけのようだが、
再実装は時間の無駄でしかないので、既にあればそれを使いたい。 >>842
index-stageを理解してないおまえにはわからないかもしれないけど、
DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、
逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、
そんな単純にはいかない >>842
Windowsはアプリを実行する上でコード署名が必須でないから問題にならないだけ >>843
gitのマージを全然理解できてないからブランチを復活させたいとか思ってしまうんだな
普段の運用でスクリプトを使ってブランチを復活させたいとか思う羽目になることはあまりない
ブランチがDBにおけるindexみたいなものとか、後から追加できる？みたいな疑問が生じるあたり、ブランチが何なのか全然わかってない
reflogの偽造が必要という発想もかなりズレてるし、>>814 をみるとコミットの履歴がどういうものなのか理解できていないのだろう >>844
さすがにその程度は知ってるぞ。
ただ、一般的には git add -A で問題ないディレクトリ構成で使う方が多いんじゃないか？
まあそれはさておき、
要は、正しくソフトウェアが構成されてれば、cat-file/hash-object を組みで交換すれば、
末端のファイル形式は自由に選べるって事だよ。sshにすればネットワーク先にも余裕だ。
つってももうこの話は通じないのでいいが。 >>845
つまり現行2.38.1のMac版にはBashバイナリが入ってないのか？
それでMacに元々入っているbash以外のshを使ってれば、そりゃ問題は発生するだろうさ。
> https://qiita.com/ko1nksm/items/59c2e8a7afa969af8212#:~:text=Mac%20%E3%81%AE%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%20macOS%2010.15%20Catalina%20%E3%81%A7%20bash%20%E3%81%8B%E3%82%89,%E3%81%AB%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%9F%E3%81%A8%E4%B8%80%E8%88%AC%E3%81%AB%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8C%E3%80%81%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%95%AA%E5%8F%B7%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E9%99%A4%E3%81%84%E3%81%A6%E4%BB%A5%E5%89%8D%E3%81%A8%E3%81%BB%E3%81%A8%E3%82%93%E3%81%A9%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82%20%2Fbin%2Fsh%20%E3%81%AF%20POSIX%20%E3%83%A2%E3%83%BC%E3%83%89%E3%81%A7%20bash%20%28%2Fbin%2Fbash%29%20%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%BE%E3%81%99
Macとしては署名済みじゃないとウイルスかもしれないので認められず、
GPLとしては署名付けるならその署名を作るソースも公開しろと言ってるわけ？
どっちも拗らせすぎだが、
一般論としては、Mac側に「開発者オプション」で「署名がないバイナリの動作を許可する」があれば済む話では？
実際自分でコンパイルしたバイナリを動かせないと困るし。
ただ、Macってスマホと同一化したからこれって脱獄になるんだっけ？
ならまあ、Gitの為に脱獄はないし、こじれるのは分かるが。
まあ、正直つき合いきれないが、俺なら、C化ではなく、
bashの機能を諦めてshの機能だけで書き直す方を選択するけどね。 >>847
実際仕事すればわかるが add -Aで綺麗なコミットを作れるように整備されてるリポジトリはあまり無い
デバッグしながらコミットしていくときは add -p を使うことがとても多い git add -Aで十分とかさぁ、開発経験なさすぎだろ
それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
通常なにかのバグの修正とか
複数の個別の問題の複合なのに
それ全部まとめんな >>846
そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、
単に便利だから使ってるだけだと思うがな。
理解せずに使えるのならそれに越したことはない。
(この価値観が相容れないのは理解したからもういいが）
君はGitを履歴追跡ツールとしてしか見てないようだが、
俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB)
そして、俺は>>808と同意見で、
開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。
常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、
hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。
(なおreleaseブランチは最後にバージョンを打つ奴にはいいが、
俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない）
それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、
git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。
featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、
名前が似てるだけの別物扱いになるので、
featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。
実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、
まあGitの文化でこれはなかった。
が、まあ、俺的にはこれであって欲しかったね。
「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」
「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。
ただこれ、branch側は --list オプションで表示を簡単に絞れるから、
Gitの思想としてはbranchは「消さずに全部残しておけ」で、
git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。 >>852
世の中に理解しないで使えるものなんてない 大体gitの使い方を理解したいと思ってるやつはアホ
理解するのはバージョン管理の仕方だ
こうやってツールの使い方を学ぶことが理解だと思ってるから
gitがなくなったらどうしよう
また新しいことを学ばなきゃいけないってなるんやろ >>854
git そのものを理解すること諦めたか
でもお前使い方の方も盛大に勘違いしてるよ >>851
> それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
> 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
そうだぞ。
ブッ込んでおけば後で何とでもなるただのバケツでしかない。
バケツの使い方を学べとか、知るかボケだ。
後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。
大方、プログラマの大半はこの程度の認識のはずだぞ。
そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。
だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。
今のGitにこの機能がないだけ。（まあ近い機能はあるが）
DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。
sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。
まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？
連中にとっては直感的になるから。 > 大方、プログラマの大半はこの程度の認識のはずだぞ。
お前の周りの無能集団だけだろ 一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ データの取り出し方なんか知っていても
過去のコミットのミスを簡単に直せないなら
バージョン管理は苦痛になるし
やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな
バージョン管理が不便だからgitが作られたんだぞ >>859
俺はそれでいいと思うけど。
記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。
>>860
今のGitの修正は十分苦痛だよ。
修正させたくないから面倒にする、は間違いで、
簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。 × 俺はそれでいいと思うけど。
○ 無能はそんなことをしている。
まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ
そこから勉強しなよ > 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
お前はテキストエディタで保存するたびに
gitにセーブしろって言ってんのか？ｗ >>863
俺が言ってる「修正」は、Git自体の修正で、
> なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになる (778)
の場合に、SQL的に、
DELETE FROM my_repo WHERE branch='featureX' AND commit_message='';
あるいは、
CREATE INDEX beautiful_featureX ON my_repo WHERE branch='featureX' AND commit_message='';
で済むのに、何故Gitにつき合ってグダグダやらねばならんのだ？ということ。
それとは別に、ちょこまかcommitしても、俺は構わんと思うけど。
上記のように、それを１コマンドで除去出来れば、実務上何ら問題ない。
粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。
bitcoinはこの方式だ。
>>862
多分根本的に違うのは、
俺： 俺のワークフローに合うようにツールをカスタマイズする
863： Gitのワークフローに合わせてgitを使え、それ以外認めない！
なんだよ。
Linusが個人的に開発したんだからGit自体はそれでいいんだが、
全世界でLinuxと同じワークフローが適切なわけではない。 >>864
アホなの？コミットメッセージは毎回入れるものだ >>864
> 全世界でLinuxと同じワークフローが適切なわけではない。
だからgitはいろんなワークフローに対応してるんだろうが
お前のはバージョン管理のワークフローではない
ただのバックアップのワークフローだ まあ1人プロジェクトみたいだし好き勝手やらせればいいさ コミットメッセージが空だったら～とかわけわからんなｗ 行単位で独立してるデータベースのデータじゃないんだからさぁ
ソースコードは前後の歴史とつながってる
DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀 >>869
それは当然UIの話で、当たり前だが内部のリンクは接続し直すんだよ。
そしてそれをユーザーには見せない。
多分ここら辺の階層の話がGitには存在しないんだよ。
だからユーザーがviでリンク書き換えろとかの勢いだろ。
超密結合だし滅茶苦茶だよそれは。 >>870
都合が悪いからって無視するな
前後のソースコード関連してるから
途中のコミットを取り除くことはできないと言ってる つまり、両親がイブに中出ししてお前が生まれたという歴史において、
イブの中出しだけを無かったことにはできないと言うことだね
その後の歴史でお前が存在するのはおかしいし >>871
何言ってんだ？
中身はただの単方向リンクリストだぞ。
リンク先が複数のこともあるが、それでも問題なく抜ける。
ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
CREATE INDEXを使うが。これなら理解出来るか？
だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。
それがDELETEしたものと同じ物になる。これで理解出来るか？ >>873
じゃあ抜き取ってみ
・commit 1「aaa を追加」
aaa
・commit 2「bbb を追加」
aaa
bbb
・commit 3「bbb を ccc に置き換えた」
aaa
ccc
ここからcommit2を抜き取ったときの
commit3の修正内容をよく読んでみろ >>873
残念だけどそこから間違ってる
Gitのコミットのリストは単方向リンクリストではない
なのでリストの途中のコミットを削除したり途中に追加できない >>874
ああコミットメッセージについては考えてなかったが、
俺ならそのままぐちゃっと貼り付けるけど。
つまり、
・commit 1「aaa を追加」
aaa
・commit 3「bbb を追加」「bbb を ccc に置き換えた」
aaa
ccc
になる。 >>875
親が複数あるだけの単方向リストだよ。
まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？
ツリーが複数重なり合った状態になってるだけだよ。
単線の A<-B<-C なら A<-C になる。これは自明だよな。
マージの場合、(BがADのマージ結果ね）
A<-B<-C
D<-|
を
A<-C
D<-|
にする。 >>876
ようやく理解したか。
だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ
バージョン管理というのは何をどう変えたかという変化を記録するものだ
スナップショットじゃねーんだよ、あーほ >>876
bbbの話がないのだから、
書き間違えなのか全く区別がつかない
バグコミットメッセージだな >>873
> ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？
ファイルを保存するたびにコミットするんだろお前は？
バージョン管理で記録するのはソースコードの修正履歴であって
お前個人の作業履歴じゃねーんだよ
使い物にならないゴミコミットを作るな >>878
ああ履歴についての認識が違うんだな。了解した。
履歴は、
俺： スナップショット＝「点」の並び
君： 変更した線の並びで、それはcommitメッセージに現れる。
それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、
commitメッセージなんて目安に過ぎないんだよ。
Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
差分ではなく本体を記録するだろ。 >>881
> 履歴は、
> 俺： スナップショット＝「点」の並び
だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ
> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ
> commitメッセージなんて目安に過ぎないんだよ。
はっｗ バージョン管理の素人が。
コミットメッセージの重要性を知らない時点で終わってるよ >>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。
間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。
所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。 > Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
> 差分ではなく本体を記録するだろ。
だから最初からバージョン管理は差分を記録するものであり
gitの優れた点が、発想の転換で
本体を記録することで差分を表現することにした点なんだろ
実装の話とごっちゃにするな
そういうところが技術的に未熟なんだよ >>883
> そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
そりゃお前が素人だから問題であることに気づいてないだけ
誰もやってないからね
> この辺はポリシーだし、好きなようにすればいいと思うがね。
お前が未熟だから反論できずにポリシーってことにしようとしてる >>877
分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、
あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ
なのでGitではそれができないようにデータ構造が設計されています > 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。
コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ
お前はただ見れればいいと思ってる
バージョン管理を理解してない >>883
> 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ >>882
まあ君と仕事することは無さそうだから別に問題ないけど、
> 修正しろよ。それが出来るように作られているだろ
コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
管理してるのはメッセージじゃなくてソースコードなんだから。
それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。
コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
> はっｗ バージョン管理の素人が。
> コミットメッセージの重要性を知らない時点で終わってるよ
まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。 > コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
それはお前だけの感想ですねｗ > まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
バージョン管理の素人だって言ってる
お前、他の人と一緒に仕事ができないよｗ > コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ >>889
こうやってコミット履歴をちゃんと見れて
なんの変更をしたのかわかるようになるまで頑張れよ
https://github.com/freebsd/freebsd-src/commits
お前のコミットは汚すぎて
使い物にならんのだわ >>884
> gitの優れた点が、発想の転換で
> 本体を記録することで差分を表現することにした点なんだろ
これは違う。
というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。
ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。
だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。
あまり関係ないからこの話は終わりで。 > これは違う。
だーかーら、素人のお前の意見なんか聞いてない https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965
なぜスナップショットとして記録するのか
スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。
詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、
Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。
このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。
Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。
ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは
当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。 >>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。
というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。
ところで、
実は今もbranchの実体がどこにあるのか見えてない。
見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？
これだと毎回reflogを動的に解釈することになるが。
実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。
なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。
だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。 > 後からでもいくらでも作れるだろ、という話。
だから速度重視だって言ってる >>898
君、ほんと知らないなら黙ってたほうがいいよ
恥ずかしいだけだから >>898
> 余分なcommitはrepoから消せ！とする君らにとっては問題だが、
余分なコミットじゃなくて、
コミットとして使えないものにする
バグコミットを消せと言ってるだけ >>898
まあもう面倒臭くなってきたので全部説明しちゃうが
結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている
その自分のコミットオブジェクトから計算して求めるのが自分のhash
親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない
ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
ず〜〜〜と思っているんだがどう考えてもお前のブランチへの理解はオカシイ
内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える
だから >>815 みたいな謎発言がでてくる
DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない >>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。
ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。
ただまあ、親ハッシュは混ぜ込んでるのは理解した。
> ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それは俺の最初の理解、「点」なんだよ。815の通り。エントリポイントだけ、というわけだろ。
ただそれだと、オブジェクトツリーは辿れるが、
master @{1}で「master branch上の」一つ前、という経路情報に変換することが出来ない。
つまり、HEAD~! != @{1} とするには、何らかの情報が何処かに必要なんだよ。
そして今のところ、reflogしかないので、そこを動的に辿ってるのか？みたいなことになってる。
だから「reflogを偽造」(843)なんて話になる。
言い換えると、エントリポイントからだと、親は辿れるが、
親が複数現れたとき(マージ）に、どちらから来たのか分からないのと、
fast-forwardマージでオブジェクトは一本道でもbranch上では飛ばしている場合に、その情報がないんだよ。
これはどこに格納されてるんだ？ すまん、分かると思うが、 HEAD~1 != @{1} >>903
reflogのhashは、HEADが変わるような操作をしたときに、その操作の結果のHEADのhashを追記していくだけのログだよ
このログがその後のgitの動作に影響を与えることはない
HEAD@{0}が常に最新の操作に対応したhashに更新される
だからたとえばmasterとfirstという二つのブランチを交互にcheckoutすればこんな感じになる
$ git reflog
0956cde (HEAD -> first) HEAD@{0}: checkout: moving from master to first
be7e7d7 (master) HEAD@{1}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{2}: checkout: moving from master to first
be7e7d7 (master) HEAD@{3}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{4}: checkout: moving from master to first
be7e7d7 (master) HEAD@{5}: checkout: moving from first to master
最後にcheckout firstしたので HEAD -> first になってる >>905
reflogがその形式なのは知ってる。
ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。
例えば、815の場合、再記するが、
impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop
これで、master上で
git diff @{1} では、initial commit との差分
git diff HEAD~1 では、 impl4との差分が出るんだよ。
これが、master->impl5のエントリポイント情報だけだと出来ないから、
maseterはinitial->impl5に移動しましたよ、という経路情報が何処かに必要なんだ。
それで、git reflog では、
どこにswitchして、commit して、mergeした、という履歴が全部出るから、
（多分だが各HEADのreflogを全てcatして時系列にソートしてる）
解釈すれば可能ではあるけど、そんな面倒なことするか？普通はstaticにシャローコピーだろ、というのと、
reflog は gc されるので、reflogを頼りにする実装は不適切だし、
俺的にbranchを消したり復活させたりする使い方はヤバそうなんだよ。
だからその辺を確認してる。
それで、後で任意のオブジェクト群でbranchを作れるのなら、この辺心配ないのだけど、そうではなさそうだし。 ちなみに、843の記事では、Git内のcontrib内のスクリプトが、
branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい。
確かに目で見た限りそうだが、
でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。 ごめん、書き方が悪かった。
907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。
復活させるときにそこにしか手がかりがないのは仕方ないとして、
生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。 >>906
そのリポジトリがどういう構造になっているかわけわからん
git show-branch してみろ >>909
すまぬ、確かに今見てればちょっとおかしい。
もう一度作るから30分ほどお待ちを。 >>909
結果
$ git show-branch
! [develop] impl5
* [master] impl5
--
+* [develop] impl5
$ git branch
develop
* master >>909
$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
$ git diff @{1}
diff --git a/test.txt b/test.txt
index e79c5e8..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,7 @@
initial
+impl0
+impl1
+impl2
+impl3
+impl4
+impl5 >>909
再現コード
#!/bin/bash -x
#
git init
echo 'initial' > test.txt
git add test.txt
git commit -m 'initial'
git branch develop
for (( i=0 ; i<6 ; i++ ));
do
git branch feature$i
git switch feature$i
echo "impl"$i >> test.txt
git add test.txt
git commit -m "impl"$i
git switch develop
git merge feature$i
git branch -d feature$i
done
git switch master
git merge develop >>909
ちなreflog
$ git reflog
1a804d9 (HEAD -> master, develop) HEAD@{0}: merge develop: Fast-forward
b0325fc HEAD@{1}: checkout: moving from develop to master
1a804d9 (HEAD -> master, develop) HEAD@{2}: merge feature5: Fast-forward
ba4e962 HEAD@{3}: checkout: moving from feature5 to develop
1a804d9 (HEAD -> master, develop) HEAD@{4}: commit: impl5
ba4e962 HEAD@{5}: checkout: moving from develop to feature5
ba4e962 HEAD@{6}: merge feature4: Fast-forward
a32e11d HEAD@{7}: checkout: moving from feature4 to develop
ba4e962 HEAD@{8}: commit: impl4
a32e11d HEAD@{9}: checkout: moving from develop to feature4
a32e11d HEAD@{10}: merge feature3: Fast-forward
8d9924f HEAD@{11}: checkout: moving from feature3 to develop
a32e11d HEAD@{12}: commit: impl3
8d9924f HEAD@{13}: checkout: moving from develop to feature3
8d9924f HEAD@{14}: merge feature2: Fast-forward
0f78740 HEAD@{15}: checkout: moving from feature2 to develop
8d9924f HEAD@{16}: commit: impl2
0f78740 HEAD@{17}: checkout: moving from develop to feature2
0f78740 HEAD@{18}: merge feature1: Fast-forward
47792a3 HEAD@{19}: checkout: moving from feature1 to develop
0f78740 HEAD@{20}: commit: impl1
47792a3 HEAD@{21}: checkout: moving from develop to feature1
47792a3 HEAD@{22}: merge feature0: Fast-forward
b0325fc HEAD@{23}: checkout: moving from feature0 to develop
47792a3 HEAD@{24}: commit: impl0
b0325fc HEAD@{25}: checkout: moving from master to feature0
b0325fc HEAD@{26}: commit (initial): initial >>909
ついでに一応、終了時のtest.txt
$ cat test.txt
initial
impl0
impl1
impl2
impl3
impl4
impl5 >>911-915
これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる
どっちのマージにするかは現場の運用しだい git log --graph --branches --oneline とかするとわかりやすい >>916
ああ、それがrebaseしないと履歴が無くなるとかいう話か？
実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、
俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ)
けしからんか？
それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、
どこにあるのか分かれば教えてくれ。 HEAD~1と@{1}は全然関係無いよ？
HEAD~1は今のHEADの一番目の親のhash
親が複数いるときにはHEAD^1とかHEAD^2とかで指定する
@{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い >>914 で説明すると、
@{0}は最後のコミットで、FFマージした結果masterとdevelopがこのhash=1a804d9になった
@{1}はgit commit -m 'initial'の結果できた最初のコミット(最後のマージ操作の前のmaster)で、最後にこれにdevelopをマージするためcheckoutしたらこれになってる >>920
> @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
だから、それは「そのbranchの」一つ前の操作なんだよ。
結果、diffは、masterブランチでは>>912で、HEAD~1 != @{1} だが、
developブランチでは、以下になって、 HEAD~1 == @{1} なんだよ。
$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
$ git diff @{1}
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
だからmasterブランチをdevelopにmergeしかしない運用をした場合、
masterブランチは @{n} でn回前のリリースが検索出来、存在価値が出てくる、という見立てだが、間違ってるか？
(@はcommit履歴だと思ってるが、まさか操作履歴か？なら確かに意味無いし、先頭情報しか要らないし、reflogしかなくても納得だが) 最終的にお前のリポジトリは git merge develop でこうなっているはずだ
$ git log --graph --branches --oneline
* 1a804d9 impl5 (HEAD -> master, develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial
最後のひとつ前の git switch master をやったときにはこうなっていたはず
* 1a804d9 impl5 (develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial (HEAD -> master)
だから HEAD@{0} = 1a804d9 で、HEAD@{1} = b0325fc >>921
@はやっぱcommit履歴だよな？
エントリポインタだけだと、commit履歴に出来ないんだよ。
今回はfast-forwardマージしてるから、
init<-0<-1<-2<-3<-4<-5 = master, develop
で、単にエントリポイントだけなら master も develop も同じ 5 で区別がない。
当たり前だが両方とも HEAD~1 は4を指してる。
ただ、@{1}は、commit履歴だから、masterでは init を指し、developでは4を指す。
この、commit履歴情報はどこに記録されてるの？というのが俺の質問。
>>923
そこは理解出来てるはず。上記の通り。
問題はcommit履歴がどこにあるか。 >>922
masterブランチをdevelopブランチにマージする方法が
git switch masterとgit merge developの連続実行だけではないし、
HEAD@{n}は適当なタイミングでGCされるから、
HEAD@{n}をそんな用途に使う奴はいない >>924
commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ @はcommit履歴じゃなくて、reflogの履歴 >>926
$ git log --graph --branches --oneline
* 1a804d9 (HEAD -> master, develop) impl5
* ba4e962 impl4
* a32e11d impl3
* 8d9924f impl2
* 0f78740 impl1
* 47792a3 impl0
* b0325fc initial @{n}はカレントブランチのreflog履歴になるはず
reflog履歴はブランチ毎に存在するので
master@{n}とdevelop@{n}は違うハッシュになってるはず
git reflog masterとgit reflog developで比べてみればわかる >>917,926
ちな --no-ff 版、
今出すと余計に混乱するかもだが。
$ git log --graph --branches --oneline
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
|\
| * e03bcd0 impl5
|/
* 324df68 Merge branch 'feature4' into develop
|\
| * c2634c4 impl4
|/
* 68ed20a Merge branch 'feature3' into develop
|\
| * 5e12b99 impl3
|/
* 608e5d7 Merge branch 'feature2' into develop
|\
| * 4660e46 impl2
|/
* 3924eae Merge branch 'feature1' into develop
|\
| * 138d83f impl1
|/
* 7db4424 Merge branch 'feature0' into develop
|\
| * 8877414 impl0
|/
* ec041f9 initial >>929
$ git reflog master
1a804d9 (HEAD -> master, develop) master@{0}: merge develop: Fast-forward
b0325fc master@{1}: commit (initial): initial
$ git reflog develop
1a804d9 (HEAD -> master, develop) develop@{0}: merge feature5: Fast-forward
ba4e962 develop@{1}: merge feature4: Fast-forward
a32e11d develop@{2}: merge feature3: Fast-forward
8d9924f develop@{3}: merge feature2: Fast-forward
0f78740 develop@{4}: merge feature1: Fast-forward
47792a3 develop@{5}: merge feature0: Fast-forward
b0325fc develop@{6}: branch: Created from master
ってことは、commit履歴はreflogにしか無いって事か？
ならbrahchを消すとreflogも消されてcommit履歴が消えるが、マジ？
これだとbranchの復活は本質的に無理なことになってしまう。
(他branchに断片的には残ってるんだけどさ） >>928
impl5のコミットオブジェクトの hash = 1a804d9
impl5のコミットオブジェクトの中には親のコミットオブジェクトimpl4の hash = ba4e962 が格納されている
impl4のコミットオブジェクトの hash = ba4e962
impl4のコミットオブジェクトの中には親のコミットオブジェクトimpl3の hash = a32e11d が格納されている
impl3のコミットオブジェクトの hash = a32e11d
impl3のコミットオブジェクトの中には親のコミットオブジェクトimpl2の hash = 8d9924f が格納されている
impl2のコミットオブジェクトの hash = 8d9924f
impl2のコミットオブジェクトの中には親のコミットオブジェクトimpl1の hash = 0f78740 が格納されている
impl1のコミットオブジェクトの hash = 0f78740
impl1のコミットオブジェクトの中には親のコミットオブジェクトimpl0の hash = 47792a3 が格納されている
impl0のコミットオブジェクトの hash = 47792a3
impl0のコミットオブジェクトの中には親のコミットオブジェクトinitialの hash = b0325fc が格納されている
initialのコミットオブジェクトの hash = b0325fc
initialのコミットオブジェクトはルートなので親のコミットオブジェクトが存在しない
つまり impl5のコミットオブジェクトの hash = 1a804d9 からたどっていけば、コミット履歴が全部わかる
親が複数存在する場合には複数の親のhashを格納する >>930
￥で表示されるとちょっと見にくいが、慣れれば見やすい >>931
逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね
それを説明してるのが >>902 >>930は最後のdevelopのマージが --no-ff になってないな
最後のも --no-ff にするともっと面白いぞ >>932
ごめん、それは分かってる。
それはグローバル履歴＝gitオブジェクトを辿った履歴、だろ。
問題は、masterのcommitには b0325fc と 1a804d9 しかない、という情報が、
今のところ master の reflogにしか見あたらないんだよ。
だから、各branchを消したら、それ以前の gitオブジェクト は全部辿れるが、commit履歴は消失してしまう。
今のmasterみたいに、fast-forwardマージで中間をすっ飛ばしてきた、
という情報が無くなってしまうんだよ。
だから、branchを消す前の状態に完全には戻せない、という話。
だから、常識的に考えればもうちょっとましな何処かに保持してるはずなんだけど、無いんだ。 >>935
ほい
$ git log --graph --branches --oneline
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
|\
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| |\
| | * 4b27393 impl5
| |/
| * 9bfb8cc Merge branch 'feature4' into develop
| |\
| | * c2a5b7d impl4
| |/
| * 02d2308 Merge branch 'feature3' into develop
| |\
| | * f6d1cf7 impl3
| |/
| * 81e18bb Merge branch 'feature2' into develop
| |\
| | * 01c3871 impl2
| |/
| * 5b57f48 Merge branch 'feature1' into develop
| |\
| | * 0fe34d2 impl1
| |/
| * 6272da6 Merge branch 'feature0' into develop
| |\
|/ /
| * fe1b132 impl0
|/
* 832f464 initial >>936
FFマージしたらその情報は消滅するな
--no-ff で全部マージすれば複数親のハッシュをもってるコミットオブジェクトの1番目だけたどればいける
^1 だけみていくね
git log にはそれをやるオプションがあるはず
>>930をそのオプションで表示すればこんな風に表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial >>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial >>938
$ git log --graph --branches --oneline --first-parent
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial
>>939
$ git log --graph --branches --oneline --first-parent
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| * 9bfb8cc Merge branch 'feature4' into develop
| * 02d2308 Merge branch 'feature3' into develop
| * 81e18bb Merge branch 'feature2' into develop
| * 5b57f48 Merge branch 'feature1' into develop
| * 6272da6 Merge branch 'feature0' into develop
|/
* 832f464 initial >>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな >>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。
そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は大して食わない）
--no-ff がデフォのほうがよかった気がするが。
まあとにかく了解した。長々とありがとう。 >>943
ffがデフォのメリットって何だ？特にないと思うが。見た目すっきり、か？
ただまあ、デフォだし、サル先生他も特に何も言ってないので、ffでの運用が多数派なのだろう。
--no-ffはcommitオブジェクトが別に作られるだけで、
スナップショットに比べたらゴミなので全体としては大して増えない。
commit履歴はgitオブジェクトツリー内に混ぜ込まれ、完全に保持される。
ffの場合は、commit履歴情報はreflogにしか無いので、branchを削除したら基本的に失われる。
そしてreflogもgc対象なので、Linusはcommit履歴は基本的に保持する必要がないとの立場なのだろう。
また、branchを削除しろといいつつffなのは、その人達もcommit履歴は要らない、と考えていることになる。
ただこれは奇妙な実装だ。
カーナビを考えれば分かるが、当たり前だが地図情報とルート情報は別なのだ。混ぜ込むのはあり得ない。
commit履歴が要らないってのは、経路(線)は不問で、目的地(点)に着いてるかどうかだけだ、と言っているわけ。
それはバージョン管理の達人()にとっては、違うんだろ。バージョン管理は「線」であると！
ただ、Linusも「点」の立場だね。まあプログラマ的にはこれで正しいんだよ。
コンピューターは今現在のソースコードしか見てなくて、どの経路を辿ったかなんて関係ない。
だからどういう紆余曲折(「線」)があったかではなく、結局は前回の「点」と今回の「点」のdiffだけが価値を持つ。
そしてLinusの個人的ツールであるGitも、この流れなわけだ。
とはいえ俺はルート情報はまた別に重要だと思うから、保持したい。
混ぜ込まれてる場合は後からbranchを追加することが絶対に出来ない。
まあ開発ツールとしては別経路から同じ点に到達しました！なんてのは現実的にあり得ないから、
偽造を防ぐ為にもこれでいいのかもしれんが、一般的に考えればこの実装は奇妙だ。
ちなみに一般文書、例えばEULA(EndUserLicenseAgreement)とかの隙を潰していくタイプの法務文書等は、
別経路だが最終到達時点は同じ、ということが普通にあり得るはず。
だからやっぱりGitはソースコード向けにしか出来てない、ということは認識しておくべきだろう。 あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が異なってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能)
それは正しく説明しなければならない。
密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。
とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。
ただ、そもそも仕様がグダグダ過ぎるし、
或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。
おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。
とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。 ただこれだと、branchを「線」として扱おうとしたら動作が不安定になるわけで、
おそらくfilter-branchが不安定なのはこの辺に起因してる。
そしてドキュメントの何処か(多分showかlog)に、
「これには実はpitfallがあって、マージに遭遇した場合に分岐するから云々」とかいう
(当時の俺にとって)謎の記述が挿入されてたのも納得がいく。
commit履歴を保持してないから確定的動作が出来ないんだよ。
これははっきり言って仕様の欠陥で、commit履歴も完全に保持する仕様だったら自然と回避出来てた。
現仕様では、filter-branchの実装をいくら頑張ったところでどうにもならない。
代わりのfilter-repoも、動作は同様に糞だろうよ。安定して使えるものではないはず。
ここら辺はちょっと惜しいね。Gitが素晴らしいのは、「伽藍とバザール」での
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
を体現してるからであって、つまり根っこがしっかりしてるから上部は雑草でも問題なかったんだが、
この点は根っこが駄目だから、上部(filter-branch)が機能しない。
ここら辺はちゃんと仕様の大切さを理解してる奴が仕切らないと駄目なのだが、
おそらくGitの連中も、仕様を捏ねてる連中は手を動かしてないと見なし、嫌ってるのだろう。
だから仕様を捏ねることすらしてない。
ただ、それは結局は遠回りでしかない。
今のGitだと、filter-branchも、filter-repoも、その次に出てくる何かも、まともに動作するはずがない。
駄目な仕様だと実装をいくら頑張ってもどうにもならない、と知ってる奴が、ちゃんと仕切らないといけないんだけどね。
ただこれは、それを知らない奴にとってはムカつく奴でしかなく、そいつらを排除した結果、Gitは暴走中、というわけだ。
Linusがcommit履歴も大切に考える奴だったら違ってたが、惜しいね。 長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。 >>943
と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。
オブジェクトツリーはffの方がいい。
ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。
ソースと混ざるとウザイので、可能なら分離したい。
ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？
> Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea). >>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。
しかし世の中の一般人のGitの使い方は後者だろ。 >>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ >>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。
だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、
mergeするときには本ブランチでその結果がいきなり生えたように見せる機能
(捨てbranchとmergeしても中身の結果だけもらって親にはしない）
みたいな機能が必要なんだよ。
ただまあ、これは今でも手動だと出来た気はするが。
だからまあ、確かにパッチ管理ツールであって、
ソフトウェア開発時のバージョン管理ツールではないんだろうさ。
だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。
一つのパッチを作るまでにも何回もcommitが必要なのだから。 >>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。 >>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。 試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？
こういう話なので無視すんなよ？ｗ バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ >>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。
そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時にはあった方が便利なんだろうしさ。(ただのcommitには邪魔でしかない）
しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。
そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。
確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。 >>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。 >>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。 >>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？ >>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。 >>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと >>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ >>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？ >>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い
git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う
マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない >>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。
> マルチルートは普通に作ったリポジトリをfetchやpushで合成して
ああこれは俺の要求とは違うね。
まあ、もう地味に.git/.xxx/に転がそうと思案中。 >>963,964
お前らunixコマンドの使い方知らないだろ。
patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。
具体的な使い方は以下。
今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、
cp fileA fileB
diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、
diff fileA fileC | sed -n '10,20 p' | patch fileB
これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。
だからパッチの分割はすぐ出来るんだよ。 >>967
そういう作業を必要で無くすためにgitが生まれた
patchの提出をgitの分散リポジトリ上で可能とするためにね
963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事
そのpatchを整理するのに index や rebase がある もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。 >>968
知ってるよ。
ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。
なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。 >>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ >>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。
つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。
ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。 >>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。 >>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。 >>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。 >>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。 https://www.praha-inc.com/lab/posts/commit-message
そもそもコミットメッセージは何のためにあるのでしょうか？
コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。
もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつでも聞ける状況であるとは限りません。
「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。
加えて、コミットメッセージは基本的に他人が読むものです。
他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。
つまり、コミットメッセージは自分以外の人のために存在するのです。 まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す
ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない 「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって
バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ 前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン 相変わらずお前ら盛大に勘違いしてるが、とりあえず、
× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである
としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？
バグパッチに於いて、重要な物から順に、
1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ
だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、
○年○月○日に○○から送られてきた○○のバグ(メモリリーク)を修正する。
詳細はXXXX
で、XXXXのところ、Git流ならSHA1ハッシュで、
その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。
これで、「何故この変更を行ったのか」の完全情報が保たれる。
そして、再現コードは今後ずっとregressionテストに使う資産にする。
そうすれば、少なくとも過去と同じバグはリリース前に見つかる。 こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。
で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。
こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。
ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。 ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。
バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。
分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。 >>985
> commitメッセージなんてただのラベルに過ぎない。
その言葉からお前がわかってないのが明らかなんだけど？ regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？ バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ >>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、
1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、
commitメッセージにそのリンクは落とされている(落とされる予定）なのか？
そうじゃないと>>977が達成出来ないだろ。
2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？
3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで
だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、
gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。
gitで出来るのは上の1だけだね。
だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。
それでバグやパッチが減るわけでもないから。
目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。 >>994
と思ったがすまん、見落とした。
> 修正コミットのログ
つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？ >>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。 >>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。
俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。
が、まあ、これは多分為されるだろう。見守るよ。
> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。
それが何故そうなってるか理解出来ない、
つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、
言うこと聞く連中ならそうはならない。
通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、
そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、
問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。
マジかー、って、ちょっと驚きだが、まあ観戦だ。
ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。
だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。
というか単発のコードでそんなに技量の差なんて出ないし。 >>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
