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

Add support for git shallow clones #3449

Closed
sbuzonas opened this issue Nov 21, 2014 · 11 comments
Closed

Add support for git shallow clones #3449

sbuzonas opened this issue Nov 21, 2014 · 11 comments
Labels
Milestone

Comments

@sbuzonas
Copy link
Contributor

When working with a large repository it would be nice to opt for a clone depth of 1 to still leverage git to patch dependencies for a project

@stof
Copy link
Contributor

stof commented Nov 21, 2014

the issue with a clone depth of 1 is that the locked commit may not be the latest commit of the repo. If the depth is not high enough to reach the locked commit, the installation will not work. And there is no way to find a value of depth working everywhere (it is easy to create a case requiring more than this value: just add more commit after the locked one in the repo)

@sbuzonas
Copy link
Contributor Author

A similar state to a shallow clone can be to git init, set remote, fetch desired sha.

@GromNaN
Copy link
Contributor

GromNaN commented Feb 23, 2015

Interesting idea @slbmeh. That would avoid limitations of shallow clones. Do you know the command to run to fetch only the desired commit ?

@sbuzonas
Copy link
Contributor Author

@GromNaN you can fetch any treeish object so just fetch the hash directly

@sbuzonas
Copy link
Contributor Author

actually, it doesn't appear to work like that anymore... i'll do further investigation, i was sure it worked for me like that git 1.6 era or so... there's a way to do it with the plumbing rather than the porcelain commands

Seldaek added a commit to Seldaek/composer that referenced this issue Feb 25, 2016
@Seldaek
Copy link
Member

Seldaek commented Feb 25, 2016

Please check #4961

@shqear93
Copy link

shqear93 commented Sep 3, 2020

any updates on this?

@Seldaek
Copy link
Member

Seldaek commented Oct 26, 2020

I think this isn't as needed anymore now that we clone from the cache dir, so we do local clones which are pretty fast.

@Seldaek Seldaek closed this as completed Oct 26, 2020
@hetii
Copy link

hetii commented Mar 4, 2021

This issue should be reopened. For CI/CD purpose or docker/kubernetes world where we start always from clean scratch there is no shared cache and for more complex project it's a waste of time to get all full repositories instead what is needed.

@ondrejmirtes
Copy link
Contributor

@hetii Wouldn’t your problem be solved with --prefer-dist?

@hawkeyetwolf
Copy link

hawkeyetwolf commented Jun 29, 2021

@ondrejmirtes yes indeed --prefer-dist should do it, but in my case the private packagist wasn't making the dist output available. I'm still working on that, but here's some thoughts for others:

If your private packagist isn't building dist output, see docs here.

If your private packagist is mirroring a private GitHub (or BitBucket?) instance, you may just need to edit your private packagist's satis.json and change the repository type from vcs to github (or git-bitbucket) to force Composer into making dist available from those services. You may need to clear your composer cache for this to start working. Details here.

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

No branches or pull requests

8 participants