Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to 'sparse_paths' are not reflected on subsequent installs #265

Open
holdenrehg opened this issue Sep 5, 2021 · 3 comments
Open

Comments

@holdenrehg
Copy link

There was something pointed out in Issue #218 that I ran into today:

Updating sparse_paths entries
It looks like at the moment the sparse_paths entries are only written during the initial cloning. So if we later decide we need more files from a repo, we can not simply update the gitman.yml file and do an update, we need to either delete the repo first, or manually update the sparse-checkout file.

I'm not sure if this is expected behavior or not. It doesn't feel too natural that updating sparse_paths and then re-running install or update doesn't pull in the new paths defined. It does look like you need to delete the entire dependency folder and re-run.

@jacebrowning
Copy link
Owner

It doesn't feel too natural that updating sparse_paths and then re-running install or update doesn't pull in the new paths defined.

I agree and would be open to a PR that changes that.

@jacebrowning jacebrowning changed the title sparse_paths updates Changes to 'sparse_paths' are not reflected on subsequent installs Mar 11, 2022
@ksharma-bdai
Copy link

Hi @jacebrowning, I ran into this for a very specific use case and would like to take a shot at making a PR.

A couple of questions from a quick look through the source:

Is there a minimum version of git that is supported? I noticed gitman currently manually creates .git/info/sparse-checkout rather than using git sparse-checkout <init/set/add/reapply/enable/disable> from git 2.25 (2020) I believe. Can understand if you want to support older versions of git, but just checking if I should update things to use the new command while I'm in here.

It seems like this is just a case of passing sprase_paths into update and checking if there's a mismatch, e.g.:

  • full checkout -> sparse (new entries)
  • sparse -> updated sparse (updated entries)
  • sparse -> full checkout (all entries removed)

I'm assuming we'd want to do this check somewhere towards the end of update here after all of the clone/local changes present/etc. checks?

If that all sounds reasonable, I can put up a PR with updated test cases (for the above transitions) in the near-ish future.

@jacebrowning
Copy link
Owner

@ksharma-bdai Right now the README calls out Git 2.8+, but if we need to bump that to include newer features, that's fine.

I didn't write most of the sparse_paths logic so I'd recommend looking through git blame to locate the original PR authors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants