Thanks Philip. I guess I will just import those code the old fashion way...copy/paste :)
On Sun, Feb 21, 2016 at 9:54 PM Philip Oakley <[email protected]> wrote: > ----- Original Message ----- > *From:* Xi Shen <[email protected]> > I cloned part of a git repo from *repo1* > > cd my-repo > git init > git remote add -f upstream ... > > Then I set up sparseCheckout, and the local directory only contains the > directory I want. > Then I added another remote > > git remote add new-repo ... > git push -u new-repo master > > Even though the local only contains the files I want, the last command > still pushes everythin from upstream to my new-repo. > > How can I make git only push what is at my local repo? > > > Thanks, > David > > I don't think you can limit what is pushed upstream (other than 'Shallow > clone' depth limits). It must be whole commits. > > The sparse checkout is designed for those cases where the repository is > "extensive", but the user's working space is 'limited', so that only part > of the relevant commit is expanded (checked out) into the users > memory/filesystem/workspace. > > This can be useful if there are large binary blobs that are not relevant > to the coding. However once you have made your changes to the code parts > and prepared a new commit, those unchanged blobs are still referenced as > being part of the commit structure, so it can ALL sent to the remote. > > In the case where the remote is the upstream the repo was fetched from, > then the upstream already has that big blob, so it doesn't need sending > again, keeping the network bandwidth low. If you are pushing to a new > remote then the big blob will need to be sent as a full copy. > > The idea of Narrow Clone, supported both locally and at some servers, is > a longe term ideal of mine, but I don't think it finds much favour in the > upstream community (confusion between openess and bandwidth, compared to > restrictive (security) and access approaches). Note that sub-modules are > already a type of Narrow Clone, but some find them difficult to work with > as they try to be too many things to too many people and don't satisfy > anybody that well. > > -- > Philip > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/buQONZgIio8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Regards, David -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
