Ramkumar Ramachandra <artag...@gmail.com> writes: > I'll raise some (hopefully interesting) points. Let's take the example > of a simple push: I start send-pack, which in turn starts receive_pack > on the server and connects its stdin/stdout to it (using git_connect). > Now, it reads the (sha1, ref) pairs it receives on stdin and spawns > pack-objects --stdout with the right arguments as the response, right? > Overall, nothing special: just pack-objects invoked with specific > arguments. > > How does pack-objects work? ...
You've been here long enough to know that you can and should learn things yourself instead of repeating "tell me tell me" ;-) > threads to find_deltas(). This is where this get fuzzy for me: it > calls try_delta() in a nested loop, trying to find the smallest delta, > right? Yes. > I'm not sure whether the interfaces it uses to read objects > differentiates between packed deltas versus packed undeltified objects > versus loose objects at all. Yes, but that happens way before that. Start reading from pack-heuristics document to get the general overall feel of what goes on, and then go back to the source. > Now, the main problem I see is that a pack has to be self-contained: I > can't have an object "bar" which is a delta against an object that is > not present in the pack, right? Therefore no matter what the server > already has, I have to prepare deltas only against the data that I'm > sending across. There is a --thin option to allow deltas against base objects that are known to exist on the other end to be used in the pack without including the base objects. The receiving end then re-adds the base objects to the received data to complete the pack. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
