Changes to 'sparse_paths' are not reflected on subsequent installs

[holdenrehg]

Changes to 'sparse_paths' are not reflected on subsequent installs

[jacebrowning]

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]

@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.

[ksharma-bdai]

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.