gitエラーメッセージ「サーバーは非広告オブジェクトのリクエストを許可しません」とはどういう意味ですか?


23

私はgithubからチェックアウトしようとしていますが、このエラーメッセージが表示されました:

[user@arch ~]$ git clone --recursive https://github.com/simsong/tcpflow.git
Cloning into 'tcpflow'...
The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
remote: Counting objects: 4190, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 4190 (delta 21), reused 29 (delta 12), pack-reused 4146
Receiving objects: 100% (4190/4190), 50.27 MiB | 2.21 MiB/s, done.
Resolving deltas: 100% (2954/2954), done.
Submodule 'src/be13_api' (https://github.com/simsong/be13_api.git) registered for path 'src/be13_api'
Submodule 'src/dfxml' (https://github.com/simsong/dfxml.git) registered for path 'src/dfxml'
Submodule 'src/http-parser' (https://github.com/nodejs/http-parser.git) registered for path 'src/http-parser'
Cloning into '/home/user/tcpflow/src/be13_api'...
remote: Counting objects: 1203, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 1203 (delta 2), reused 5 (delta 1), pack-reused 1194
Receiving objects: 100% (1203/1203), 477.47 KiB | 1.96 MiB/s, done.
Resolving deltas: 100% (821/821), done.
Cloning into '/home/user/tcpflow/src/dfxml'...
remote: Counting objects: 1929, done.
remote: Total 1929 (delta 0), reused 0 (delta 0), pack-reused 1929
Receiving objects: 100% (1929/1929), 572.09 KiB | 2.89 MiB/s, done.
Resolving deltas: 100% (1294/1294), done.
Cloning into '/home/user/tcpflow/src/http-parser'...
remote: Counting objects: 1487, done.
remote: Total 1487 (delta 0), reused 0 (delta 0), pack-reused 1487
Receiving objects: 100% (1487/1487), 667.24 KiB | 2.46 MiB/s, done.
Resolving deltas: 100% (916/916), done.
Submodule path 'src/be13_api': checked out 'c81521d768bb78499c069fcd7c47adc8eee0350c'
Submodule path 'src/dfxml': checked out 'c31224626cf5f6678d42cbcfbfcd4e6191c9a864'
error: Server does not allow request for unadvertised object 5bbcdc5df9d01b521e8da011bab0da70bdec3653
Fetched in submodule path 'src/http-parser', but it did not contain 5bbcdc5df9d01b521e8da011bab0da70bdec3653. Direct fetching of that commit failed.
[user@arch ~]$

だから私はこれらのリポジトリのメンテナーです。src / http-parserは別のリポジトリのフォークであり、そのリポジトリのメンテナーは、いくつかの自動生成された.gitignoreファイルをファイルに追加するためのプル要求を(理由なしで)一貫して受け入れていません。しかし、私はそれがここの問題だとは思わない。


同じコマンドを試しましたが、エラーはありませんでした。まだ問題がありますか?私の場合、別のコミットをチェックアウトしましたSubmodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'
。– ge0rdi

問題はなくなりました。これは、サブモジュール参照が存在しないチェックアウトのためのものだったことを意味すると思います。確信はないけど。
-vy32

このメッセージは混乱しますが、このメッセージは、サブモジュールを更新し、親モジュールを新しいコミットに更新し、サブモジュールに新しいコミットをプッシュしない場合に発生する可能性があります。それからもちろん、サブモジュールのリモートに存在しないコミットをチェックアウトするのに苦労するでしょう!
パトリック・サナン

問題は、サブモジュールを更新し、親リポジトリを更新し、親リポジトリをプッシュしたが、サブモジュールをプッシュしなかったことにあるようです。文字通り、親リポジトリは、githubのサブモジュールのリポジトリにないコミットを参照しました。
vy32

回答:


8

jgit-gitの広告参照とは何ですか?-スタックオーバーフロー

フェッチ中に、サーバーは自身が持っている参照、およびクライアントがフェッチしたい参照をリストできます。これらは公示された参照です。

  • サーバーから特定のコミットを直接取得することはできず、参照(ブランチとタグ)のみを取得するようです。むしろ、Githubサーバーはそのようなリクエストを拒否するように設定されています。
  • ですから、で特定のコミットを取得したい場合、フェッチされたref--depth<depth>-1(サブモジュールのメタデータで指定されたブランチ/タグ)から離れたコミットでなければなりません。

    通常、人々は、depth合理的に大きい数に設定することをお勧めしますが、それでもリポジトリ内のコミットの総数よりはるかに小さいです- 50またはのように100。たとえば50、プロジェクトの初期クローンを作成するときにTravisが使用するものです。

でサブモジュールを更新していない場合--depth、コミットが見つからないと、次のいずれかを意味します。

  • サブモジュールのツリーは「浅い」状態にあり、上記が適用されます(以前に更新された--depth、そのエントリが.gitmoduleshasにshallow = trueある場合のみ可能)
  • コミットは、サブモジュールが使用しているブランチではありません
  • コミットはサブモジュールのリポジトリにまったくありません:
    • 誰かがミスをしたか、
    • または、一度存在したが、強制プッシュによって削除された

記録については、特定のケースでは、最後のケースでした:コミット5bbcdc5df9d01b521e8da011bab0da70bdec3653https://github.com/simsong/http-parser.gitリポジトリにありません。


なにdepth
vy32

@ vy32は、で更新していない場合の情報を追加しました--depth
ivan_pozdeev

「かつては存在していたが、強制プッシュによって削除された」-この状況に頼ることはできますか?
skolsuper

1
@skolsuperは、取得する別のコミットを選択します。たとえば、それがサブモジュールだった場合、スーパープロジェクトで別のコミットに切り替えます。
ivan_pozdeev

3

広告されていないオブジェクトにアクセスする1つの方法は、同期することです。次に、サブモジュールの更新が機能するはずです:

git submodule sync --recursive
git submodule update

1
シンプルにするために+1。私にとってgit submodule updateは別のサブモジュールで失敗しましたが、これらの2行をすべてのサブモジュールに正しい順序で適用すると、ようやく機能しました。
Bizhan

2
潜在的に大規模なスーパープロジェクトの$ git submodule sync --recursive; git submodule update場合、リモートを複製した直後である場合は、実際にORを実行することをお勧めします$ git submodule update --init --recursive。これにより、プロジェクトファイルツリーが/project/root/下から上へ効率的に走査されます/project/root/.gitmodules。さらに多くの$ git submodule --help...
Cbhihe

ありがとう@Cbhihe --recursiveフラグを含めるために答えを編集します。
カーバー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.