# Where can I learn more about "partial checkouts"?
**URL:** https://discourse.pijul.org/t/where-can-i-learn-more-about-partial-checkouts/194
**Category:** Question
**Created:** [April 22, 2018, 5:34am UTC](https://discourse.pijul.org/t/where-can-i-learn-more-about-partial-checkouts/194 "2018-04-22T05:34:42Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@erlend\_sh](https://discourse.pijul.org/u/erlend_sh)
#### Post date: [April 22, 2018, 5:34am UTC](https://discourse.pijul.org/t/where-can-i-learn-more-about-partial-checkouts/194/1 "2018-04-22T05:34:42Z")
In [“The road ahead”](https://pijul.org/posts/2018-04-21-pijul-0.10/) there is this brief feature description:
> Partial repository checkouts. This is one the coolest features of Pijul, which will hopefully allow it to scale to much bigger repositories than others.
This would be a pretty huge deal for monorepos. There’s lots of custom tooling to ease the management of Git monorepos, e.g. [https://lernajs.io/](https://lernajs.io/), but certain parts of its architecture is hard to get around.
Has there been any writings anywhere about how Pijul’s partial checkouts would work?
---
### Author:  [@whitespace](https://discourse.pijul.org/u/whitespace)
#### Post date: [April 23, 2018, 1:37am UTC](https://discourse.pijul.org/t/where-can-i-learn-more-about-partial-checkouts/194/2 "2018-04-23T01:37:17Z")
I guess it is something like
```auto
svn checkout http://example.com/svn/repo/trunk/subdirectory
```
You can checkout any subdirectory of the project, keep the history, and still can pull from the project (`svn update`).
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [April 24, 2018, 5:37pm UTC](https://discourse.pijul.org/t/where-can-i-learn-more-about-partial-checkouts/194/3 "2018-04-24T17:37:45Z")
> [@erlend\_sh](#):
>
> Has there been any writings anywhere about how Pijul’s partial checkouts would work?
No, but I can explain more here. There are two levels of implementation:
1. Because _Pijul patches commute_™, and include a globally unique identifier of the files they apply to, it is fairly easy to just pull the patches that apply to a subset of the repository. This allows one to work on that subset and make patches against it. Now, remember that branches/repositories behave as sets (actual mathematical sets) of patches, ordered only by the dependencies, explicitly mentioned in the patches themselves. This means that when the author pushes to a central monorepo, that monorepo will have the dependencies, which is the only condition required to merge patches. Hence, the monorepo will just compute the union of its sets of patches with the new patches.
2. Another implementation level is to help users write patches that apply to just one subset of the repository. I don’t know if others agree, but this is what I’d like to do with nested repositories: when you create a nested repository, it creates an empty `.pijul`, which just means that `pijul record` from inside the nested repository will record a patch only in the nested repository path. Obviously, this default behaviour could be overridden with some command-line option.