{"thread":{"id":"43695","subject":"[PATCH (WISP) 0/5] Support shallow repositories","startedAt":"2006-10-30T19:08:14Z","lastAt":"2006-10-30T19:08:14Z","messageCount":1,"participants":["Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"296780","messageId":"Pine.LNX.4.63.0610302006301.26682@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43695","inReplyTo":null,"subject":"[PATCH (WISP) 0/5] Support shallow repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-30T19:08:14Z","receivedAt":"2006-10-30T19:08:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nDef.: Shallow commits do have parents, but not in the shallow\nrepo, and therefore grafts are introduced pretending that\nthese commits have no parents.\n\nThe basic idea is to write the SHA1s of shallow commits into\n$GIT_DIR/shallow, and handle its contents like the contents\nof $GIT_DIR/info/grafts (with the difference that shallow\ncannot contain parent information).\n\nThis information is stored in a new file instead of grafts, or\neven the config, since the user should not touch that file\nat all (even I did not once edit it myself during development!).\nEach line contains exactly one SHA1. When read, a commit_graft\nwill be constructed, which has nr_parent < 0 to make it easier\nto discern from user provided grafts.\n\nSince fsck-objects relies on the library to read the objects,\nit honours shallow commits automatically.\n\nThis stuff is definitely \"pu\" material:\n\n- I am not quite sure if we have to force non-thin packs when\nfetching into a shallow repo (ATM they are forced non-thin). \nComments?\n\n- A special handling of a shallow upstream is needed. At some\nstage, upload-pack has to check if it sends a shallow commit,\nand it should send that information early (or fail, if the\nclient does not support shallow repositories). There is no\nsupport at all for this in this patch series.\n\n- Instead of locking $GIT_DIR/shallow at the start, just\nthe timestamp of it is noted, and when it comes to writing it,\na check is performed if the mtime is still the same, dying if\nit is not. Is this enough?\n\n- I have not touched the \"push into/from a shallow repo\" issue.\nDon't even try it yet.\n\n- If you deepen a history, you'd want to get the tags of the\nnewly stored (but older!) commits. I don't think this works\nright now.\n\nThis series does the following:\n\n- gets rid of the call to rev-list in upload-pack\n\n  It is just a tiny change. It is needed so that the client can\ntell the server which commits to ignore for the moment. Note that\nthis is bad for porting to Windows: it should be relatively easy\nto spawn other programs in Win32, but is probably lot more work\nto just fork _and_ maintain the memory and fd's.\n\n- support fetching into shallow repositories\n\n  Up until now (including this patch), we do not have tool\nsupport to make shallow repos. This patch is separated from\nthe rest for your reviewing pleasure only.\n\n- support making a shallow repository by cloning with a depth\n\n  \"git-clone --depth 20 repo\" will lead to a shallow repository,\nwhich contains only commit chains with a length of at most 20. It\nalso writes an appropriate $GIT_DIR/shallow.\n\n- support deepening a shallow repository\n\n  \"git-fetch --depth 20 repo branch\" will fetch branch from repo,\nbut stop at depth 20, updating $GIT_DIR/shallow.\n\n- add tests to t5500\n\n  Since t5500 conveniently provides all we need to test shallow\nclones, no new test script was added, but t5500 extended.\n\nUnfortunately, my time resources are scarce in the next few days,\nbut I did not want to hold this stuff back any longer.\n\nCiao,\nDscho\n"}]}