If I push straight to the other repo, it only pushes the 3 objects I'd expect (instead of 10,000+). So it looks like that is the problem, but I don't really understand why. >From my point of view, there should be no difference, but I clearly don't understand how it actually works. How does git decide what refs and/or objects are the same? For a bit of background, the reason I have 2 remotes is to try and avoid pushing to master. We work in a highly regulated industry, and our code needs to be reviewed before hitting the mainline. So I push to my fork and create a PR to the blessed repo, that way if I accidentally commit to master (I have form!) then I have an extra chance to catch it and don't have to back it out. The two repos started out the same though, the only differences should be the new work I have done. Is there any way I can continue to work like this, or do I have to choose between slow pushes and safety? On 23 March 2015 at 10:41, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Mon, Mar 23, 2015 at 5:35 PM, Graham Hay <grahamrhay@xxxxxxxxx> wrote: >> Hmm. I'm using a "private" fork of a repo, I pull from one and push to >> the other, e.g. >> >> git fetch foo >> git rebase foo/master >> git push --set-upstream origin bar >> >> It's quite possible my workflow is causing the problem, but I'm not >> sure what I could do differently. What do you mean by a "no-share >> remote"? > > I mean the refs (and associated objects) that are available on "foo" > may be not available on "bar" so when you push to "origin" you just > need to send more. That rebase could generate lots of new objects to > push out too, I think. > -- > Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html