From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Basin Ilya'" <basinilya@gmail.com>, <git@vger.kernel.org>
Subject: RE: pushing a delete-only commit consumes too much traffic
Date: Thu, 25 Jan 2018 20:56:09 -0500 [thread overview]
Message-ID: <000f01d39648$d918f6e0$8b4ae4a0$@nexbridge.com> (raw)
In-Reply-To: <79fd9c0b-3067-afce-1fcd-507b7c97889e@gmail.com>
So the point here is that the jars are still in the repository. They are deleted in your branch, but any objects depending on others (without a lot more information on your exact repository structure) may cause packed objects to be sent upstream. The delete is local to your branch, but the delete does not mean the objects are actually removed from your repository. To actually effect a removal, the objects would need to be no longer accessible, thus git gc would remove them permanently. That may be difficult depending on security on your upstream repository and what you are able to do there. So:
A--- B--- C
If A has no jars, B has the jars and has A as its parent, and C has no jars, but has B as its parent, then B is still accessible and the jars still exist in the repository but only not at the HEAD of your branch. Your tree may vary. How a push gets objects from your repository to your upstream depends on more information that I have but the point is that the jars still exist in a distributed sense. Your repository state and the upstream repository state do not need to be (and are likely not) identical.
> -----Original Message-----
> From: Basin Ilya [mailto:basinilya@gmail.com]
> Sent: January 25, 2018 10:08 AM
> To: Randall S. Becker <rsbecker@nexbridge.com>; git@vger.kernel.org
> Subject: Re: pushing a delete-only commit consumes too much traffic
>
> > Were the 60Mb of jars previously pushed in a commit that already existed
> on the upstream?
> yes
>
> > Was the delete an actual removal of history or did you commit with the jars
> deleted, then pushed?
> I committed with the jars deleted
>
> > Did you do a merge squash or delete branch to effect the removal.
> No
>
>
>
>
> On 25.01.2018 17:24, Randall S. Becker wrote:
> > On January 25, 2018 9:15 AM, Basin Ilya wrote:
> >
> >> I had a 60Mb worth of unneeded jar files in the project. I created a
> >> new branch and performed `git rm` on them. Now while I was pushing
> >> the change the counter of sent data reached 80Mb. Why is that?
> >
> > Can you provide more info? Were the 60Mb of jars previously pushed in a
> commit that already existed on the upstream? Was the delete an actual
> removal of history or did you commit with the jars deleted, then pushed? Did
> you do a merge squash or delete branch to effect the removal. More info
> please.
> >
> > Cheers,
> > Randall
> >
> > -- Brief whoami:
> > NonStop developer since approximately NonStop(211288444200000000)
> > UNIX developer since approximately 421664400
> > -- In my real life, I talk too much.
> >
> >
> >
prev parent reply other threads:[~2018-01-26 1:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 14:15 pushing a delete-only commit consumes too much traffic Basin Ilya
2018-01-25 14:24 ` Randall S. Becker
2018-01-25 15:07 ` Basin Ilya
2018-01-26 1:56 ` Randall S. Becker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000f01d39648$d918f6e0$8b4ae4a0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=basinilya@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).