2010/7/28 Elijah Newren <newren@xxxxxxxxx>: > 1) A user controls sparseness by passing rev-list arguments to clone. > > This allows a user to control sparseness both in terms of span of > content (files/directories) and depth of history. It can also be used > to limit to a subset of refs (cloning just one or two branches instead > of all branches and tags). For example, > $ git clone ssh://repo.git dst -- Documentation/ Does pathspec is supported to in addition to prefix? > $ git clone ssh://repo.git dst master~6..master > $ git clone ssh://repo.git dst -3 > (Note that the destination argument becomes mandatory for those doing > a sparse clone in order to disambiguate it from rev-list options.) > > This method also means users don't need much training to learn how to > use sparse clones -- they just use syntax they've already learned with > log, and clone will pass this info on to upload-pack. > > There is a slight question as to whether users should have to specify > "--all HEAD" with all sparse clones or whether it should be assumed > when no other refs are listed. So you basically kill off shallow clone too, with "master~6..master". I wonder what happens if user does "git clone ... master~6..master~3"? > 4) All revision-walking operations automatically use these limiting args. > > This should be a simple code change, and would enable rev-list, log, > etc. to avoid missing blobs/trees and thus enable them to work with > sparse clones. fsck would take a bit more work, since it doesn't use > the setup_revisions() and revision.h walking machinery, but shouldn't > be too bad (I hope). > > There are also performance ramifications: There should be no > measurable performance overhead for non-sparse clones (something that > might be a problem with a different implementation that did > does-this-exist check each time it references a blob). It should also > be a significant performance boost for those using it, as operations > will only need to deal with the subset of the repository they specify > (faster downloads, stats, logs, etc.) Revision walking is not the only gate to access objects. Others like diff machinery needs also be taught about rev-list limits. > 5) "Densifying" a sparse clone can be done > > One can fetch a new pack and replace the limiting rev-list args with > the new choice. The sparse checkout information needs to be updated > too. > > (So users probably would want to densify a sparse clone with "pull" > rather than "fetch", as manually updating sparse checkouts may be a > bit of a hassle.) What information would you send to the server to request new pack in sparse clone? Currently we send all commit tips. rev-list has a notion to subtract commit trees. I don't know if it can "add" or "subtract" tree prefix though. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html