Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 75475
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 10, 20262026-05-10T20:31:19+00:00 2026-05-10T20:31:19+00:00

We have a git project which has quite a big history. Specifically, early in

  • 0

We have a git project which has quite a big history.

Specifically, early in the project there were quite a lot of binary resource files in the project, these have now been removed as they’re effectively external resources.

However, the size of our repository is >200MB (the total checkout is currently ~20MB) due to having these files previously committed.

What we’d like to do is ‘collapse’ the history so that the repository appears to have been created from a later revision than it was. For example

1-----2-----3-----4-----+---+---+                    \       /                     +-----+---+---+ 
  1. Repository created
  2. Large set of binary files added
  3. Large set of binary files removed
  4. New intended ‘start’ of repository

So effectively we want to lose the project history before a certain point. At this point there is only one branch, so there’s no complication with trying to deal with multiple start points etc. However we don’t want to lose all of the history and start a new repository with the current version.

Is this possible, or are we doomed to have a bloated repository forever?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. 2026-05-10T20:31:20+00:00Added an answer on May 10, 2026 at 8:31 pm

    You can remove the binary bloat and keep the rest of your history. Git allows you to reorder and ‘squash’ prior commits, so you can combine just the commits that add and remove your big binary files. If the adds were all done in one commit and the removals in another, this will be much easier than dealing with each file.

    $ git log --stat       # list all commits and commit messages  

    Search this for the commits that add and delete your binary files and note their SHA1s, say 2bcdef and 3cdef3.

    Then to edit the repo’s history, use rebase -i command with its interactive option, starting with the parent of the commit where you added your binaries. It will launch your $EDITOR and you’ll see a list of commits starting with 2bcdef:

    $ git rebase -i 2bcdef^    # generate a pick list of all commits starting with 2bcdef # Rebasing zzzzzz onto yyyyyyy  #  # Commands:  #  pick = use commit  #  edit = use commit, but stop for amending  #  squash = use commit, but meld into previous commit  #  # If you remove a line here THAT COMMIT WILL BE LOST. # pick 2bcdef   Add binary files and other edits pick xxxxxx   Another change   .   . pick 3cdef3   Remove binary files; link to them as external resources   .   . 

    Insert squash 3cdef3 as the second line and remove the line which says pick 3cdef3 from the list. You now have a list of actions for the interactive rebase which will combine the commits which add and delete your binaries into one commit whose diff is just any other changes in those commits. Then it will reapply all of the subsequent commits in order, when you tell it to complete:

    $ git rebase --continue 

    This will take a minute or two.
    You now have a repo that no longer has the binaries coming or going. But they will still take up space because, by default, Git keeps changes around for 30 days before they can be garbage-collected, so that you can change your mind. If you want to remove them now:

    $ git reflog expire --expire=1.minute refs/heads/master       #all deletions up to 1 minute  ago available to be garbage-collected $ git fsck --unreachable      # lists all the blobs(files) that will be garbage-collected $ git prune $ git gc                       

    Now you’ve removed the bloat but kept the rest of your history.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have a git directory which contains the a whole bunch of files and
I have a git repository (covering more or less project history) and separate sources
I have a project in SVN which has a plugins folder. Several of the
I have a rails project deployed on heroku which has only a production environment.
There's an SVN open-source project which I have read-only access to, and I'd like
I have been using git to keep two copies of my project in sync,
I am using git for windows to manage a local project. I have two
I have a git repository which tracks an svn repository. I cloned it using
I have a git repository with multiple branches. How can I know which branches
I have a Git repository which contains a number of subdirectories. Now I have

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.