On Feb 4, 2017, at 6:07 AM, Konstantin Khomoutov <[email protected]> wrote: > > commit 016e6ccbe03438454777e43dd73d67844296a3fd > Author: Johannes Schindelin <[email protected]> > Date: Mon Oct 30 20:09:29 2006 +0100 > > allow cloning a repository “shallowly"
That’s not what I mean by “shallow,” since according to the docs,[1] it only works for a single branch. It’s also not clear to me that there’s a way to pull more history at need with this mechanism. If I’m online, and I step back one checkin on a branch past the files I have locally, will it go pull what it needs transparently from the repo I originally cloned from? To me, a shallow clone says “give me the most recent history at the tip of all open branches, and fetch more at need.” This Git VFS sounds like an extreme form of that, where the initial clone depth is 0. I’d prefer something that copies more like 30 days to my local machine on the initial checkout, so that I could immediately go off-line and have an excellent chance of still having everything I needed. All of this is is an effort to avoid sending the deep history of a repository — at least on initial clone — which most of the time you never need. A secondary use of DVCSes is widespread total-repository replication, but for that you can trickle the history in over the course of days, if need be. For day-to-day use, you rarely need deep history. [1]: https://www.git-scm.com/docs/git-clone#git-clone---depthltdepthgt > commit ed5336a7541e19b267de53afc8d15cffdbde8286 > Author: Nguyễn Thái Ngọc Duy <[email protected]> > Date: Thu Aug 20 20:47:05 2009 +0700 > > Introduce "sparse checkout” According to Stack Overflow,[2] you still get all of the remote artifacts in your local repo clone when you do this, subject of course to --depth and such. What I mean by “narrow” is that it only clones a particular subdirectory, or some other pattern match, as Subversion allowed. For example, if I have three top-level directories in my repository, A, B, and C, I’d like to be able to say: $ fossil clone --narrow B https://my-project.org B.fossil which Fossil would realize means I want only B and its children. (We can argue separately over the syntax.) A nice side effect is that this would let you “shard” a large repository, since the local B.fossil clone could be re-shared separately. I have multiple cases here where I put multiple projects in a single repository, because Subversion encouraged that, and now I want them broken up into separate repositories, because Fossil likes that better. If the A, B, and C sub-trees are the same size, I expect this narrow clone to take about 1/3 the time as a full clone, and take about 1/3 the disk space. [2]: http://stackoverflow.com/q/2336580 _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
