Add sparse checkout feature about git-sync HOT 14 CLOSED

So since 2.19 git has a partial clone option, which most likely isn't supported on the server-side widely.
Adding in for context: https://github.com/git/git/blob/v2.19.0/Documentation/technical/partial-clone.txt

In general sparse checkout would still grab the data, but it wouldn't show within the tree.
Reducing the depth is already an optional option.
So sparse checkout seems to really only make sense with partial cloning support in my view.
As the main point is not downloading unnecessary files and not download unnecessary files, but hide them (sparse checkout):

If I missed something, please correct me and add your thoughts.

from git-sync.

Could you give a specific use case, why that would be needed?

from git-sync.

This is very usefull when you have multi-purpose repository but you don't want to clone the full repository each each time, it saves time and disk space.

eg. a repository containing all sort of infrastructure configurations like kubernetes yml files and your json dashboards for grafana but you only want to clone those json as a volume for your grafana deployment.

from git-sync.

from git-sync.

https://git-scm.com/docs/git-read-tree#_sparse_checkout

git init
git remote add origin git://...
git config core.sparseCheckout true
echo "{REPO_PATH}/{DESIRED_SUBDIR}/*" > .git/info/sparse-checkout
git checkout {BRANCH}

from git-sync.

The problem with sparseCheckout is that still the whole repo will be cloned and then only specified folder will be checked into working tree. So, disk space and time still used.

from git-sync.

@trnl --depth 1 should solve this problem.

from git-sync.

I don't think --depth solves the same problem OP was asking about.

from git-sync.

I think that even without the benefits of a partial checkout, sparse checkouts can still be useful in some situations.

For instance, I have an application that iterates through the folders at the top level of a repository and then does some work with the yaml files it finds in each directory.

See this structure:

.
├── team-a_access
│   └── access.yaml
├── team-a_app
│   └── foo.yaml
├── team-b_service
│   └── foo.yaml
│   └── bar.yaml
├── team-c_access
│   └── hola.yaml
│   └── helloworld.yaml
├── team-c_app
│   └── something.yaml
└── team-c_backend
    └── example.yaml

The folders belong to different teams and I would like each team to be able to run a separate deployment of this tool that operates only on their folders.

If git-sync could perform a sparse checkout then I wouldn't need to modify my application to filter the folders or move each teams folders into a separate repo. There are good reasons to try and avoid both of those options for me.

from git-sync.

+1 sparse checkout would be a useful feature

from git-sync.

+1 sparse checkout would be a useful feature

+1 sparse checkout would be a useful feature

this sparse checkout feature is very important for decoupling Static Files from the new features release

from git-sync.

+1 sparse checkout would be a useful feature

+1 sparse checkout would be a useful feature

this sparse checkout feature is very important for decoupling Static Files from the new features release

+1 to this.
A case where this would be exceptionally useful is when using this utility in conjunction with Kubernetes to synchronise Airflow dags that are not isolated in their own separate repo.

from git-sync.

I'm not inherently against this idea, if someone wants to take a run at a design. It's not clear if it should be a flag with literal contents or a flag with a filename or something else.

from git-sync.

I think the main idea is when you specify GIT_SYNC_ROOT that the content of the repo ends there and not inside of a folder

from git-sync.