Ответ 1
Фиксировать шестнадцатеричный
Вы не просчитали гекс, но вы не передаете правильное значение. Помните, что каждой строке в smart protocol предшествует счетчик длины:
<length><data>
Итак, для строки, которая выглядит так:
00419eabf5b536662000f79978c4d1b6e4eff5c8d785 refs/tags/v2.4.2^{}
Вам нужно отбросить первые четыре символа, что делает фактическое commit hex:
9eabf5b536662000f79978c4d1b6e4eff5c8d785
Формат запроса
Когда POST ввод запроса, строки have и want должны быть разделены символом новой строки, но если вы посмотрите на результат из curl, вы увидите, что нет перевод строки:
=> Send data, 110 bytes (0x6e)
0000: 0031want 00419eabf5b536662000f79978c4d1b6e4eff5c8d7850024have 00
0040: 3e2be062dfcfd1fd4aca132ec02a40b56f637762020000
Вам нужно использовать --data-binary вместо --data:
--data-binary @-
Вам нужно префикс этих строк с подсчетом длины, и вам нужно закончить строку, состоящую из 0000:
0032want 9eabf5b536662000f79978c4d1b6e4eff5c8d785
0032have 2be062dfcfd1fd4aca132ec02a40b56f63776202
0000
Советы по отладке
Вы можете установить GIT_TRACE_PACKET=1 в свою среду, если хотите получить отладочную информацию от git, чтобы увидеть, что именно она отправляет туда и обратно.
И все, что он написал
Я не могу получить ответ сам, даже учитывая приведенную выше информацию, но я решил, что это поможет.
Update
Итак, это было весело.
Я установил локальный сервер git (используя git http-backend и thttpd) и запустил tcpdump, чтобы захватить трафика, генерируемого операцией git remote update. Оказывается, вам нужно отделить директивы want и have с помощью нулевой команды, которая равна 0000 (нет новой строки, поскольку длина также кодирует новые строки). То есть:
<length>want <commitid><newline>
0000<length>have <commitid><newline>
<length>done
например:
0032want 9eabf5b536662000f79978c4d1b6e4eff5c8d785
00000032have 2be062dfcfd1fd4aca132ec02a40b56f63776202
0009done
Это дает мне:
0000: POST /git/git/git-upload-pack HTTP/1.1
0028: Host: github.com
003a: Accept: */*
0047: Content-type: application/x-git-upload-pack-request
007c: User-agent: git/1.8
0091: Content-Length: 113
00a6:
=> Send data, 113 bytes (0x71)
0000: 0032want 9eabf5b536662000f79978c4d1b6e4eff5c8d785.00000032have 2
0040: be062dfcfd1fd4aca132ec02a40b56f63776202.0009done.
== Info: upload completely sent off: 113 out of 113 bytes
<= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
<= Recv header, 26 bytes (0x1a)
0000: Server: GitHub Babel 2.0
<= Recv header, 52 bytes (0x34)
0000: Content-Type: application/x-git-upload-pack-result
<= Recv header, 28 bytes (0x1c)
0000: Transfer-Encoding: chunked
<= Recv header, 40 bytes (0x28)
0000: Expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 18 bytes (0x12)
0000: Pragma: no-cache
<= Recv header, 53 bytes (0x35)
0000: Cache-Control: no-cache, max-age=0, must-revalidate
<= Recv header, 23 bytes (0x17)
0000: Vary: Accept-Encoding
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 4 bytes (0x4)
0000: 31
<= Recv data, 51 bytes (0x33)
0000: 0031ACK 2be062dfcfd1fd4aca132ec02a40b56f63776202.
<= Recv data, 6 bytes (0x6)
0000: 1fff
<= Recv data, 1370 bytes (0x55a)
0000: PACK.......[..x...An.0...z.?`..d.*[email protected](.tu......>~B.....]..8
0040: 2...j).OQ}..#.....'......[..8K..t..,%[email protected]'...
[....]
Обновление с двойным бонусом
Вы можете использовать команду git unpack-objects для извлечения пакета. Как видно из вышеприведенного трассировки, вы сначала возвращаете ответ с длиной (
0031ACK 2be062dfcfd1fd4aca132ec02a40b56f63776202), за которым следуют данные пакета, поэтому вам нужно отбросить эту первую строку:
$ git init tmprepo
$ cd temprepo
$ tail -n +2 output_from_curl | git unpack-objects
Unpacking objects: 100% (91/91), done.
$ find .git/objects -type f | head -3
$ git cat-file -p dc940e63c453199dd9a7285533fbf2355bab03d1
/*
* GIT - The information manager from hell
*
* Copyright (C) Linus Torvalds, 2005
*
* This handles basic git sha1 object files - packing, unpacking,
* creation etc.
*/
[...]