問題タブ [git-lfs]

レポートの PDF スナップショットをコミットしたリポジトリがあります。git lfs を試して、生活の質が向上するかどうかを確認したい。

ここ ( https://github.com/rtyley/bfg-repo-cleaner/releases )の手順に従って、BFG を使用して古いバイナリを消去し、lfs に移行しました。リポジトリに Gitlab サーバーを使用することに関連するいくつかのしわがありましたが、最終的にはこれでうまくいったと思います。

私たちが何をしたかを示し、最後にマージ競合のクリーンアップについて質問するために書いています。

抄録をお見せします。「--mirror」クローン (裸のレポ) をチェックアウトし、BFG がその作業を行い、いじってからプッシュバックします。

これを試す場合は、レポにプッシュバックする際のトラブルに備える必要があります。1 つの問題は、8.12 より前の Gitlab では、git の SSH 転送と git lfs の HTTPS 転送の間でパスワード管理が統合されていなかったことです。もう 1 つの問題は、Gitlab プロジェクトの「保護」です。これは、Gitlab を使用している場合に見られる可能性があります。初めてプッシュしたときにこれを見ました：

この問題を回避するためにいくつかの変更を加えました。Gitlab の最新バージョン (8.12.4) が必要でした。古い証明書を無視するように Git に指示する必要がありました。Gitlab サーバーでは、開発者がプッシュできるようにプロジェクトを「保護しない」必要がありました。私は所有者であり、通常の git の変更をプッシュできるため、なぜそれが必要なのかわかりませんが、どうやら lfs の統合は異なるようです。大騒ぎした後、リポジトリへのプッシュバックに成功しました。

成功！

次に、このリポジトリの作業ディレクトリに戻り、PDF ファイルが保存されているディレクトリに戻り、git pull を試しました。対処しなければならないマージの競合がたくさんあります。

おそらく、リモートのクリーンなクローンを作成して、そこから先に進むと思います。私がインターネットで見つけた指示は、それについてはあまり役に立ちません。それらは主に、進行中の lfs や lfs のクローンを扱うことについてではなく、lfs を使い始めることに関するものです。誰かがこのことを複製し、lfs を持っていなかったらどうなるか、少し心配です。ああ、まあ、見てみましょう。

これが私の質問です。これらのバイナリ競合のすべてに対処したい場合、どうすればよいでしょうか? サーバーからのすべての変更を単に受け入れたい場合は、競合する「fn.pdf」ごとに1回、これを何度も実行する必要があるようです。

それを何度も行うのは面倒に思えますが、できると思います。

また、こちら (バイナリ ファイルとの Git の競合の解決) で試してみるため のアドバイスも見つけました。

しかし、私はそれとどのように相互作用するかを確実に伝えることはできません. diff は 3 列のバッファーを持つ gvim フレームを起動しますが、うまくナビゲートできませんでした。編集者の地獄に私を着陸させているように私には思えます。

私は優れたsameersbn/gitlabを使用して、仕事用のカスタム gitlab サーバーをセットアップしています。

だから私はばかげたシナリオを持っています.gitlab ce v8.12.5を使用して10〜20 GBgit lfsの範囲のファイルを保存するために使用していますが、いたるところに500のサーバーエラーが表示され、アップロードを完了できません.

質問: サーバー側の制限を増やす方法を知っている人はいますか?

注: これは 413 nginx の問題ではありませんclient_max_body_size 500G。gitlab に正常に転送されるように設定しました。

さらに情報が必要な場合 (つまり、ログ ファイルなど)、喜んで提供します。コメントを残してください。

Update.1:

この同じ問題に関連するgitlabの問題があるようです。

Update.2

関連するその他のリソース:

今のところ、Docker コンテナのチェーンまたはプロキシ サーバーのどこかにタイムアウトがあるというのが私の仮説です。

git bash: エラー: RPC に失敗しました。結果 = 18、HTP コード = 200B | 1KiB/秒

https://github.com/gitlabhq/gitlabhq/issues/694

これは、gitlab が500でエラーを出すのとほぼ同時に、docker にマップされたデバイス/dev/dm-7が100% フルになることに気付いたところです。

これは gitlab の問題ではなく、docker の問題であり、gitlab のスペースが不足しているだけだと思い始めています。

お時間をいただき、ありがとうございます。

Git LFS が大きなファイルを適切に追跡するのに問題があります (同様の問題がここで報告されています: Git LFS は、次のことを行うまで、大きなファイルを適切に追跡することを拒否しました)。

私の特定のケースでは、複数のサブディレクトリで構成されるディレクトリをプッシュしようとしています。各サブディレクトリには、追跡したい特定の種類のファイルがあります。これらのファイル タイプの拡張子は.bed、、、.Bedおよび.sorted. これが私が従ったレシピです：

を実行しgit add .、次にgit commit -m "initial commit"、それぞれの追跡コマンド (例: git lfs track ".bed")を発行し、次に を実行しましたgit push origin master。

しかし、「this exceeds GitHub's file size limit of 100.00 MB」で終わる複数のエラー コマンドを受け取りました。このトピックに関するスタック オーバーフローの投稿はほぼすべて確認済みです (たとえば、git lfs が 100MB を超えるファイルに対して適切に機能しないなど)。アドバイスをいただければ幸いです。

私は自分のプライベート リポジトリにセットアップしgit-lfs、すべてがコマンド ラインから完全に機能します。

TeamCity ビルド エージェントをセットアップして、git-lfsインストールと初期化を行いました。ただし、TeamCity ビルドで実行しようとすると、git-lfs pullコマンドが永久にハングし、データがまったく転送されません。私のタスク マネージャーは、git-lfs.exe が存在するがアイドル状態であることを示しています。エージェントの作業フォルダー (エージェント マシン上) から手動でテストする場合、git-lfs pullまたはgit lfs pullすべての大きなファイルを正常にダウンロードする場合。

私のビルド構成にはgit-lfs pull最初のビルドステップがあり、ソースが更新された直後に実行されます。

TeamCity ビルド プロセス経由での実行が、ビルド エージェント内のコマンド ラインでのgit-lfs pull実行と異なる理由を知っている人はいますか?git-lfs pull

TeamCity 10.0.2 (42234) を使用しており、エージェントが更新されています。

Windows用にgit-lfsをインストールしました。と の両方で私の道にあるようGit BashですPowerShell。ここからの出力は次のとおりですGit Bash

それでも、実行すると：

pre-pushフックで次を取得します。

pre-pushフックを削除して再インストールしようとしましたが、それでも同じ結果が得られます。

追跡する必要があるファイルをプッシュしてテストしました...使用git lfs track、追加.gitattributes、および追跡されたファイルですが、git-lfs ストレージではなく、通常の git リポジトリにプッシュされます。

git lfs install適切なコンテンツをpre-pushフックに入れることができない理由や、回避策を知っている理由はありますか?

Github デスクトップがインストールされ、実行されています。Git LFS をダウンロードし、リポジトリと大きなファイルを Gitlab サーバーに同期しようとしています。ただし、次のエラーが発生し、続行する方法がわかりません。

どういうわけか次のステップをスキップしたようです

これはセットアップ手順で提供されます

しかし、これを試してみると、これも失敗します...

どうすればこれを修正できますか?

Bitbucket サーバーでホストされている LFS git リポジトリがあります。今は LFS は必要ありません。

git LFS リポジトリから通常のリポジトリに戻す方法は?

LFS を使用したレポの場合 - コミットにはファイルの代わりに「ポインター」があります。また、LFS を削除する必要がある場合は、「ポインター」の代わりにファイルを使用する必要があります。では、すべての「ポインター」をコミット履歴のファイルに置き換えるにはどうすればよいでしょうか。

それは何かのようなものですgit lfs smudgeが、すべてのログに適用する必要があることを提案してください。