client send-pack doesn't follow protocol
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Dulwich |
Fix Released
|
Medium
|
milki |
Bug Description
According to the pack protocol for receive-pack at
https:/
(0)
If the receiving end does not support delete-refs, the sending end MUST
NOT ask for delete command.
(1)
A pack-file MUST be sent if either create or update command is used,
even if the server already has all the necessary objects. In this
case the client MUST send an empty pack-file. The only time this
is likely to happen is if the client is creating
a new branch or a tag that points to an existing obj-id.
In my github
https:/
and the attached patches, I have tackled these two issues.
As (1) suggests, when branches are created/updated to existing
server-side objects and when tags are created to existing server-side
objects, an empty pack-file should be sent.
Currently, the code will only send a pack-file if it is not empty. This
patch adds an additional check - no deletions (aka ZERO-SHAs) in new
refs. 0001-send... will handle this case.
As (2) suggests, delete commands should never be sent if the server
doesn't support them. 0002-Remove... handles this case. Additionally, if
report-status is included, then these commands are reported as failed.
I made a design choice here to match existing implementation regarding
report-status. Existing implementation in dulwich will only
report-status if the server supports it. On the other hand, git-push(1)
will report regardless of the receiver's report-status.
If (2) looks good, I would like to change the behaviour of status-report
as well to match git-push(1). This would allow failed delete commands to
be reported when the server doesn't have delete-refs.
Changed in dulwich: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Note: patches don't touch the http client