Notices by xor_zt (xor_zt@molotov.sanrizuka-struggle.com)

@leno 言われてみればcloneは別にローカルの設定読まないんだよね だからローカル設定で差分が出る + curl側の仕様で優先順位があったという二重苦

@leno

* 貰ったログにおいて, httpにスキームが変わっているけど認証系の情報が削られているように見えたのは, transport_anonymize_url関数を通して削除しているため
- https://github.com/git/git/blob/4590f2e9412378c61eac95966709c78766d326ba/remote-curl.c#L521-L522
* つまるところextraheaderの適用有無ではなく, 以下の機序によるものと推測されます
- ls-remoteはローカルリポジトリのconfigを基準に見る
- cloneはグローバルconfigを基準に見る
- ローカルにextraheader設定があった
- curl側で二重指定されているうちextraheader側が優先された
- 認証失敗 + insteadOfは成功

@leno 今ソースコード読んで得られた結論です

* バックエンドにcurlを使っていることは両方変わらない
- `ag --cc "repository '%s' not found"` で検索かけるとremote-curl.c:L521しか引っかからない
* cloneの方ではいくつかプロジェクト固有設定の類を飛ばしている
- そもそもグローバルな設定しか見ないみたいな感じ
- https://github.com/git/git/blob/4590f2e9412378c61eac95966709c78766d326ba/builtin/clone.c#L1298
- 対するls-remoteは https://github.com/git/git/blob/4590f2e9412378c61eac95966709c78766d326ba/builtin/ls-remote.c#L118
* またcurl側でもURL側直接指定とダブったときうまく行かないことを確認している
- `curl -v -H "AUTHORIZATION: basic hogefuga" http://yeah:wow@example.com` はbasic hogefugaの方だけが記述されます
- どちらかというとこれが一番影響している可能性が高い (URL自体は同時に指定できているけれども, ヘッダとして指定されたほうが優先されている)

@leno http経由でファイル取得する場合全部に適用されるはず

https://github.com/git/git/blob/4590f2e9412378c61eac95966709c78766d326ba/http.c#L522-L531
こっから追ってくとhttp_copy_default_headers → http_request → http_request_reauth → http_get_file / http_get_strbuf / ...と続く

Edit: http.cの方あんまり関係なかったのでツリー読んでくれ

@leno
@citoppig
ということで昨日のやつ(gitのextraheader問題)雑調査しました報告をば (ツリーにあります)