commit - b3a62bf5a9b4874417758b608c7257f78f6469bb
commit + 0e11765d9d4fd6b0493f356b3c4ad314ce7b2433
blob - a314451ecf6df80b9f87a023226778f15053eb2e
blob + bded0b757e1e36f5f2afe70832ee5dd8bb3d7607
--- notes-pull-push
+++ notes-pull-push
@@ -133,3 +133,28 @@ remote "origin" {
 # mapping: refs/heads/master <-> refs/heads/master
 branch "master" pull-from "origin"
 ]]]
+
+---
+
+Known implications of the above design for the implementation:
+
+For each changed file, the 'trivial-rebase' operation needs to know the
+ID of the blob which the new file content is based on ("base-blob ID").
+Otherwise the out-of-dateness check in 'trivial-rebase' cannot work.
+To satisfy this requirement, the client<->server protocol could require file
+content modifications in a chain of commits being pushed to be expressed
+in terms of GOT_OBJ_TYPE_REF_DELTA objects against known base blob IDs.
+The client can read such base blob IDs from the latest commit in its copy
+of the branch (e.g. refs/remotes/origin/master).
+
+For simplicity, it might make sense to require the protocol to express
+all file modifications in this way (GOT_OBJ_TYPE_REF_DELTA).
+File additions could be expressed as a delta against the empty blob's hash
+as a base. File deletions could send a delta which simply deletes all content
+from the specified base blob in addition to an explicit 'delete' command to
+allow the server to distinguish this case from an empty file on disk.
+
+Implementing a network protocol will require support for generating deltas.
+At present, got can only parse deltas, but not generate them. Since deltas
+are also necessary to create pack files it makes sense to implement support
+for creating pack files before implementing a network protocol.