[PATCH 01 of 13 sparse] sparse: vendor Facebook-developed extension

[Martin von Zweigbergk]

On Wed, Jul 5, 2017 at 12:45 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
>> On Jul 3, 2017, at 17:51, Durham Goode <durham at fb.com> wrote:
>>> On 7/1/17 7:14 PM, Gregory Szorc wrote:
> [...]
>>> As I move code from the extension to core, I'm attempting to make as
>>> many things as possible no-op unless sparseness is enabled. This
>>> *should* mean that narrow isn't affected by the presence of sparse code
>>> in core. I'm also trying to not break Facebook with changes: if they
>>> need to e.g. rename their existing extension to "fbsparse," it should
>>> work, even with the presence of sparse code in core.
>>
>> The series looks reasonable to me (assuming people are ok with the initial vendoring), and I'm all for getting sparse into core, even if it's initially experimental.
>>
>> +1 on moving things to a special sparse module instead of merge.py too.
>
> Looks good to me too, but I'd like confirmation from Google that this fits with an eventual plan of upstreaming narrowhg on top of this, or at least easing the maintenance burden for them by reusing sparse code from core. Augie, Martin?

I'm happy to see sparse in tree and in core. There are some things we
need to discuss, but I think we can discuss those as things are being
moved into core. For example, should "hg clone --include X" be a
narrow clone of files (and directories, if using treemanifests)
matching X or a full clone with a sparse checkout of files matching X?

>
> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
>