----- Original Message ----- 
  From: Xi Shen 
  To: git-users@googlegroups.com 
  Sent: Monday, February 22, 2016 12:23 AM
  Subject: Re: [git-users] git repo with sparseCheckout still pushes everything 
to remote


  Thanks Philip. I guess I will just import those code the old fashion 
way...copy/paste :)

Xi,
Maybe we are talking past each other. My comments were about the 'push' step, 
not about any step that copies and then pastes locally.

Git has many options and capabilities. Perhaps if you draw a diagram (ascii 
text?) it may help.

One possible option (I'm guessing as to your aim) is the use the idea of 
--orphan branches, which are the same as having two 'repos', with independent 
roots, in the same .git repository. So you clone two repos into one. Or start 
one repo and clone another into it.

At that point you can then checkout files, or cherry pick commits from one 
independent line of development to the other (exactly which side you call the 
'orphan' is a personal choice). 


Then when you want to push to your new upstream, you simply select (via the 
refspec) which branches you want pushed, so that just the trimmed back 
development is pushed.

  On Sun, Feb 21, 2016 at 9:54 PM Philip Oakley <philipoak...@iee.org> wrote:

      ----- Original Message ----- 
      From: Xi Shen 
      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 
git-users+unsubscr...@googlegroups.com.
    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 git-users+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

-- 
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to