- 10 Jun, 2017 1 commit
-
-
Fix ACK parsing in wait_while_ack() internal function. This patch handles the case where multi_ack_detailed mode sends 'ready' ACKs. The existing functionality would bail out too early, thus causing the processing of the ensuing packfile to fail if/when 'ready' ACKs were sent.
Roger Gee committed
-
- 10 Feb, 2017 1 commit
-
-
This change provides an option in git_libgit2_opt_t which can be used in git_libgit2_opts to turn off/on ofs_delta capability in libGit2
Gaurav Saral committed
-
- 06 Jan, 2017 1 commit
-
-
The Git protocol does not specify what should happen in the case of an empty packet line (that is a packet line "0004"). We currently indicate success, but do not return a packet in the case where we hit an empty line. The smart protocol was not prepared to handle such packets in all cases, though, resulting in a `NULL` pointer dereference. Fix the issue by returning an error instead. As such kind of packets is not even specified by upstream, this is the right thing to do.
Patrick Steinhardt committed
-
- 29 Dec, 2016 1 commit
-
-
Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Edward Thomson committed
-
- 12 Dec, 2016 2 commits
-
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
- 02 Nov, 2016 2 commits
-
-
When trying to receive packets from the remote, we loop until either an error distinct to `GIT_EBUFS` occurs or until we successfully parsed the packet. This does not honor the case where we are looping over an already closed socket which has no more data, leaving us in an infinite loop if we got a bogus packet size or if the remote hang up. Fix the issue by returning `GIT_EEOF` when we cannot read data from the socket anymore.
Patrick Steinhardt committed -
When reading a server's reference announcements via the smart protocol, we expect the server to send multiple flushes before the protocol is finished. If we fail to receive new data from the socket, we will only return an end of stream error if we have not seen any flush yet. This logic is flawed in that we may run into an infinite loop when receiving a server's reference announcement with a bogus flush packet. E.g. assume the last flushing package is changed to not be '0000' but instead any other value. In this case, we will still await one more flush package and ignore the fact that we are not receiving any data from the socket, causing an infinite loop. Fix the issue by always returning `GIT_EEOF` if the socket indicates an end of stream.
Patrick Steinhardt committed
-
- 07 Jun, 2016 1 commit
-
-
When we receive a packet of exactly four bytes encoding its length as those four bytes it can be treated as an empty line. While it is not really specified how those empty lines should be treated, we currently ignore them and do not return an error when trying to parse it but simply advance the data pointer. Callers invoking `git_pkt_parse_line` are currently not prepared to handle this case as they do not explicitly check this case. While they could always reset the passed out-pointer to `NULL` before calling `git_pkt_parse_line` and determine if the pointer has been set afterwards, it makes more sense to update `git_pkt_parse_line` to set the out-pointer to `NULL` itself when it encounters such an empty packet. Like this it is guaranteed that there will be no invalid memory references to free'd pointers. As such, the issue has been fixed such that `git_pkt_parse_line` always sets the packet out pointer to `NULL` when an empty packet has been received and callers check for this condition, skipping such packets.
Patrick Steinhardt committed
-
- 08 Mar, 2016 1 commit
-
-
Chris Hescock committed
-
- 18 Feb, 2016 1 commit
-
-
Patrick Steinhardt committed
-
- 12 Jan, 2016 1 commit
-
-
The inner packet may be split across multiple sideband packets.
Chris Hescock committed
-
- 14 Aug, 2015 1 commit
-
-
The conditional checked cbs->transfer_progress then used the value in cbs->push_transfer_progress. In both cases it should be push_transfer_progress
Dan Leehr committed
-
- 20 May, 2015 1 commit
-
-
This can be used by tools to show mesages about failing to communicate with the server. The error message in this case will often contain the server's error message, as far as it managed to send anything.
Carlos Martín Nieto committed
-
- 14 May, 2015 1 commit
-
-
Marius Ungureanu committed
-
- 13 May, 2015 2 commits
-
-
Having the setting be different from calling its actions was not a great idea and made for the sake of the wrong convenience. Instead of that, accept either fetch options, push options or the callbacks when dealing with the remote. The fetch options are currently only the callbacks, but more options will be moved from setters and getters on the remote to the options. This does mean passing the same struct along the different functions but the typical use-case will only call git_remote_fetch() or git_remote_push() and so won't notice much difference.
Carlos Martín Nieto committed -
The push object knows which remote it's associated with, and therefore does not need to keep its own copy of the callbacks stored in the remote. Remove the copy and simply access the callbacks struct within the remote.
Carlos Martín Nieto committed
-
- 13 Feb, 2015 1 commit
-
-
Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.
Edward Thomson committed
-
- 29 Dec, 2014 1 commit
-
-
Jacques Germishuys committed
-
- 09 Nov, 2014 1 commit
-
-
There is one well-known and well-tested parser which we should use, instead of implementing parsing a second time. The common parser is also augmented to copy the LHS into the RHS if the latter is empty. The expressions test had to change a bit, as we now catch a bad RHS of a refspec locally.
Carlos Martín Nieto committed
-
- 16 Sep, 2014 1 commit
-
-
Ciro Santilli committed
-
- 02 Sep, 2014 1 commit
-
-
Arkady Shapkin committed
-
- 27 Jun, 2014 1 commit
-
-
Philip Kelley committed
-
- 22 May, 2014 1 commit
-
-
We have too many places where we repeat free code, so when adding the new free to the generic code, it didn't take for the local transport. While there, fix a C99-ism that sneaked through.
Carlos Martín Nieto committed
-
- 21 May, 2014 1 commit
-
-
The protocol has a capability which allows the server to tell us which refs are symrefs, so we can e.g. know which is the default branch. This capability is different from the ones we already support, as it's not setting a flag to true, but requires us to store a list of refspec-formatted mappings. This commit does not yet expose the information in the reference listing.
Carlos Martín Nieto committed
-
- 21 Apr, 2014 3 commits
-
-
Jacques Germishuys committed
-
Jacques Germishuys committed
-
The user may have requested that the operation be cancelled.
Jacques Germishuys committed
-
- 20 Apr, 2014 1 commit
-
-
It's not very useful to only know that a pre-receive hook has declined a push, you probably want to know why.
Jacques Germishuys committed
-
- 25 Feb, 2014 1 commit
-
-
- added MSVC cmake definitions to disable warnings - general.c is rewritten so it is ansi-c compatible and compiles ok on microsoft windows - some MSVC reported warning fixes
Miha committed
-
- 11 Dec, 2013 1 commit
-
-
This changes the behavior of callbacks so that the callback error code is not converted into GIT_EUSER and instead we propagate the return value through to the caller. Instead of using the giterr_capture and giterr_restore functions, we now rely on all functions to pass back the return value from a callback. To avoid having a return value with no error message, the user can call the public giterr_set_str or some such function to set an error message. There is a new helper 'giterr_set_callback' that functions can invoke after making a callback which ensures that some error message was set in case the callback did not set one. In places where the sign of the callback return value is meaningful (e.g. positive to skip, negative to abort), only the negative values are returned back to the caller, obviously, since the other values allow for continuing the loop. The hardest parts of this were in the checkout code where positive return values were overloaded as meaningful values for checkout. I fixed this by adding an output parameter to many of the internal checkout functions and removing the overload. This added some code, but it is probably a better implementation. There is some funkiness in the network code where user provided callbacks could be returning a positive or a negative value and we want to rely on that to cancel the loop. There are still a couple places where an user error might get turned into GIT_EUSER there, I think, though none exercised by the tests.
Russell Belfer committed
-
- 03 Dec, 2013 1 commit
-
-
Jameson Miller committed
-
- 18 Nov, 2013 1 commit
-
-
Edward Thomson committed
-
- 11 Nov, 2013 2 commits
-
-
A previous commit forgot to update the head list after push as well, leading to wrong output of git_remote_ls().
Carlos Martín Nieto committed -
The callback-based method of listing remote references dates back to the beginning of the network code's lifetime, when we didn't know any better. We need to keep the list around for update_tips() after disconnect() so let's make use of this to simply give the user a pointer to the array so they can write straightforward code instead of having to go through a callback.
Carlos Martín Nieto committed
-
- 05 Nov, 2013 1 commit
-
-
Edward Thomson committed
-
- 01 Nov, 2013 2 commits
-
-
This allows us to add e.g. "HEAD" as a refspec when none are given without overwriting the user's data.
Carlos Martín Nieto committed -
This avoids sending our whole history bit by bit to the remote in cases where there is no common history, just to give up in the end. The number comes from the canonical implementation.
Carlos Martín Nieto committed
-
- 30 Oct, 2013 2 commits
-
-
This tells the server that we speak it, but we don't make use of its extra information to determine if there's a better place to stop negotiating. In a somewhat-related change, reorder the capabilities so we ask for them in the same order as git does. Also take this opportunity to factor out a fairly-indented portion of the negotiation logic.
Carlos Martín Nieto committed -
It was there to keep it apart from the one which read in from a file on disk. This other indexer does not exist anymore, so there is no need for anything other than git_indexer to refer to it. While here, rename _add() function to _append() and _finalize() to _commit(). The former change is cosmetic, while the latter avoids talking about "finalizing", which OO languages use to mean something completely different.
Carlos Martín Nieto committed
-