You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So we have a use-case where we want to be able to define either one or more folders and/or files that should be checked out from the git repo.
So for instance we have a repo that only contains folders in the root of the git repo and they can be used for different things and in different situations. So to avoid having to clone everything or to checkout everything, we want one of two things.
One solution is that we must clone the entire git repo down to local, but we use sparse-checkouts which is an older feature and we tell git only to checkout a list of names from the repo and maintain them.
Or the second solution is to use git clone --filter from git 2.19 now works on GitHub (tested 2020-09-18, git 2.25.1) that might also prevent us from having to download everything from the remote as well.
The configuration for a repo has to be upgraded to include a option to define sparse checkouts and to define a list of names that we want to checkout.
Note here that this will eventually affect all commands like pull, init and so on, that needs to work with both adding and removing this. The bad part about this feature is that it adds in a ton of complexity in what repo states that we should both support and sort out how to move between. It might just be that if we go from a full checkout to sparse checkout that we give off an error and that the user has to run subgit delete first before we can do a sparse checkout.
One idea here is that we maybe have to implement a custom state tracking mechanism ourselfs that will track some certain states about the git repo that might not be so obvious or simpler or even possible to figure out and track from a git repo that we have checked out already. I would like to avoid this as it adds complexity, but if we need this to sort out tracking our repos, then so be it...
So we have a use-case where we want to be able to define either one or more folders and/or files that should be checked out from the git repo.
So for instance we have a repo that only contains folders in the root of the git repo and they can be used for different things and in different situations. So to avoid having to clone everything or to checkout everything, we want one of two things.
One solution is that we must clone the entire git repo down to local, but we use sparse-checkouts which is an older feature and we tell git only to checkout a list of names from the repo and maintain them.
Or the second solution is to use
git clone --filter from git 2.19 now works on GitHub (tested 2020-09-18, git 2.25.1)
that might also prevent us from having to download everything from the remote as well.The configuration for a repo has to be upgraded to include a option to define sparse checkouts and to define a list of names that we want to checkout.
Note here that this will eventually affect all commands like pull, init and so on, that needs to work with both adding and removing this. The bad part about this feature is that it adds in a ton of complexity in what repo states that we should both support and sort out how to move between. It might just be that if we go from a full checkout to sparse checkout that we give off an error and that the user has to run
subgit delete
first before we can do a sparse checkout.One idea here is that we maybe have to implement a custom state tracking mechanism ourselfs that will track some certain states about the git repo that might not be so obvious or simpler or even possible to figure out and track from a git repo that we have checked out already. I would like to avoid this as it adds complexity, but if we need this to sort out tracking our repos, then so be it...
Source material for this feature and examples how sparse checkouts work can be found here https://stackoverflow.com/questions/180052/checkout-subdirectories-in-git
The text was updated successfully, but these errors were encountered: