On Jun 10, 3:21 am, Konstantin Khomoutov <khomou...@gmail.com> wrote:
> On Jun 10, 2:13 am, Daniel Zajic <dza...@yahoo.com> wrote:
>
> > Actually, I did do a "-f" push. If I don't, it complains in the usual way 
> > that it's not a fast-forward.
>
> > Thanks for the explanation about branch behavior, but it must not be 
> > impossible because it happened to me. I was able to push a branch from a 
> > completely new repository (~10MB) with no history onto one with a year of 
> > history (~155MB) and Heroku is showing a repository size of 165MB.
>
> > I did several tests using a local repository, with all kinds of pushes, 
> > prunes, etc. and I just can't find a way to reduce the size of the 
> > repository itself.
>
> Ah, that might be completely another story!
> For performance reasons, Git uses some sort of "garbage collection":
> it does not track which objects became unreferenced ("loose" in Git
> speak) due to execution of a command, and normally they remain in the
> database; to actually nuke these objects you have to run `git gc`.
> Until this, even if you replace a branch worthy of 1Gb objects with
> another one with only 1k of data, this 1Gb won't go away immediately.
>
> In fact, that was not the whole truth -- Git does check for loose
> objects after certain operations, and runs garbage collection if
> certain expiration criteria are met. But while this is configurable, I
> doubt you can force compaction from the client's side. Refer to [1]
> for more info.
> Possibly you could contact the administration of that service and ask
> them to explain their policy on garbage collection.
>
> In any case, I think you can be sure that your replaced data
> eventually will go away. So any urgent means are only worth applying
> if you have rather tight space restrictions on that service and
> pushing new data will surely hit them. In this case asking the service
> admins for support is a good idea, I think.
>
> > (Sorry about the top-posting. I'm new to this. This time I replied from my 
> > email client, so I'll see what happens.)
>
> Well, the software is usually only responsible for placing your text
> cursor either above or below the quoted text, nothing more. ;-)
> If you're using the google web interface (like I do), just move the
> cursor down and place your text under what quoted text you're
> logically replying to.
> You can get a good idea about this stuff from [2].
>
> 1.http://www.kernel.org/pub/software/scm/git/docs/git-gc.html
> 2.http://en.wikipedia.org/wiki/Posting_style

Thanks so much for taking the time to help me out. I hope this info
will help someone else out there, too.

I put in a support ticket with Heroku to see what useful information
they can give me about this issue (haven't heard back yet, but I'll
post their reply if/when they reply).

When I originally posted this question, I wasn't expecting to get such
a complicated answer. My problem on Heroku isn't with space concerns,
it's with trying to create a "bundle" (how they package up an app for
backup/transfer) that's smaller and easier to work with. 90% of our
repository's size is taken up by video files that were added and
removed early in its history. Basically there's a single commit that I
want to delete from the history, but it seems that even if I did that
(using filter-branch?) I won't get the outcome I'm trying to achieve
since I can't remotely garbage collect the Heroku repositories.

As far as using filter-branch, is there a simple way to delete a
single commit from history? I can't seem to wrap my head around what
filter-branch does or how it works. My best guess is that I'd use the
index-filter and unstage the files from that commit using "git rm --
cached". Is that right?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to