Commit Briefs
stop allowing empty send {} or fetch {} blocks; yacc complained about grammar
yacc has been complaining about "shift/reduce conflicts" since commit 16c4be8c1cab9456f9dd0468c27f8ab73235737e Revert that change for now. Not sure how it can be done properly. In any case, allowing empty config blocks is not very important.
fix seek to incorrect offset in the delta base when creating deltas
The stretchblk() function needs to compare data located after the block which has just been matched. However, upon entry it was resetting the file pointer of the delta base to the beginning(!) of the block. The other file is correctly positioned after the block. In many cases the data won't match and stretchblk() will not stretch the matched block. But when the data did happen to match this resulted in a bogus delta, and wrong file contents when the delta was applied. Fix this by setting the delta base file pointer to end of the block. Problem reported by naddy after our server refused a pack file which was sent by 'got send'. I could reproduce the issue by running the 'gotadmin pack' command on a copy of naddy's repository. ok naddy
make realloc_ids() malloc-like and do not overallocate
Let realloc_ids() take as argument the number of entries to allocate. Do not allocate an extra chunk. ok stsp
drop realloc_ids() initialization calls, one of which had a typo
realloc_ids() is called again in the loops that assign to the ID arrays, before the first assignment. ok stsp
Add got(1) command tab-completion for ksh(1) to EXAMPLES section.
Suggested by Clint Pachl, thanks!
do not send a pack file when 'got send' is only deleting branches
The git protocol spec says the client MUST NOT send a pack file if the only command used is 'delete'. Fixes 'got send -d' against Github's server which closed the session upon receiving the empty pack file we sent. This problem wasn't caught by regression tests since git-daemon does accept an empty pack file. Problem reported by jrick.
remove github capabilities workaround from got-send-pack, it is not needed
This workaround was inherited from git9, which claims that Github did not send capabilities. Protocol traces show that Github's server does in fact advertise its capabilities. Git protocol capabilities are hidden behind a NUL byte in the middle of the first refline sent by the server. This makes them easy to miss when treating a refline as a C string. I guess this is why Ori concluded that Github didn't send any capabilities. Or perhaps Github has been fixed since.
add send and fetch plumbing to parser for got.conf
This is the beginning of support for naddy's suggestion to break this out similar to git. More code to come from stsp. ok stsp@