[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
764: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)05:49 ID:AHw2USmo0(2/17) AAS
>>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。
で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
省7
765: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(3/17) AAS
ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう)
766: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(4/17) AAS
ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。
767: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(5/17) AAS
これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)
省7
768(1): (ﾜｯﾁｮｲ d9e4-Ojdt) 2022/11/03(木)10:41 ID:NhDXzDSd0(1/3) AAS
それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される
769: (ﾜｯﾁｮｲ 699f-1Eu/) 2022/11/03(木)10:46 ID:odT0DHDr0(1) AAS
まだやってのか
暇そうだな
770(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)13:22 ID:AHw2USmo0(6/17) AAS
>>768
それは無理だね。
仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。
(使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何？でしかない)
GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。
俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。
省17
771(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/03(木)13:30 ID:9oLRzF140(1/4) AAS
index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。
772: (ﾌﾞｰｲﾓ MMeb-ntN1) 2022/11/03(木)13:52 ID:/4IN/B1bM(1) AAS
indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す
773(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)14:35 ID:AHw2USmo0(7/17) AAS
>>771
> index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。
いや普通に出来るよ。曖昧だったが、俺は git add -u; git commit -m "message"; で使ってる。
以降はワークフローの話だからどちらが正しいとかいう事ではないが、
> コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
これは若干邪道というか基本的に全部commitするものだろうし、commitしてから前に進めばいいだけで、
> どのcommitを取ってきてもちゃんと動く状態にするのが普通だから
省7
774: (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/03(木)14:40 ID:5PP47Osh0(1/3) AAS
git分からない思想も理解できないならSVN使えば？
775(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/03(木)14:46 ID:9oLRzF140(2/4) AAS
>>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。
776: (ﾌﾞｰｲﾓ MMeb-ntN1) 2022/11/03(木)15:04 ID:jVDh6EB5M(1) AAS
適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS
777(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)15:05 ID:AHw2USmo0(8/17) AAS
>>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。
778(1): (ﾜｯﾁｮｲ a95f-Tk+f) 2022/11/03(木)15:26 ID:O+O1uzzM0(1) AAS
>>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
省1
779(1): (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/03(木)15:53 ID:HnXRQ5rf0(1) AAS
index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。
780: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)16:18 ID:AHw2USmo0(9/17) AAS
>>778
> N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
(tutorial2を読んだだけの理解だから間違ってるかもしれんが、)
669で言ったように、Gitが分かりにくいのは業務プロセス名がコマンドに付いてるからだよ。
実際には、git add でスナップショットを取ってて、(←これが直感的に認識出来ない）
git commit でツリーの頭にそれを付け加えてるだけ。
だからaddしてないと付け加えるべきスナップショットがないからコケる。
省19
781(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)16:20 ID:AHw2USmo0(10/17) AAS
>>779
いやレビュー対象はcommit済みで、index上ではないだろ。
782: (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/03(木)16:22 ID:5PP47Osh0(2/3) AAS
うんうんわかった
大人しくSVN使え
その方が君には向いている
783: (ﾜｯﾁｮｲ d9e4-Ojdt) 2022/11/03(木)17:18 ID:NhDXzDSd0(2/3) AAS
>>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ
784(2): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)17:50 ID:e1pojM/n0(1/8) AAS
>>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
FreeBSDにはbash入っとらんぞ
785: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)17:52 ID:e1pojM/n0(2/8) AAS
>>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！
786: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)17:53 ID:e1pojM/n0(3/8) AAS
>>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ
787(1): (ﾌﾞｰｲﾓ MMeb-ntN1) 2022/11/03(木)18:10 ID:3fLLADP3M(1) AAS
>>784
macもbsahやめたんだよね
GPLから逃げるために
788(3): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)19:01 ID:AHw2USmo0(11/17) AAS
あと実は、masterの意義も分からないのだが。俺の場合は、
master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード
と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
省6
789(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)19:03 ID:AHw2USmo0(12/17) AAS
>>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが…
790(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)20:29 ID:e1pojM/n0(4/8) AAS
>>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ
791(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)20:33 ID:e1pojM/n0(5/8) AAS
>>788
1系、2系の同時開発とかあるやろ
792(1): (ﾜｯﾁｮｲ 7933-Tk+f) 2022/11/03(木)20:41 ID:vXMSDhes0(1/2) AAS
.gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？
793: (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/03(木)20:41 ID:5PP47Osh0(3/3) AAS
>>788
なんだやっぱりブランチのことすら分かってなかったのか
794(1): (ｶﾞｯｸｼ 06eb-lAaw) 2022/11/03(木)20:48 ID:5fumPTTR6(1) AAS
>>792
*.log* でなにか被ったりする？
795: 792 (ﾜｯﾁｮｲ 7933-Tk+f) 2022/11/03(木)20:58 ID:vXMSDhes0(2/2) AAS
logフォルダ作ってそれを無視することにしました
>>794
ごめんなさい！
796(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)21:00 ID:AHw2USmo0(13/17) AAS
>>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。
797(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)21:04 ID:e1pojM/n0(6/8) AAS
>>796
今自分で「必要だ」って言ったってこと理解してるかい？
798(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)21:15 ID:AHw2USmo0(14/17) AAS
>>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
省4
799(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)21:16 ID:e1pojM/n0(7/8) AAS
だからなんでgit使うだけで
bash＋たくさんコマンド入れなきゃならんのだよ
800(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)21:22 ID:AHw2USmo0(15/17) AAS
>>797
必要なのはポインタであってブランチではないんだ。
というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。
fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、
git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、
どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。
まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。
801(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)21:25 ID:AHw2USmo0(16/17) AAS
>>799
逆に一体どんな環境でやってるのさ？
普通のunixコマンド一式すら入ってないのか？
そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。
802(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/03(木)21:29 ID:e1pojM/n0(8/8) AAS
>>800
今話をしているのはお前が言ったこと
> 逆に言えば、同時開発する気がなければ要らないわけだな。
if (同時に開発する気がある) {
いる
} else {
いらない
省2
803: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/03(木)21:39 ID:AHw2USmo0(17/17) AAS
>>802
ん？どこを誤解されてるのかは分からんが、
俺は複数バージョンを同時開発する気はない。
ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。
804: (ﾜｯﾁｮｲ 7997-uk66) 2022/11/03(木)23:10 ID:9oLRzF140(3/4) AAS
>>801
普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。
805(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/03(木)23:14 ID:9oLRzF140(4/4) AAS
>>788
少なくともCIで回すときは楽だろ。
Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、
そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？
勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。
806(1): (ﾜｯﾁｮｲ d9e4-Ojdt) 2022/11/03(木)23:20 ID:NhDXzDSd0(3/3) AAS
>>798
以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない
macOSはbash,gcc,sambaをベースシステムにいれるのをやめた
これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由
linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い
GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね
他のOSSに依存するとこういうのもあるから気を付けないといけない
807(1): (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/04(金)00:15 ID:SQ9pznPg0(1/2) AAS
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
頭おかしい
808(2): (ｽｯｯﾌﾟ Sd33-wVCK) 2022/11/04(金)00:54 ID:NvjwOVKTd(1) AAS
まあdevelopはいらないかな
mainブランチで開発すりゃいいよ
リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい
809(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)01:05 ID:EF7BixRC0(1/9) AAS
>>798
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
gitの都合でbashに迷惑をかけるな
お前のやりそうなことだな
自分の都合で関係ないやつに迷惑をかける
810: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)01:06 ID:EF7BixRC0(2/9) AAS
>>808
初心者のお前の感想なんかどうでもいいよ
811: (ﾜｯﾁｮｲ 1901-FQW+) 2022/11/04(金)02:09 ID:v1xRwBrw0(1) AAS
GPLに賛同せずにGNU製品を使ってたってことだろね。
結局Linusもタダ乗り爺ってことでしょ。
812: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/04(金)02:50 ID:BbpXyzD40(1) AAS
ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え
git のブランチは全部等価
デフォルトで main / master 作られるけど
これも使いたくなけりゃ使わなくて良いし名前変えても良い
813: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)18:16 ID:XH5wI1Z90(1/9) AAS
>>805
そんなガキみたいなことはしないが、
どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。
ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね？
自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。
> 少なくともCIで回すときは楽だろ。
必要になったときに作ればいいだけなのと、
省2
814(3): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)18:17 ID:XH5wI1Z90(2/9) AAS
A. 消したbranchの情報が確認出来るのって、reflogsだけ？
B. あと、branchは線だ！ってマニュアルは言ってるけど、点だよなこれ？
（ドキュメントか実装のどちらかが間違ってると思うが)
以下git-flowを真似てるとして、gitkと同様に下から上にcommitして、
impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
省8
815(3): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)18:19 ID:XH5wI1Z90(3/9) AAS
そして、どうやらGitはブランチローカルという感覚がないらしく？
どのブランチにいても同じ結果が出るのはどうなのよ？---(B)
具体的には、この場合、
masterブランチでは、HEAD~1はinitialを指し、(master上での一つ前)
developブランチでは、HEAD~1はimpl2を指すべき(develop上での一つ前)
だと思うのだが、どこにいてもHEAD~1はimpl4を指してしまう。
つまり、HEAD~Nの探索先はグローバルであり、それは.git/objects下のツリーそのものらしい。
省16
816(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)18:20 ID:XH5wI1Z90(4/9) AAS
>>806
MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。
> GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった
よく分からんが結局は両方ともここかな？
> プロプライエタリなドライバソフトをLinuxカーネルに読み込む際にDRMの技術を応用している件についてだと思います。
> 外部ﾘﾝｸ[htm]:japan.cnet.com
> GPLv3ではDRMを実装する場合はそのDRMのアルゴリズムに加えて秘密鍵も公開することを義務付けているので、
省7
817(3): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)18:22 ID:XH5wI1Z90(5/9) AAS
>>807
>>809
お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。
Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。
そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、
それは立派なバグだから、bashの連中に投げれば直してもらえるよ。
省4
818: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)19:16 ID:EF7BixRC0(3/9) AAS
> お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
だからgitの話はgitの中で盛り上がればいいだろ
勝手に他人の家で盛り上がるな
ば～か
819: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)19:18 ID:EF7BixRC0(4/9) AAS
>>817
あとgitをbashに依存させるな
820: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)19:19 ID:EF7BixRC0(5/9) AAS
bashがなんでも修正を入れるわけがない
それは俺の仕事じゃないと言って断られるが落ち
bashをぶくぶく太らせるな
一つ事だけやらせろ
821(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/04(金)19:54 ID:fRhzbJ/d0(1/2) AAS
>>816
GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい
MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる
822(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/04(金)19:57 ID:fRhzbJ/d0(2/2) AAS
>>817
GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、
GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり
たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん
823(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/04(金)20:10 ID:jUM5cpqM0(1/2) AAS
どのOSでメインに作業してるのかわからん感じだな。
LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも当然DISり、 Windowsなんか論外って感じだろ。
3OSぐらい使ってたらとてもシェルなんか信用できないけどな。
824(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)21:06 ID:XH5wI1Z90(6/9) AAS
>>822
いやそこまでは全然見てない。
今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。
読む価値のないコードのはずだから。(物によって全然違うかもしれんが)
ただこれで回ってるのは事実だからな～。ちょっと観戦モードだ。
まず既に言ってるが仕様がグダグダ。
仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。
省18
825: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)21:10 ID:EF7BixRC0(6/9) AAS
口だけ達者で何もできない無能
826: (ﾌﾞｰｲﾓ MM33-ntN1) 2022/11/04(金)21:14 ID:PwG12fTHM(1/2) AAS
>>824
GNUが何なのか全く理解できていない
827: (ﾌﾞｰｲﾓ MM33-ntN1) 2022/11/04(金)21:27 ID:PwG12fTHM(2/2) AAS
>>823
自分が理解できないものは全部糞
理解力が致命的に弱い
この2つが合わさると全方面Disることになる
828(1): (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/04(金)21:35 ID:SQ9pznPg0(2/2) AAS
>>817
何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか？
金も貰えないのにそんなの苦行でしょう、アホらしい
それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか？
829(1): (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)21:39 ID:EF7BixRC0(7/9) AAS
bashの方を直せって言うなら
GNU bashのプロジェクトに殴り込みをかければいいじゃん
お前が
830(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)21:54 ID:XH5wI1Z90(7/9) AAS
>>828
逆だよ。他人に投げられることは他人に投げろと言ってる。
bashのバグだってことになれば、勝手に直してもらえるだろ。
自分で対応するのは、直してもらえないのが確定してからでいい。
>>829
そもそも俺はbashの互換性で苦労した試しがない。
ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。
省1
831: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)21:55 ID:EF7BixRC0(8/9) AAS
> 逆だよ。他人に投げられることは他人に投げろと言ってる。
なんのために？
832: (ﾜｯﾁｮｲ 8b14-Tk+f) 2022/11/04(金)21:56 ID:EF7BixRC0(9/9) AAS
> bashのバグだってことになれば、勝手に直してもらえるだろ。
だからお前がbashに通報しろって
お前という他人に投げたぞｗ
さっさとやれ
833: (ﾜｯﾁｮｲ 7997-uk66) 2022/11/04(金)22:08 ID:jUM5cpqM0(2/2) AAS
>>830
え、Cでプログラム書いたことないの？OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ…
考慮しなければならないのはファイルシステムと改行コードぐらいだろう。
834(1): (ﾌﾞｰｲﾓ MM33-ntN1) 2022/11/04(金)22:17 ID:qsZ+zSWqM(1) AAS
まあおまえら落ち着け>>815とか見る限りこいつはひとりではGitを理解できない
炎上させて答えを引き出そうとしてるから餌を与えちゃいかん
ほっとけばすぐいなくなるよ
835: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)22:48 ID:XH5wI1Z90(8/9) AAS
>>834
ああ、@1か、これは失礼。
ただお世辞にも分かりやすいとは言えないねこれは。
まあでも、ならbranchを残す意味はあり、>>815は取り下げだな。
>>814については引き続き募集中。
836(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/04(金)22:50 ID:XH5wI1Z90(9/9) AAS
@{1}ね、まあ分かると思うけど
837: (ﾌﾞｰｲﾓ MM33-ntN1) 2022/11/04(金)23:04 ID:7RpVnNq7M(1) AAS
>>836
@{1}に気が付くとはさすが軍師殿ｗｗｗ
838: (ﾜｯﾁｮｲ debb-qVfh) 2022/11/05(土)00:48 ID:yugci9j10(1) AAS
HEAD~1 で一つ前のリリースとか言ってて爆笑
リリースごとに一回だけコミットするつもりなのか？
永久に git 理解できそうにないな
839: (ﾜｯﾁｮｲ 5e8f-gUJl) 2022/11/05(土)01:35 ID:CLSrxuim0(1/2) AAS
ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな
つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか
840: (ﾜｯﾁｮｲ 527c-zlm6) 2022/11/05(土)01:42 ID:zPyCNtrD0(1) AAS
そもそも一つ前ｗみたいな考え方するようなものじゃないよなｗ
841: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)03:02 ID:0q4aURph0(1/9) AAS
自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな
POSIX原理主義者と一緒。POSIXの名前を勝手に使って
シェルスクリプトしかできないのをごまかしてる
gitを利用してシェルスクリプトしかできないのをごまかしてる
842(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)09:15 ID:646uiMLL0(1/38) AAS
>>717
ちなみに書く側のコマンドは hash-objectのようだ。
多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。
そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。
>>821
って、ふと気づいたが、俺が使ってるのはGitBashだったわ。
現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。
省3
843(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)10:38 ID:646uiMLL0(2/38) AAS
>>814
公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。
つまり熟知してる公式からみても面倒な作業だと認めているわけだ。
解決というよりは諦めと納得だが、これも質問を閉じる。
> 外部ﾘﾝｸ:zenn.dev
ちなみに、branchを『後から追加』は出来るか？
いやそんな使い方はおかしい！禁止だ！かもしれんが、
省4
844(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)11:40 ID:zDjINlW+0(1/26) AAS
>>842
index-stageを理解してないおまえにはわからないかもしれないけど、
DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、
逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、
そんな単純にはいかない
上下前次1-新書関写板覧索設栞歴
あと 158 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s