Skip to content

re: Hack or maybe not: "Deleting" master when it gets too big VIEW POST


I don't understand why this would do anything at all. my-branch-name is still going to have all the history of master in it, and now things are just that bit more confusing for new people starting on the project. And it doesn't delete master either locally or remotely. Are you sure this isn't a joke?
If you want to clean stuff up you can always squash some commits and run git gc, I guess, but unless your repo contains some seriously bonkers history it's probably not going to be an issue.


I assume they decide to keep all the history up til that point... or methodically rewrite it

I think they meant to make a copy/alternate branch, push that, and deploy that going forward?


If the problem is really with a big history... I guess it can be solved cloning the repo with an specific deep. The parameter is --deep. For example:

git clone --deep=100


No. He means not checking out the master branch locally, just to use it as base to checkout your branch.

You can checkout your new branch directly from the remote ("origin" in this case).

The difference is that, when you checkout master locally then git build a working tree for it.

In order to understand it correctly, you need to keep in mind that you can't work in all of the branches.

Given that git stores the changes differentially, when you checkout a branch it needs to calculate the complete state of the files and make the needed changes to you local files to reach those changes.

I guess git calculates the commits it need to revert from your branch in order to reach merge base (the oldest common commit from both branches) and then it starts to apply the ones from the other branch.

That would trigger a lot of modifications for the local files and make take a long time specially if the files are big or there is a big amount of them in master.

That's my guess. That the problem is not so much with the history but with the amount of files.

code of conduct - report abuse