From: Nguyen Thai Ngoc Duy Date: Sat, 16 May 2009 05:17:01 GMT Subject: Re: Narrow clone implementation difficulty estimate Message-ID: In-Reply-To: On Thu, May 14, 2009 at 8:39 PM, Jakub Narebski wrote: > Alexander Gavrilov writes: > >> We are considering using Git to manage a large set of mostly binary >> files (large images, pdf files, open-office documents, etc). The >> amount of data is such that it is infeasible to force every user >> to download all of it, so it is necessary to implement a partial >> retrieval scheme. >> >> In particular, we need to decide whether it is better to invest >> effort into implementing Narrow Clone, or partitioning and >> reorganizing the data set into submodules (the latter may prove >> to be almost impossible for this data set). We will most likely >> develop a new, very simplified GUI for non-technical users, >> so the details of both possible approaches will be hidden >> under the hood. > > First, there were quite complete, although as far as I know newer > accepted into git, work on narrow / sparse / subtree / partial > *checkout*.  IIRC the general idea about extening or (ab)using > assume-unchanged mechanism was accepted, but the problem was in the > user interface details (I think that porcelain part was quite well > accepted, except hesitation whether to use/extend existing flag, or > create new for the purpose of narrow checkout).  You can search > archive for that >  http://article.gmane.org/gmane.comp.version-control.git/89900 >  http://article.gmane.org/gmane.comp.version-control.git/90016 >  http://article.gmane.org/gmane.comp.version-control.git/77046 >  http://article.gmane.org/gmane.comp.version-control.git/50256 >  ... > should give you some idea what to search for. This is of course > only part of solution. FWIW I still maintain the patch series as a merged branch "tp/sco" under my branch "inst" here http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=refs/heads/inst -- Duy