22/08/14 15:10:31.19 hteYaGpv0.net
>>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ
466:デフォルトの名無しさん
22/08/14 15:48:56.36 eEFpmmgP0.net
>>453
たった数万行に驚いてるのか？
467:デフォルトの名無しさん
22/08/14 16:47:19.54 psUND9lqa.net
そもそも描いたこと無いからイキれるんだな
468:デフォルトの名無しさん (ﾜｯﾁｮｲ 31ab-5Ix7)
[ここ壊れてます] .net
一日100行でも一年経てば20000行
469:デフォルトの名無しさん
22/08/15 20:10:11.85 KNym4Y6d0.net
svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな
470:デフォルトの名無しさん
22/08/15 20:22:20.12 1icmhpVn0.net
リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。
リモートリポジトリ無しってgit登場時点で普通の話だったっけ？
471:デフォルトの名無しさん
22/08/15 21:27:50.09 dRxXQoxWM.net
リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ
472:デフォルトの名無しさん
22/08/15 22:34:37.88 vxI8O7UY0.net
>>458
SCCSとかRCSとか。
473:デフォルトの名無しさん
22/08/15 23:18:53.39 f21eh4iaM.net
Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿
474:デフォルトの名無しさん
22/08/16 01:17:15.07 yNxxslbt0.net
URLﾘﾝｸ(ezoeryou.github.io)
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
＞ しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞ レポジトリのローカルコピーがあることと、分散マージはでかかった。
475:デフォルトの名無しさん
22/08/16 23:52:04.96 zXGOFEoi0.net
>>448
gitに�
476:ﾀらんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ
477:デフォルトの名無しさん
22/08/18 11:54:41.84 p/limWqpa.net
gitとgithubの区別がついてないんだろ
478:デフォルトの名無しさん
22/08/25 00:47:44.66 x22ro4Sl0.net
初歩的な質問になるけれど…
異なるローカルブランチ「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をしたときのワークツリーの挙動が掴めない
479:デフォルトの名無しさん
22/08/25 02:38:58.44 W0zamWK80.net
「git checkout ブランチ」するとき、
checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる
つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う
ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する
480:デフォルトの名無しさん
22/08/25 02:40:02.58 W0zamWK80.net
$ 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.
481:デフォルトの名無しさん (ﾜｯﾁｮｲ 1f5f-SiT/)
[ここ壊れてます] .net
>>466-467
whoyou.txtが復活するのは勘違いしていたみたい すまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。
ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな
482:デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ)
[ここ壊れてます] .net
>>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる
git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示
483:デフォルトの名無しさん (ﾜｯﾁｮｲ 7f7c-tEjH)
[ここ壊れてます] .net
git status -v
とかじゃダメなのか？
484:デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ)
[ここ壊れてます] .net
git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る
485:デフォルトの名無しさん
22/08/26 18:45:49.38 8mS1vdmvM.net
たかだかpushするだけなのに、ターミナルからやった方がエモいですか？
486:デフォルトの名無しさん
22/08/26 19:07:22.83 m09WXDX9a.net
エモいと言う言葉の意味がわからない
487:デフォルトの名無しさん
22/08/26 19:30:50.57 WwYTVpIB0.net
>>472=>>407
488:デフォルトの名無しさん
22/08/27 07:34:04.59 cMY+Cqk70.net
エモいかどうかは知らんけど、
489:ターミナルの方が便利
490:デフォルトの名無しさん
22/08/30 12:28:50.29 CdxrcFTpM.net
興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww
491:デフォルトの名無しさん
22/08/30 23:04:23.35 F66FctjD0.net
まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？
492:デフォルトの名無しさん
22/08/31 08:44:21.38 hYROypry0.net
ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ
493:デフォルトの名無しさん
22/08/31 08:46:09.80 kba1lHfP0.net
Git v2.37.3
494:デフォルトの名無しさん
22/08/31 12:34:16.47 nUvaW37BM.net
>>478
最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw
495:デフォルトの名無しさん
22/08/31 15:08:11.70 83s/Qhp/a.net
タイムスタンプω
パソコン初心者かよωωω=2πf
496:デフォルトの名無しさん
22/08/31 15:34:18.76 t/W0dlco0.net
gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった
497:デフォルトの名無しさん
22/08/31 16:40:45.15 hYROypry0.net
あと、扱うファイル形式的にも難しそう
>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？
498:デフォルトの名無しさん
22/09/01 01:20:40.38 v92yFclD0.net
>>481
涙拭けよ
499:デフォルトの名無しさん (ﾜｯﾁｮｲ 5dc2-nKCz)
[ここ壊れてます] .net
タイムスタンプみたいな信用できないものに依存するなよ
500:デフォルトの名無しさん
22/09/03 12:08:05.86 gEPymsC80.net
URLﾘﾝｸ(github.com)
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？
501:デフォルトの名無しさん
22/09/03 12:50:36.25 91ZlUxrsa.net
git clone github.com:witwall/mman-win32
502:デフォルトの名無しさん
22/09/03 12:56:48.05 ZbfA6K7G0.net
>>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → URLﾘﾝｸ(github.com)
に読み替えてhttpsでやればいい
503:デフォルトの名無しさん
22/09/03 15:32:09.11 gEPymsC80.net
>>488
ありがとう
504:デフォルトの名無しさん
22/09/04 18:01:40.46 F3wqdiHv0.net
情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども
505:デフォルトの名無しさん
22/09/04 18:03:08.45 F3wqdiHv0.net
日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども
506:デフォルトの名無しさん
22/09/04 18:09:17.04 ZgLwpFsc0.net
いいよ
間違ったとこにpushすることを防げる
507:デフォルトの名無しさん (ﾜｯﾁｮｲ 7fdb-Cgcv)
[ここ壊れてます] .net
おとなしくGUI使えよ
タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ
508:デフォルトの名無しさん
22/09/05 01:29:30.11 +fm9JKxR0.net
>>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです
509:デフォルトの名無しさん
22/09/05 01:33:50.45 CQl5AJDr0.net
>>494
論破しましたね
510:デフォルトの名無しさん
22/09/05 12:14:03.67 s3GaDdDqM.net
論破ww
久々に聞いた、平成かよw
511:デフォルトの名無しさん
22/09/05 14:19:44.96 vU9z3P6x0.net
ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるの�
512:煢ﾟ去に完全論破されたのがよっぽど悔しかったんだろうな
513:デフォルトの名無しさん
22/09/05 16:50:12.49 dKgf+YLO0.net
ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？
514:デフォルトの名無しさん
22/09/05 18:08:18.48 pTpxX+Uo0.net
別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？
515:デフォルトの名無しさん
22/09/05 19:17:05.40 dKgf+YLO0.net
>>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた
516:デフォルトの名無しさん
22/09/05 20:13:32.62 CQl5AJDr0.net
気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる
517:デフォルトの名無しさん
22/09/05 23:32:13.90 vU9z3P6x0.net
気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する
518:デフォルトの名無しさん
22/09/10 14:36:31.13 4Ftb5IZI0.net
>>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok
519:デフォルトの名無しさん
22/09/10 17:37:58.38 EVlNSVx0M.net
.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
520:デフォルトの名無しさん
22/09/10 17:55:34.66 2MbFO6mH0.net
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？
そもそも、UTF-16LE-BOM を使う事ってある？
普通は、BOM 無しUTF-8 を使う
521:デフォルトの名無しさん
22/09/10 18:08:59.50 EVlNSVx0M.net
>>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります
522:デフォルトの名無しさん
22/09/10 18:17:08.28 kN9l3Zj10.net
>>505
使う理由があって使ってんのに難癖はやめとけ
523:デフォルトの名無しさん (ﾜｯﾁｮｲ a561-Z99o)
[ここ壊れてます] .net
>>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？
524:デフォルトの名無しさん
22/09/10 20:18:35.22 RL5Ydm0F0.net
素直に文字コード変換ソフト使ってからpushしたほうがイイんじゃね？
文字コードの問題は結構根深いとこあるし
525:デフォルトの名無しさん
22/09/10 20:23:42.76 1BX46xrY0.net
情報学部卒IT企業勤務1年目だけどGit難しいよ
よくみんな使いこなせるな
ブランチ切り替えとか発生した瞬間に混乱するわ
526:デフォルトの名無しさん
22/09/10 20:25:06.14 1BX46xrY0.net
とあるブランチで開発を進めていて、pushまで完了していつでもブランチ切り替えできる状態ではあるけど
新しくブランチ切ったからそこで作業してと言われた瞬間パニックになる ブランチ切り替えすると作業フォルダの中身変わるの緊張するわ
527:デフォルトの名無しさん
22/09/10 20:40:06.16 amn8zzJ5M.net
慣れないうちはコミットログやブランチ同士の関係をグラフ表示できるGitクライアントに頼ったほうがいいよ
ミスっても所詮は手元だけだから、適宜リモートにプッシュしてさえいれば操作は大胆にやればいい
ただしプッシュ前のチェックだけは入念に
528:デフォルトの名無しさん
22/09/10 21:23:42.21 EVlNSVx0M.net
>>508
リモートの.editorconfigと.gitattributesでUTF-16LE-BOMを指定してるので
.rcファイルもUTF-16LE-BOMで上がっているんじゃないのかな
cloneした.rcファイルはUTF-16LE-BOMになってます
>>510
よくわからないエラーで悩むよ
529:デフォルトの名無しさん
22/09/11 01:22:10.61 TANQ1xvy0.net
そもそもutf-16 leを推奨しているMicrosoftがおかしいからな(直す気もないらしい)
>>504
多分もう色々調べてると思うけど、もし見てなかったら参考に
URLﾘﾝｸ(developercommunity.visualstudio.com)
URLﾘﾝｸ(qiita.com)
530:デフォルトの名無しさん
22/09/11 06:37:15.30 ViMVDrAnM.net
>>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
531:デフォルトの名無しさん
22/09/11 08:17:11.62 p8irpA6n0.net
>>510
頭が良い悪いは関係なくて、単に慣れの問題だと思うよ
心配しなくても、そのうち慣れる
532:デフォルトの名無しさん
22/09/11 12:15:22.07 EZu34myO0.net
ある程度の難しさがあるのは確かだと思うので地図を読むことの得手不得手みたいな適性は何かしらあるかもしれない
533:デフォルトの名無しさん
22/09/11 12:17:08.26 EZu34myO0.net
けどブランチ切り替えくらいなら慣れだな
分散開発で計画やマージを任せられるとなると人によって難しい
534:デフォルトの名無しさん
22/09/15 14:34:12.65 cRBlrBBnF.net
githubの質問ってここで良いのかな？
フォーク基のリポジトリをPublicからPrivateに変更したら、Publicの時にフォークしたユーザーのリポジトリに影響って出る？
535:デフォルトの名無しさん
22/09/15 23:28:16.29 GwVm0Djk0.net
>>519
こっちでお願いします
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
ｽﾚﾘﾝｸ(tech板)
536:デフォルトの名無しさん
22/09/16 13:09:50.05 QQvhz5cq0.net
Git v2.38.0-rc0
537:デフォルトの名無しさん
22/09/23 16:47:47.90 UblpnXcK0.net
Git v2.38.0-rc1
538:デフォルトの名無しさん
22/09/27 03:57:55.82 x8Dmf6Id0.net
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'
こういう学習のためのテスト環境ってローカル同士じゃダメなんですか？
539:デフォルトの名無しさん
22/09/27 07:59:31.26 UwDioOcC0.net
bare repositoryになってないとかmaster,developへの直接push不可になってるとか
540:デフォルトの名無しさん
22/09/27 09:48:59.09 +d371Z/C0.net
【Git】bare リポジトリで無いならば、push を受け入れないことを知りました
URLﾘﾝｸ(oki2a24.com)
学習のためだけならreceive.denyCurrentBranchを設定してもいいかもね
541:デフォルトの名無しさん
22/09/27 10:14:08.47 c2KUidKp0.net
不可解な挙動で学習時間や意欲をロスしないためにも普通の構成にしたほうがいいと思う
俺ならserver(bare)とclient1とclient2を作る
542:デフォルトの名無しさん
22/09/27 11:33:58.99 vJTIC1iI0.net
そもそもどこからcloneして
543:きたのか不明だし、こういう質問する奴って情報が不足し過ぎてるような githubとかにあるようなのをcloneしてpushして失敗しましたとかなら草だがｗ
544:デフォルトの名無しさん (ﾜｯﾁｮｲ 7fe4-Nf8B)
[ここ壊れてます] .net
別にどこからcloneしてきたとか関係ないよ
デフォルト設定だとbareでないレポジトリへpushできないことがあるのは仕様
bareにするとかdenyCurrentBranchは危ないよとかググれば日本語の情報もいっぱいある
545:デフォルトの名無しさん
22/09/28 09:04:02.38 +1FeoF9d0.net
Git v2.38.0-rc2
546:デフォルトの名無しさん
22/09/28 11:25:13.07 bhRVKQK10.net
server側をベアで作り直したらうまくいきました
ありがとうございます
なぜ入門書はここら辺を説明してくれずに
まずGitHubのアカウントを作ります。とか言い出してしまうのか
547:デフォルトの名無しさん
22/09/28 11:44:27.73 MP/YhhuJ0.net
選び方が悪いね
そういう方向性の入門書ならプロジェクトリーダー濱野氏の入門Gitだ
5章「2か所で使う」でバックアップリポジトリをbareで作って云々を解説してる
githubには一切触れていない(と思う)
git clone /pub/repositories/～ みたいなローカルマシン内でのcloneを解説してる本は他にあるのかな
548:デフォルトの名無しさん
22/10/01 10:02:20.72 DVLayUHe0.net
Gitをインストールした記憶がないのに、なぜかインストール済みでした。
Git Bashを起動すると、プロンプトが変だし、フォントが小さいし、色付けもされません。
プロンプトは「~>」です。
これはどういうことでしょうか？
549:デフォルトの名無しさん
22/10/01 14:10:19.42 J9f91GHl0.net
それウィルスに感染してる
550:デフォルトの名無しさん
22/10/02 17:48:34.37 6kxI91N30.net
コミットメッセージについてです
テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が
あるみたいですが、基本的にはどっちを使うべきなんでしょうか？
551:デフォルトの名無しさん
22/10/02 18:05:40.19 dk1cJbbAM.net
仕事や既存OSSならチームのルールがあるだろうから先輩に聞け
個人ならどっちでも自分が楽な方でいい
ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、
そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない
552:534
22/10/02 18:30:26.77 6kxI91N30.net
>>535
分かりました ありがとうございます
取り敢えずVSCodeを使っておこうと思います
553:デフォルトの名無しさん
22/10/02 18:55:33.63 q9OgIqJtM.net
Vimを使って書くのが正しいやり方です
554:534
22/10/02 19:05:01.56 6kxI91N30.net
>>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました
555:デフォルトの名無しさん
22/10/02 19:10:39.82 uPDZdRB50.net
コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。
自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。
コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。
556:デフォルトの名無しさん
22/10/02 19:16:22.79 D5S18uSu0.net
長文したためなくてもバグトラッカーのID書いてあればいいよ
繰り返しになるけどプロジェクト次第
557:デフォルトの名無しさん
22/10/02 19:28:14.51 Sn8H/WH4M.net
>>539
まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄
コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ
558:デフォルトの名無しさん
22/10/02 20:42:06.76 t7yq2oGI0.net
URLﾘﾝｸ(git-scm.com)
> 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:
...
559:デフォルトの名無しさん
22/10/02 21:53:11.93 QRo7yeZh0.net
>>539
コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが
560:デフォルトの名無しさん
22/10/02 21:57:22.79 QRo7yeZh0.net
>>541
ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね
561:デフォルトの名無しさん
22/10/02 22:11:44.82 uPDZdRB50.net
>>543
vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。
562:デフォルトの名無しさん
22/10/02 22:30:04.49 w76y/xOG0.net
コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね
ログもGUIの方が見やすいし、diffもそうだしね
563:デフォルトの名無しさん
22/10/02 23:56:46.78 Yp4OiWZtd.net
今時Tortoiseはないでしょ
GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、
SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい
普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな
564:デフォルトの名無しさん
22/10/03 01:53:25.03 VqHymwUT0.net
Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの
565:デフォルトの名無しさん
22/10/03 11:24:33.95 KjjssmK/0.net
以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？
566:デフォルトの名無しさん
22/10/03 11:33:15.47 9fynhyqE0.net
gitに関係ないのでこっちで質問してください
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
ｽﾚﾘﾝｸ(tech板)
567:549
22/10/03 16:52:54.84 KjjssmK/0.net
>>550
分かりました
失礼しました
568:デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-pIDl)
[ここ壊れてます] .net
>>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ
569:デフォルトの名無しさん (ﾜｯﾁｮｲ d39f-xADz)
[ここ壊れてます] .net
クラーケンでいいっすよ
570:デフォルトの名無しさん
22/10/03 23:39:02.11 HIJT7OgS0.net
>>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。
571:デフォルトの名無しさん (ﾜｯﾁｮｲ 53c8-H9hz)
[ここ壊れてます] .net
あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。
572:デフォルトの名無しさん
22/10/04 08:23:42.03 uzf3Ju8H0.net
Git v2.38.0
573:デフォルトの名無しさん
22/10/04 11:25:30.61 00cm+2sC0.net
TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット
574:デフォルトの名無しさん
22/10/04 13:18:54.26 8FecEEXR0.net
TortoiseGitはシェルエクステンションの時点でインスコする気失せる
575:デフォルトの名無しさん
22/10/04 15:00:17.58 iRJJVrVe0.net
git
576:使うなら開発者が愛用してるEmacsのmagitを使おうぜ
577:デフォルトの名無しさん
22/10/05 08:43:21.48 sfonbe+Ea.net
GUIクライアントならForkおすすめ
578:デフォルトの名無しさん
22/10/05 22:35:11.78 UUeH3vvk0.net
そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。
579:デフォルトの名無しさん
22/10/06 18:25:19.94 q29RvDaDM.net
fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。
580:デフォルトの名無しさん
22/10/06 18:28:48.47 N59THtE80.net
女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。
581:デフォルトの名無しさん
22/10/06 18:57:50.90 tI414gt60.net
使い方が分からないという話？
それともソース管理がイマイチ分からない話？
582:デフォルトの名無しさん
22/10/06 19:20:02.27 zjAiMCMB0.net
なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。
583:デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO)
[ここ壊れてます] .net
>>565
知らんがな。
Git採用を決定したヤツに言えよ。
584:デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl)
[ここ壊れてます] .net
決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません
585:デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)
[ここ壊れてます] .net
>>565
お前はいつ、誰が、何のために変更したか全部覚えておけるの？
どの変更とどの変更が一緒の組でどれが独立した修正か、差分見ただけですぐに区別できる？
多数の変更案の中から必要なものだけをすぐに組み合わせられる？
開発人数が多くなっても同じことができる？
1万回修正したとして、その差分を全部コピーで持っておくの？
その無数のコピーの中から必要なコピーを見つけるのはどうやってやるの？
586:デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO)
[ここ壊れてます] .net
>>567
この「うちの学生」とは、あなたの想像上の存在に過ぎないのではないでしょうか。
587:デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl)
[ここ壊れてます] .net
>>569
実際に教えていますが何か？
URLﾘﾝｸ(richlab.org)
そんな中，まさにその疑問や悩みに応えるような内容の講義
「シェルスクリプト言語論」を金沢地区の大学向けに、2016年から
開講してきました．ここまで4回（4年）開講し，内容が洗練されてきたところでついに書籍化しました．
588:デフォルトの名無しさん
22/10/06 20:19:02.29 tI414gt60.net
バイナリでも別に過去の履歴は取って来れるような
ただリポジトリは肥大化するしバイナリの管理の為に作られたものでは無いから
相性が良い訳では無いのは分かるのだが
プログラム開発の世界でバイナリと言えば大抵はエクセルなどのオフィス系のファイルだが
正直これらをgitでバージョン管理する必要は無い気はしなくもないｗ
（でも大抵の会社はバイナリだろうがgitで管理しているが）
589:デフォルトの名無しさん
22/10/06 20:45:30.79 zjAiMCMB0.net
>>571
なにか勘違いしているようだな
gitはテキストデータでも保存するときに
バイナリ形式を使っているから将来データが取り出せなくなると言っておるのだ
その�
590:謔､なものは使わん
591:デフォルトの名無しさん
22/10/06 20:46:16.55 tI414gt60.net
ん？将来？別に好きな履歴を取り出せるが？
何の話だ？
592:デフォルトの名無しさん
22/10/06 21:08:34.12 vH9MiC1U0.net
gitの使い方を知らないただの老害だった…
593:デフォルトの名無しさん
22/10/06 21:49:48.89 p6k/LOp80.net
>>565 おじいちゃん去年のスレッド忘れてまた来ちゃったの？
さぁ↓こっちに帰りましょうね。
ｽﾚﾘﾝｸ(tech板)
594:デフォルトの名無しさん
22/10/06 21:50:57.66 J7yBN2sy0.net
いつもの粘着荒しじゃないの
途中で句読点のスタイルが変わってるし半分コピペの創作だろ
あの手この手で相手してほしいんじゃね
595:デフォルトの名無しさん
22/10/06 22:22:36.07 DBe4OZi40.net
バイナリ形式だから将来取り出せないって、何を心配してるんだろう？ 文明崩壊後でコンピューターが使えなくなった時？ 岩に刻んでおく？
596:デフォルトの名無しさん
22/10/06 22:38:26.50 PvD2K1c/r.net
間抜けなPOSIX原理主義者がまた論破されて敗走したのか
597:デフォルトの名無しさん
22/10/06 23:17:53.55 jAkUbGv20.net
>>563
俺もその本読んだけど、何となくGitの存在意義分かったよ
例えば会議の備忘録がこんな感じで複数あるとしたら？
・備忘録_1.txt
・備忘録_2.txt
・備忘録_1改.txt
・備忘録_最新.txt
・備忘録_3.txt
どれが最も新しいかピンとこない、どの順に更新されたのかピンとこない、
誰がどのファイルにどんな更新を加えたの分からない
そんな問題を解決してくれるのがGitのようなバージョン管理ツール(って書いてある)
598:デフォルトの名無しさん
22/10/06 23:50:19.63 orz8mNRt0.net
Gitむずかしいな
みんなよく使えるな
599:デフォルトの名無しさん
22/10/07 04:44:37.69 TBR3DhbF0.net
>>563
YouTube で「git 使い方」「git 入門 」などで検索！
山浦清透・せお丸・くろかわこうへい・しまぶーなど、色々ある
600:デフォルトの名無しさん
22/10/07 09:55:21.21 E++rKArz0.net
>>577
UNIX哲学ではバイナリ形式は禁止されている
愚か者め
601:デフォルトの名無しさん
22/10/07 10:07:54.49 GHAO4XK10.net
>>582
だから、そのバイナリーって何よ？
602:デフォルトの名無しさん
22/10/07 10:12:43.41 E++rKArz0.net
>>583
話のわからんやつだな。この本を買え。全部書いとるわ。
URLﾘﾝｸ(techbookfest.org)
我らが一番問題だと思っているのは、リポジトリーの中身の多くが訳のわからぬバイナリーデータになって
いることだ。そのバージョン管理ソフトウェアが滅んだら復元は絶望的だ。テキストデータ形式ならば眺めれ
ば方策も見えてくるのでまだ何とかなりそうな気がするというのに。「データはテキスト形式で保存せよ」とは
UNIX 哲学でも言われてきたことだ。一体何を考えているのか。
603:デフォルトの名無しさん
22/10/07 10:13:25.77 E++rKArz0.net
移り行くトレンド
古参のプログラマーなら、これまでどんなバージョン管理ソフトウェアが台頭してきたか振り返ってみよ。す
ぐ思いつくものだけでも、RCS、CVS、SVN、そしてGit。これらは同時期に存在して覇権を争っていたのでは
ない。それぞれが時代を担ってきたといっても過言ではない。時代によって使うものが替わり、新しいバージョ
ン管理ソフトウェアが
604:流行り出せば、その使い方を覚え直し、時にはリポジトリーの移行を強いられてきたこと だろう。よくまぁ、懲りもせずにといったところだが、我らはもうたくさんだ。もしかすると、諸君は「Git を 覚えれば安泰だ」などと思っているかも知れんが、あと数年、遅くとも5 年も経てばきっと次のバージョン管理 ソフトウェアが登場し、覚え直しとリポジトリーの移行を余儀なくされることだろう。
605:デフォルトの名無しさん
22/10/07 10:13:49.81 E++rKArz0.net
目的を見失っったバージョン管理ソフト
バージョン管理ソフトウェアのそもそもの目的は何だったのか。開発を続け、バージョンアップしていくソフ
トウェアの維持管理に要するコストの抑制であったはずだ。これは、POSIX 原理主義を崇拝する我らがソフト
ウェアを5 年、10 年と生き長らえさせようとする、その根底に流れる目的そのものである。
ソフトウェアはバージョンアップする。新しいコードを加え、古いコードは切り捨て、時には依存するライブ
ラリーを付け替えもする。その変わる様をすべて見届けることがバージョン管理ソフトウェアの役割であり、そ
れができて初めてまともに維持管理コストの抑制が実現する。ゆえに、
バージョン管理ソフトウェアは、ライブラリーの類よりも遥かに長く生き長らえなければ意味がない。
ところが実際はそうなっていない。「バージョン管理ソフトウェアの維持管理」を強いられる。本末転倒もい
いところ。お前は何を言っているんだ。
606:デフォルトの名無しさん
22/10/07 10:26:43.54 8xhEA9gJ0.net
覚え直しと移行すりゃいいじゃん
その時期がくれば便利な移行ツール（git svnコマンドのような）が出回るし、簡単なことだよ
そんなちっぽけなことを恐れて、完全無欠の理想通りじゃないからと今のベターな現実解を忌避するのはあれだ
こだわりが強すぎて社会生活に支障が出るタイプの典型的症例
607:デフォルトの名無しさん
22/10/07 10:31:38.34 E++rKArz0.net
>>587
何度も何度も覚え直しでお前は成長してると言えるのか
シェルスクリプトだけでなんでもできる
608:デフォルトの名無しさん
22/10/07 10:33:30.22 E++rKArz0.net
>>587
中身がわけのわからんバイナリデータなのだから壊滅的だ
データは取り出せなくなり移行なんかできん
バージョン管理ソフトウェアが滅んだら復元は絶望的だ
609:デフォルトの名無しさん
22/10/07 11:43:19.78 GHAO4XK10.net
中身がわからんのはお前が無能だからだろ。ソースも公開されてるし、中身の形式も公開されてるので読んどけ。プロプラな機密ソフトの基準で語ってんじゃねーよ。
中身が完全にわかっているという意味ではテキストと同等かフォーマットが決まってる分それ以上に効率が良い。
610:デフォルトの名無しさん
22/10/07 12:18:40.03 6in1nvJWM.net
>>582
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている
611:デフォルトの名無しさん
22/10/07 12:20:40.01 d4ub3t4La.net
テキストで保存した結果
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
↓
繝励Ο繧ｰ繝ｳ繝溘Φ繧ｰ縺｣縺ｦ菴包ｼ
612:デフォルトの名無しさん
22/10/07 13:30:31.61 8xhEA9gJ0.net
>>588
成長？
最適なツールを選ぶときに成長とか関係ある？
淡々と使うだけだろ
何度も何度もっていったい何百年生きるつもりなんだ
613:デフォルトの名無しさん
22/10/07 13:58:18.44 +OS+xNc10.net
USP研究所のシェルスクリプトマガジンを購読しているけど、
こんな人がライターなのか？
いささかガッカリした。
614:デフォルトの名無しさん
22/10/07 14:06:48.59 h1ATf2/y0.net
バイナリに見えるのはgzip圧縮されてるだけでgitconfigに
compression=
615:0 loosecompression=0 を書いておくと無圧縮のテキストになったような
616:デフォルトの名無しさん
22/10/07 14:37:14.17 E++rKArz0.net
>>593
せっかく覚えたのにバージョン管理ツールが変わって知識が役に立たなくなると言っておるのだ
シェルスクリプトなら20年後も今の知識が通用する
URLﾘﾝｸ(www.slideshare.net)
617:デフォルトの名無しさん
22/10/07 14:39:12.40 q9dWCqSf0.net
頭おかしい奴が沸いているｗ
618:デフォルトの名無しさん
22/10/07 15:14:19.27 h1ATf2/y0.net
ちなみにgitのリポジトリは、ブランチ、コミット履歴、データ(ファイル)の3種類を
それぞれsha1ハッシュで繋いでいるだけのシンプルな構造
リポジトリをバラしてファイルを取り出すだけのプログラムなら大体の人は1日もあれば作れるよ
619:デフォルトの名無しさん
22/10/07 15:32:28.30 GHAO4XK10.net
>>598
さすがに1日もかからんやろ。スクリプト言語使って15分とかそんな感じでは。
620:デフォルトの名無しさん
22/10/07 16:01:35.71 IRNCV7aTr.net
>>596
そんなに苦痛なんだ。
大変だね。
621:デフォルトの名無しさん
22/10/07 16:13:03.09 h1ATf2/y0.net
む
〇zlib圧縮
×gzip圧縮
622:デフォルトの名無しさん
22/10/07 17:08:55.91 E++rKArz0.net
>>598
ならばそのsha1ハッシュをPOSIXの範囲で作ってみよ
POSIX準拠で仕様が許されてるハッシュ化コマンドはcksumのみだ
我らはbase64コマンドをawkで作ってみせた
623:デフォルトの名無しさん
22/10/07 17:09:18.38 E++rKArz0.net
POSIX準拠で使用が許されてる
624:デフォルトの名無しさん
22/10/07 17:35:13.58 GHAO4XK10.net
>>602
アホはスクリプト言語で書いた。
普通の人は速度出したいのでそういう用途にはCコンパイラ使う。POSIXにC言語の規定がないとでも思ってるんだろうな。
625:デフォルトの名無しさん
22/10/07 18:19:16.51 E++rKArz0.net
>>604
アホはお前だ。POSIXにC言語の規定があることぐらい知っておるわ。
C言語はハードウェア依存する。そのような効率よりも移植性のほうが重要だ。
URLﾘﾝｸ(www.ipsj.or.jp)
POSIXに準拠したプログラムを作成することにすると，開発言語はシェルスクリプト
またはC言語（C99）に限定される．その理由は，POSIXで用意されている
プログラミング言語としてのコマンド（以下，POSIXコマンドと記す）に
PerlやRuby，Javaといった現在よく利用される高級言語は存在せず，
存在するものはBourneシェル（sh コマンド）とCコンパイラ（c99コマンド）だけだからである．
どちらを選択してもPOSIXに準拠したプログラミングができることにはなるが，
基本的にはシェルスクリプトを利用する．C言語はバイトオーダ等のハードウェア構造を
意識しなければならない．一方，シェルスクリプトであれば，そのようなハードウェア依存は
POSIXコマンドが吸収しているため，意識せずにプログラミングできることが理由である．
したがって，POSIX中心主義では，POSIXの仕様に準拠したシェルスクリプトを
中心としたプログラミングをする．シェルスクリプトを選択することには，以下に述べる3つの利点がある．
626:デフォルトの名無しさん
22/10/07 18:20:33.07 E++rKArz0.net
>>604
シェルスクリプトが遅いなどというのも間違いだ。
それはストリーミング型の書き方を知らない愚か者の戯言だ
3.1.1 開発効率と処理効率の両立
シェルスクリプトはC言語と比べて処理の遅さを指摘されるが，それは必ずしも正しい認識ではない．
シェルスクリプトはインタプリタ型言語であるため，ステップ数が多いほど処理効率は悪化する．
また各ステップに外部コマンドを起動する記述があればそれも大きな処理効率悪化につながる．
しかし，手続き型の書き方からストリーミング型の書き方に改めるように工夫すれば，
ステップ数の増加を抑えられ，処理効率は大きく改善する．
627:デフォルトの名無しさん
22/10/07 18:27:03.31 GHAO4XK10.net
>>606
�
628:ｶゃあ、お前がシェルスクリプトで git 書けばいいんじゃね？ 俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。
629:デフォルトの名無しさん
22/10/07 18:36:41.70 E++rKArz0.net
>>607
我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる
gitを書く必要などない
知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め
URLﾘﾝｸ(richlab.org)
630:デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)
[ここ壊れてます] .net
>>608
ゴミを勧めんな。オライリーに訴えられてろ。
631:デフォルトの名無しさん
22/10/07 20:35:52.31 E++rKArz0.net
>>609
ゴミならば大学の教科書になっておらぬわ
632:デフォルトの名無しさん
22/10/07 23:21:13.94 YKezo8WP0.net
forkで2つのコミットの差分どうやって見るの？
履歴から2つ選択しても出ない。コンテキストメニューも。未実装？
633:デフォルトの名無しさん
22/10/08 00:36:23.18 5sXOif570.net
以前作ったリポジトリの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して古いリポジトリは退避、以後は新しいのを使うことも考えてますがどうでしょうか
634:デフォルトの名無しさん
22/10/08 05:07:17.54 qNYwj5bN0.net
>>610
大学には頭おかしいのがおらんとでも？
大学全体の何割が使ってるか言ってみ。
635:デフォルトの名無しさん
22/10/08 07:49:17.82 fwLI4Y/XM.net
どうせ安全じゃないだろw
>fatal: detected dubious ownership in repository at
こんなものつけるなよカス
636:デフォルトの名無しさん
22/10/08 09:15:42.49 vxPAcYo70.net
>>613
大学だけじゃないぞ
プログラマならシェルスクリプトマガジンぐらい知っておろう
そこに長期連載されているほど、普及しておる
頭がおかしいなら、こんなに長く連載されるはずがないな
637:デフォルトの名無しさん
22/10/08 13:26:00.09 HbWzH6SVM.net
>>615
シェルスクリプトなぁ……簡単な作業の自動化用途だな。
なんでgitスレでこんな話題が？
NG指定したほうがいい？
638:デフォルトの名無しさん
22/10/08 14:00:29.88 x9F/jCO70.net
>>612set-headサブコマンドが使えるみたい
639:デフォルトの名無しさん
22/10/08 14:11:03.99 vxPAcYo70.net
>>616
愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。
この間はUNIX哲学に基づいてリアルタイムカーネルなしに
シェルスクリプトだけでリアルタイム処理を実現してみせたわ
URLﾘﾝｸ(www.sea.jp)
640:デフォルトの名無しさん
22/10/08 14:23:26.42 vxPAcYo70.net
>>616
gitのような目的を見失ったバージョン管理ソフトを使っているからだ
バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが
リポジトリでわけのわからんバイナリ形式を使っておるから
バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。
「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。
641:デフォルトの名無しさん
22/10/08 14:47:58.03 TKlSmRLn0.net
容れ物が古くなったら新しい容れ物に中身を移すだけ。
642:デフォルトの名無しさん
22/10/08 14:51:46.02 vxPAcYo70.net
>>620
よくもまあ懲りもせずにといったところだな
そうやって古くなったソフトを捨て新しいものに入れ替え
せっかく覚えた知識は無駄になり移行作業で苦しむ
POSIX原理主義なら一度覚えた知識は一生使うことが出来る
新しいことを覚える必要はない
643:デフォルトの名無しさん (ﾜｯﾁｮｲ deb0-zauZ)
[ここ壊れてます] .net
啓蒙したいんだろうけど
>新しいことを覚える必要はない
これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。
644:デフォルトの名無しさん
22/10/08 15:30:37.98 5sXOif570.net
>>617
git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、
HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか
645:デフォルトの名無しさん
22/10/08 17:26:15.60 qNYwj5bN0.net
>>621
いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。
646:デフォルトの名無しさん
22/10/08 17:39:03.44 88/OpuEG0.net
啓蒙したいんじゃなくて単に荒らしたいだけだから
だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん
647:デフォルトの名無しさん
22/10/10 11:28:58.21 JuIf0a+H0.net
シェルスクリプトのヤツは釣りだろ？
マジでいってんだったら頭おかしいだろw
(基地外を釣るエサ投下)
648:デフォルトの名無しさん
22/10/10 17:13:47.79 +gDGPUis0.net
URLﾘﾝｸ(megalodon.jp)
私の場合は「POSIX原理主義者」という名の人格者として名を知られるようになってきたが、「原理主義」を名乗るだけあって、
649:デフォルトの名無しさん
22/10/10 17:25:23.67 PTVZRYxu0.net
>>627
いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。
650:デフォルトの名無しさん
22/10/10 17:30:56.62 +gDGPUis0.net
>>628
勘違いしてるぞ。俺は人格者（笑）って書き込んだだけだぞ
651:デフォルトの名無しさん
22/10/16 04:54:37.57 kNlIrq3k0.net
Shelling at Russian power plant leaves Belgorod without electricity
URLﾘﾝｸ(www.youtube.com)
652:デフォルトの名無しさん
22/10/16 04:55:55.59 kNlIrq3k0.net
間違えた、すまん
653:デフォルトの名無しさん
22/10/19 13:19:13.07 1sfAoeRGa.net
Git v2.38.1
654:デフォルトの名無しさん
22/10/27 07:22:57.17 TnOoNEjS0.net
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しないでやってるとしか思えないが、何かそうなる理由ある？
あと、オプション等で回避する方法があれば教えて。
655:デフォルトの名無しさん
22/10/28 00:23:09.45 yz6FOYrM0.net
LooseCompressionの全展開用の領域 2MB*2800=5.6GB
git logは内部でlessにパイプでデータを渡してるから
パイプバッファも含めて約2倍だろうか
Packしなけりゃ少しはマシかもしれない(未確認)
656:デフォルトの名無しさん
22/10/28 07:15:31.79 HlXde3ci0.net
>Pack
git gcのことか？
なら実は当初はしてなくて1.2GBあったが、その時からコケてた。少なくとも2GBは食ってる。
その後gc出来ると知り、やってみたが、実際は自動で何回かやってるようだし、多分大勢は変わりない。
(実は全部新たにコミットし直すのも試してる)
なお愚直にgit show -> 切り出し -> diff を繰り返すだけのスクリプトを作って試してみた。
メモリは普段の使用と変わりなかった。
ただ問題は時間で、12分程度かかる。これでは気軽には使えない。
MINGW64だと2分程度で済む。
時間がかかるのは一々ファイルにしてるから？だから、
/dev/fd/3等で全部でパイプに出来れば短縮出来るかも？、というところ。
(システムキャッシュに完全に載るサイズだから関係ないかも？だし、
そもそも2回ずつ使うのでパイプにフィットしないが)
ただ現在でも初期画面は数分で出るし、出なければ大昔のコミットなのでどうせ問題なく、
実際の運用としては及第点ではある。でも速ければ速いに越した事はない。
Gitはおそらく速度重視なのだろう。
自動増加スワップのMINGW64環境なら現実的には大した問題にはならない。
ただ、全部メモリ上に展開する意味もメリットもないはずなので、
途中で一回もfreeしてないであろうこのコードは、コードとしては大問題だとは思うよ。
(ジョークで言われてる、Javaしか知らない奴が書いた、freeが一つもないコード、になってる)
657:デフォルトの名無しさん
22/10/28 07:18:13.37 RikIMzkC0.net
報告してあげるといい事案だと感じる
658:デフォルトの名無しさん
22/10/29 06:39:27.49 J4pkDf7Q0.net
パイプへの変更は厳しいので、一時ファイルを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超掴みに行くのは使用勝手が悪い。そもそも最初の方の履歴なんてほぼ要らんし。
659:デフォルトの名無しさん
22/10/29 08:37:46.51 e5vmfD+T0.net
>>637
HEAD~100 とかじゃ駄目なの？
660:デフォルトの名無しさん
22/10/29 08:44:53.54 +5EirK6r0.net
いやバグレポートすればいいと思う
661:デフォルトの名無しさん
22/10/29 09:15:13.77 J4pkDf7Q0.net
>>638
実はそこは初心者過ぎてよく知らないんだわ。
git log HEAD~100
では制限出来なかったけど、どう書くべきなの？
とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。
これが効かないのは、多分実装忘れじゃないかと。
> URLﾘﾝｸ(www.git-scm.com)
>>639
多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。
662:デフォルトの名無しさん
22/10/29 09:25:26.30 +5EirK6r0.net
合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい
そういうもん
レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる
仕様なのでは！？と空気読んで黙ってるのは奥ゆかしいニンジャ精神
663:デフォルトの名無しさん
22/10/29 09:38:02.85 J4pkDf7Q0.net
>>641
なるほどその通りだ。
ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。
> URLﾘﾝｸ(www.chiark.greenend.org.uk)
> URLﾘﾝｸ(www.git-scm.com) 内の this guide が上記
664:デフォルトの名無しさん
22/10/29 11:09:21.06 +W9Ulup+0.net
>>640
手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので？
665:デフォルトの名無しさん
22/10/29 15:16:52.52 e5vmfD+T0.net
>>640
HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない？
666:デフォルトの名無しさん
22/10/29 21:10:22.54 YQqcaKMe0.net
git log -100 じゃなくて？
667:デフォルトの名無しさん
22/10/29 23:05:25.26 e5vmfD+T0.net
>>645
-100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する
A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる）
668:デフォルトの名無しさん
22/10/30 02:06:46.88 IOU525bY0.net
>>644
効いた！ありがとう。
何ぞそれ？と思いきや git log のdocumentの頭に書いてあるのな。
> URLﾘﾝｸ(www.git-scm.com)
gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。
やはり最初は一通り読まないと駄目だな。
これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。
これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。
再現用のスクリプトも同梱してるから気になる人はどうぞ。
URLﾘﾝｸ(lore.kernel.org)
669:デフォルトの名無しさん
22/10/30 09:36:57.12 b5HYhcbp0.net
>>647
おつかれ。
慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。
670:デフォルトの名無しさん
22/10/30 12:37:33.31 IOU525bY0.net
>>648
初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。
なるほどタグを付けてgit logでは範囲指定がデフォか…
ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz
> URLﾘﾝｸ(www.git-scm.com)
つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。
671:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/30 18:58:14.60 IOU525bY0.net
git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ？
> URLﾘﾝｸ(www.git-scm.com)
既にフォーマッタを持っているので、
unixコマンドのdiffのデフォルト出力と同じ物が
672:欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様？ -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。
673:デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj)
22/10/30 21:37:56.23 b5HYhcbp0.net
>>650
git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。
674:デフォルトの名無しさん
22/10/30 22:10:12.22 IOU525bY0.net
>>651
マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。
スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、
これでいいと思った奴は死ねだな。
675:デフォルトの名無しさん
22/10/30 22:14:38.98 b5HYhcbp0.net
>>652
git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。
676:デフォルトの名無しさん
22/10/30 22:34:52.61 IOU525bY0.net
>>653
いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。
diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。
GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。
だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。
diffを内包する事に、何のメリットもない。
この名残がexternal driverで、それが使えればいいという事なのだろうけど、
ご丁寧にこれを禁止するオプションまである。(-no-ext-diff)
多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、
禁止するのは違う。どこかでおかしな思想が混入しているよ。
そもそも、それ以外を考慮しない＝外部コマンドで十分出来る事はdllを呼ぶ、であって、
この構成だとGitがdiffも構成してるから、君は認識を間違ってる。
Gitは明らかにおかしい方向で無駄な事をやってしまっている。
そしてそれは君の価値観的にもNGなはずだよ。
677:デフォルトの名無しさん
22/10/30 23:37:53.37 b5HYhcbp0.net
>>654
Linus のこと知ってるのなら長文書く前に調べろ。
git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。
で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。
678:デフォルトの名無しさん
22/10/30 23:53:15.06 LXgcbV870.net
Linusも言ってたような気がするけど、気に食わなければ自分で作れ
以上
679:デフォルトの名無しさん
22/10/30 23:58:47.31 IOU525bY0.net
>>655
Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。
これは間違ってない。
問題は、元のdiffの形式の出力が出来なくなってる事だよ。
オプションで出来るよ、でよかっただけ。
オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。
何故君がそんな意味不明なポジショントークをするのか分からないが、
Gitが方針を間違ってるのは事実だよ。
オプション禁止なら、git diff にオプションを何一つ付けてはいけない。
(仮にこれであれば、賛同はしないが理解はする）
ただまあ、ドキュメントの雰囲気だと、
おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。
君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。
680:デフォルトの名無しさん
22/10/31 00:04:41.05 h5Hfu9WR0.net
>>657
お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。
オープンソースなんだからオプション必要ならお前が自分でつくればいい。
681:デフォルトの名無しさん
22/10/31 00:08:19.51 h5Hfu9WR0.net
あと －－no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。
それこそ git で調べればすぐだぞ
682:デフォルトの名無しさん
22/10/31 00:21:01.40 J+3pjzxx0.net
>>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。
というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。
683:デフォルトの名無しさん
22/10/31 00:43:54.22 h5Hfu9WR0.net
>>660
不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。
684:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 07:08:10.92 J+3pjzxx0.net
色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> URLﾘﾝｸ(qastack.jp)
ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。
俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！
とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
685:デフォルトの名無しさん
22/10/31 10:11:41.92 J+3pjzxx0.net
てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。
つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。
686:デフォルトの名無しさん
22/10/31 10:39:47.64 sko8U7ef0.net
>>663 好きに fork しなよ。
687:デフォルトの名無しさん
22/10/31 12:23:13.35 h5Hfu9WR0.net
自分でやってみればいいよ。
自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。
仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。
688:デフォルトの名無しさん
22/10/31 13:21:07.66 J+3pjzxx0.net
>>665
それが従来形式のdiffの出力をさせない理由なら、
現在のGitプロジェクトの思想は俺とまるで合わない。
今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。
multicsの再来だね。(俺は使ったこと無いけど)
自覚症状もあるみたいだし。
> Git is a fast, scalabl
689:e, 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とかを絶対に交換させない為？ならマジで死ねでしかないね。
690:デフォルトの名無しさん
22/10/31 14:15:23.19 Yrczlr02M.net
Simple is not easy
Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ
691:デフォルトの名無しさん
22/10/31 14:29:14.51 Pk1WyFqz0.net
(だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう)
692:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 15:04:18.65 J+3pjzxx0.net
>>667
他よりましなだけだろ。
ただ俺が思うに、Gitはもっと簡単に出来て、
・勉強しないといけないGit(今)
・勉強しなくてもなんとなく使えちゃうGit(次世代)
に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。
実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、
(勿論見た目だけだがそれが重要)
俺はそれ作って使おうかとも思案中。
Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。
コマンド名変えるだけでも相当変わる。
693:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 15:05:02.85 J+3pjzxx0.net
>>668
それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。
今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。
3時間程度あれば、再現コード付きのバグ報告が出来てしまう。
それをマニュアルを読むのに費やしてるのだから、無駄でしょ。
世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。
694:デフォルトの名無しさん
22/10/31 15:39:10.00 oV1LtMOH0.net
それは世界中の人が俺に1円を恵んでくれたら
俺は大金持ちになっていたと言っているようなもんだな
695:デフォルトの名無しさん
22/10/31 15:57:50.61 h5Hfu9WR0.net
>>670
もっと良い物ができると主張するんなら作って広めてから出直してこい
もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ
linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ
そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる
お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」
696:デフォルトの名無しさん
22/10/31 16:18:24.02 SCCWpcRv0.net
gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね
697:デフォルトの名無しさん
22/10/31 16:37:40.55 GzQExg5g0.net
gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ
なので専用のものを内製する意味はある
698:デフォルトの名無しさん
22/10/31 18:09:11.73 J+3pjzxx0.net
>>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ
699:デフォルトの名無しさん
22/10/31 18:20:34.93 5K9TC9u30.net
初歩的な質問ですが教えてください。
コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか？
具体的には、
gitでdevelopからブランチを切ったAで作業しました。
ブランチAのコミット履歴が汚くなったので
新たに作成するブランチBにブランチAで変更したファイルを
一回のコミットで整理したいです。
git cherry-pick -n fromID..toID
などで整理しているのでしょうか？
700:デフォルトの名無しさん
22/10/31 18:28:03.00 oV1LtMOH0.net
>>675
タラレバ
701:デフォルトの名無しさん
22/10/31 18:33:43.29 J+3pjzxx0.net
>>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、
> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> URLﾘﾝｸ(cpplover.blogspot.com)
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。
ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。
まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。
702:デフォルトの名無しさん
22/10/31 18:41:18.26 oV1LtMOH0.net
小１「掛け算よりも足し算のほうが簡単だ！」
703:デフォルトの名無しさん
22/10/31 18:42:37.79 oV1LtMOH0.net
しょう１「かけざんよりもたしざんのほうがかんたんだ！かんじよりもひらがなのほうがかんたんだ！」
704:デフォルトの名無しさん
22/10/31 18:50:02.57 sko8U7ef0.net
>>678
> ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。
705:デフォルトの名無しさん
22/10/31 18:50:46.86 J+3pjzxx0.net
>>674
不可欠な機能ではあるが、核心的機能ではない。
事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。
Gitは方針を間違ってる。
もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、
アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。
Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。
別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。
勿論GNUdiffに入れるのがベストだが、この辺
706:は断られてもおかしくないし。 ただこれも人間用であって、マージする為に必要な機能部分ではないから、 君らから見てもGitではなくdiffに入れておけ、となるはずだが。 まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、 我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。 Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。 MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。 ビューを分離しておくことはものすごく重要だから。
707:デフォルトの名無しさん
22/10/31 19:41:41.79 oV1LtMOH0.net
え？まさかgit diffを差分を見るだけのツールだと思ってるの？
708:デフォルトの名無しさん
22/10/31 19:42:41.80 oV1LtMOH0.net
GNU diffに依存したら、GNU diffが使われないところで
動かないってわからんかなぁ
diffは移植性低いんだよ？
709:デフォルトの名無しさん
22/10/31 19:49:40.38 J+3pjzxx0.net
ちなみに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.
> URLﾘﾝｸ(www.git-scm.com)
このオプションが相当にヤバい。
これはデフォで
diff | less
となってる部分を、
diff --output-indicator-new='>' | less
とすれば幸せになれますよ、ということだが、これは
diff | sed 's/^\+/>/' | less
とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
Cで実装すべき案件ではないから。
そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。
多分こいつらは本当にCしか書けない、Cしか知らない連中だ。
sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。
コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。
プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。
だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。
710:デフォルトの名無しさん
22/10/31 19:51:14.64 oV1LtMOH0.net
git diffはパッチファイルを作るために利用されるし、
diffは環境依存するコマンドなんだから、
そんなのに依存したら、gitの移植性が低くなる
別の環境で実行したら、diffコマンドの出力がおかしくて
正しくパッチ当てられませんとかなったら困るやろ
常識で考えろや
711:デフォルトの名無しさん
22/10/31 19:53:03.45 oV1LtMOH0.net
>>685
> とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
あのさぁ、提案するのはGNUだけじゃだめだって理解してないの？
712:デフォルトの名無しさん
22/10/31 19:53:31.39 J+3pjzxx0.net
>>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。
713:デフォルトの名無しさん
22/10/31 19:56:13.88 GzQExg5g0.net
>>682
diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ
714:デフォルトの名無しさん
22/10/31 20:00:09.03 9mfNegYM0.net
ん?
これはもしかして以前来てたPOSIX原理主義者氏か?
715:デフォルトの名無しさん
22/10/31 20:00:09.25 oV1LtMOH0.net
>>688
全部同じ実装じゃねーよ
それぞれ全部細かい違いがある
すべてのプラットフォームのdiffにまで対応するなんて
大変な作業なんて誰もやろうとは思わん
716:デフォルトの名無しさん
22/10/31 20:01:01.17 oV1LtMOH0.net
例えば2004年版のdiffには-uがないからな
The Open Group Base Specifications Issue 6
URLﾘﾝｸ(pubs.opengroup.org)
717:デフォルトの名無しさん
22/10/31 20:02:19.83 J+3pjzxx0.net
>>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。
>>691
前後したが上記。
>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。
718:デフォルトの名無しさん
22/10/31 20:03:29.56 oV1LtMOH0.net
> まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？
依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ
719:デフォルトの名無しさん
22/10/31 20:04:11.62 oV1LtMOH0.net
OSの標準コマンドに依存したら
移植性は低くなるんだよ
常識やろ
720:デフォルトの名無しさん
22/10/31 20:08:10.94 J+3pjzxx0.net
>>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> URLﾘﾝｸ(ja.wikipedia.org)
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。
721:デフォルトの名無しさん
22/10/31 20:10:05.98 J+3pjzxx0.net
>>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。
通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。
722:デフォルトの名無しさん
22/10/31 20:15:24.67 oV1LtMOH0.net
>>696
-u がないとハンクの精度が下がるだろ
ほんとしらんならだまっとけよ
723:デフォルトの名無しさん
22/10/31 20:15:53.77 oV1LtMOH0.net
>>697
パッチファイルを受け取って
他の人がマージすることもあるだろ
ほーんと、しらんならだまっとけ
724:デフォルトの名無しさん
22/10/31 20:16:36.27 oV1LtMOH0.net
>>696
他のOSで使えるとは限らんだろうが
GNUしか頭にないんか
725:デフォルトの名無しさん
22/10/31 20:38:58.71 J+3pjzxx0.net
>>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に入れてるのを糞に言ってるが、保存先は本質ではないし、
適切なアーキテクチャであれば簡単に交換可能なものだ。
だから本来、こんな議論が発生する余地もないのだけど。
726:デフォルトの名無しさん
22/10/31 20:39:57.17 oV1LtMOH0.net
>>701
> それはGitの構造が糞だからだ。
結論ありきで理由を探すな
お前はクソな理由を一つも言っていない
727:デフォルトの名無しさん
22/10/31 20:40:47.45 oV1LtMOH0.net
以前来てたPOSIX原理主義者氏ではなく
また別のPOSIX原理主義者氏のようだなｗ
728:デフォルトの名無しさん
22/10/31 20:41:49.56 oV1LtMOH0.net
自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ
世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」
729:デフォルトの名無しさん
22/10/31 20:45:31.00 GrGctmUAM.net
POSIX原理主義はWindowsでの開発がめんどくさくなるんで本当に嫌いだわ
あと今更awkやsedの読みづらい文法覚えるより他のスクリプト言語で書いた方が楽だし、POSIX原理主義はPOSIXに慣れている奴のポジショントークにすぎないと思うね
730:デフォルトの名無しさん
22/10/31 20:46:22.02 GzQExg5g0.net
>>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない
731:デフォルトの名無しさん
22/10/31 20:49:18.25 oV1LtMOH0.net
>>705
POSIX原理主義者はPOSIXを理解してないよ。
732:デフォルトの名無しさん
22/10/31 20:55:34.73 GzQExg5g0.net
>>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん
733:デフォルトの名無しさん
22/10/31 21:08:17.57 J+3pjzxx0.net
>>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> URLﾘﾝｸ(ja.wikipedia.org)
だからそれはGitのアイデアでも全然無く、Git以前からdiffとedを組み合わせれば誰でも出来る物だった。
勿論diffの出力がキモだから出来るだけ--minimumなのは目指すとしても、
それはdiffを改善すべき話で、Git本体が対応する話ではない。
てかこの辺のソフトウェア階層の話が通じないところを見ると、割と階層無しの文化＝本当にCしか知らない感じだな。
例えばJSとかでは、扱うデータの先がDBなのか、ローカルファイルなのか、メモリ上のStringなのかを
上位のコードは区別しないで済むようにコーディングすることが普通で、
と言うか実際はそうしか出来なくて、強制的にそうさせられるわけだが、
形式的には、ネットワークでもローカルファイルでもメモリ上のStringでも、
プログラミングモデル側からは全部読み書き出来る状態になってから制御が渡される。
(メモリ上に展開し終えてから渡されるイメージ、なおこれをRubyでは上手いこと遅延読み出しにしてたりするが)
CでI/Oを分離するにしても普通はそうするし、実際、Gitでもそうなってる。
でないと git log -L で全展開の倍ほどメモリ食うとかあり
734:得ないし。 最終段のI/Oは普通はそうやって上位のコードと分離するもので、Gitもcat-fileでそうなってる。 ただ、それを交換出来ないので、テキストやDBに保存したい奴に対応出来てないだけ。 これはGitの構造の問題だよ。 それでsshを別に実装しますとか、かなり馬鹿げた方針だ。 少なくともJS知ってればそうはならない。
735:デフォルトの名無しさん
22/10/31 21:09:37.44 J+3pjzxx0.net
Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。
736:デフォルトの名無しさん
22/10/31 21:15:30.28 GzQExg5g0.net
>>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ
737:デフォルトの名無しさん
22/10/31 21:34:40.89 GzQExg5g0.net
BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
URLﾘﾝｸ(ezoeryou.github.io)
edとdiffを使ったようなVCSは眼中になかった
738:デフォルトの名無しさん
22/10/31 21:39:28.36 J+3pjzxx0.net
>>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。
ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
URLﾘﾝｸ(www.sqlite.org)
739:デフォルトの名無しさん
22/10/31 21:52:54.41 GzQExg5g0.net
>>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな