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.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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.
Oh, gotcha.