[過去ログ]
Git 18 (1002レス)
Git 18 http://mevius.5ch.net/test/read.cgi/tech/1650651945/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
リロード規制
です。10分ほどで解除するので、
他のブラウザ
へ避難してください。
82: デフォルトの名無しさん (ワッチョイ 8f10-UDF2) [sage] 2022/05/07(土) 20:22:32.06 ID:ib0Eop5f0 Git v2.36.1 http://mevius.5ch.net/test/read.cgi/tech/1650651945/82
103: デフォルトの名無しさん (ワッチョイ a1ad-fRoS) [] 2022/06/07(火) 11:37:04.06 ID:KSznXeRL0 git質問になります。 TortoiseGitのコミット後に復元、あるいはbranchのmarge時の一時的なstachを fsckで拾う事は可能ですか? 何がしたいのかと言うとコミットしていないファイルを事故ってロストしてしまいました。 コミットしていた場合、あるいはstashに退避していた場合、これらをgitから取り出せる事は理解しています。 今回の場合上記どちらも行っていません。しかし直前にブランチをリベースし、コミット後に復元を使用しています。 git的にはリベース時のstach退避も、コミット後に復元のアンカーも(多分stashですよね)、 ユーザーが意識していないだけでコミットしていて取り出せると思っているのですが、ハッシュを見つけられない状況にあります。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/103
127: デフォルトの名無しさん (ワッチョイ cedb-805U) [sage] 2022/06/20(月) 22:37:42.06 ID:wz6MnYSq0 ヤフレカス http://mevius.5ch.net/test/read.cgi/tech/1650651945/127
161: デフォルトの名無しさん (アウアウウー Sad3-GKPB) [sage] 2022/06/27(月) 18:27:28.06 ID:lwSf5/nva サルプル? 面白いことや皮肉なことを言おうとしたときは噛んじゃダメだろ 5chもミスった書き込みのやり直しができたらいいのにね そう、Gitみたいにね! http://mevius.5ch.net/test/read.cgi/tech/1650651945/161
176: デフォルトの名無しさん (ワッチョイ 4f46-MWx3) [sage] 2022/06/30(木) 21:11:17.06 ID:AaQTfIBD0 gitlabをオンプレでやってるところはそこそこいると思う http://mevius.5ch.net/test/read.cgi/tech/1650651945/176
324: デフォルトの名無しさん (ワッチョイ 7d63-1dJg) [sage] 2022/07/19(火) 06:41:24.06 ID:k+9W9ROz0 GitHubの話はソースコード ホスティング総合【GitHub,GitLab,Bitbucket等】スレでやってほしいな http://mevius.5ch.net/test/read.cgi/tech/1650651945/324
435: デフォルトの名無しさん (オッペケ Sr5d-mMCY) [sage] 2022/08/07(日) 06:13:33.06 ID:xRSduvLwr 相変わらずのダサいコードで笑う http://mevius.5ch.net/test/read.cgi/tech/1650651945/435
449: デフォルトの名無しさん (ワッチョイ 027c-5Ix7) [sage] 2022/08/13(土) 20:04:36.06 ID:WN46//k40 個人レベルだからこそ簡単に導入出来るgitを使う 別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし 便利だと思うのだけどね ただバイナリ(excelのファイル)みたいなのには使わないが http://mevius.5ch.net/test/read.cgi/tech/1650651945/449
643: デフォルトの名無しさん (ワッチョイ 7997-uk66) [] 2022/10/29(土) 11:09:21.06 ID:+W9Ulup+0 >>640 手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので? http://mevius.5ch.net/test/read.cgi/tech/1650651945/643
656: デフォルトの名無しさん (ワッチョイ 8b8f-5UCg) [sage] 2022/10/30(日) 23:53:15.06 ID:LXgcbV870 Linusも言ってたような気がするけど、気に食わなければ自分で作れ 以上 http://mevius.5ch.net/test/read.cgi/tech/1650651945/656
739: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/01(火) 08:06:50.06 ID:Jzc3CN/20 と書くと意味不明だが、この場合は要は貰ったポインタを一々投げ返して操作してもらう。 具体的には、 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って何?みたいな質問が掲示板上でもやたらでてくるわけでさ。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/739
748: デフォルトの名無しさん (オッペケ Src5-8VyY) [sage] 2022/11/01(火) 12:34:56.06 ID:lDKItQe4r Git初心者に語らせると頓珍漢な文章が生まれるという好例 http://mevius.5ch.net/test/read.cgi/tech/1650651945/748
945: デフォルトの名無しさん (ワッチョイ 617b-8+ss) [sage] 2022/11/06(日) 09:32:57.06 ID:OfQ8ymDc0 あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ!」と言ってるのは不適切だ。 Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、 同様に内部実装を見せる形で書くのが正しく、 つまり、「branchは『線』のように見せてますが、実は『点』です!」と言わないと誤解される。俺がそうだが。 これは解像度が統一されてないから起こった問題だ。 一般のマニュアルは疎結合状態、 つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、 『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。 この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。 Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、 それが外面仕様なのか内部実装なのか、 またbranchのように外面仕様と内部実装が異なってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能) それは正しく説明しなければならない。 密結合なら、上記の通り、「『線』として見せてますが実は『点』です!」と書くべきだ。 とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。 ただ、そもそも仕様がグダグダ過ぎるし、 或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。 おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。 とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/945
965: デフォルトの名無しさん (ワッチョイ 09e4-chQ5) [sage] 2022/11/06(日) 13:39:49.06 ID:az1H5JFk0 >>954 脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能 DBのATTACHとは全然違う マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる でもこれはかなり特殊な用途に使うもので普段使いするようなものではない http://mevius.5ch.net/test/read.cgi/tech/1650651945/965
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.032s