Re: Narrow clone implementation difficulty estimate

> Alexander Gavrilov <angavrilov@gmail.com> 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.