Discussion on: Hack or maybe not: "Deleting" master when it gets too big

[JavaScript Joel]

For those of you that are confused, master is not deleted on the remote repo. It is only deleted on the local repo.

If all your merging happens on the remote repo, you don't need master locally. You can fetch and then create your feature branch from origin/master.

I'm not sure the benefits of this because I don't do this myself. You still need to update your local repo with a fetch. So I am doubtful of the savings.

Not endorsing, just offering an explanation.

[Jen Chan]

Ooh thanks for identifying that only the local is deleted.

So this was my thought process: I thought they were pulling from a forked repo. I also thought they meant checkout master as my-new-branch, delete master locally AND remotely, and push my-new-branch as the authoritative new master

It seems weird not to keep previous work around for future reference. I suppose they wanted to reduce redundancy of branches or repo files at that point. My mind likes to makeup stories

[JavaScript Joel]

The work is always there in the.git folder. You just don't have the "branch".

But once you do git checkout -b my-new-branch origin/master, you'll have an identical copy of origib/master it'll just be called my-new-branch locally.

So when you build your future with, it's built it the latest files.

[JavaScript Joel]

I often need to be able to refer back the canonical "this worked" version, and the easiest and most reliable way to do that is to keep a copy locally.

The way git fetch works, you always have a local copy.

When you do this...

git fetch
git checkout -b my-new-branch origin/master

... Your branch my-new-branch is identical to origin/master.

So at any time you can always get that "this worked" version.

[JavaScript Joel]

No point wasting extra bandwidth to pull the entire thing down from scratch each time.

The whole thing is pulled down during git fetch.

Otherwise there is no way you could create a new branch off of it.

This can be confirmed by disconnecting from the internet during the internet during the git checkout stage or by doing a git branch -a to see all available branches.

There is no avoiding pulling the whole master branch.

[JavaScript Joel]

You pull the entire thing down the first time with git fetch, and then the incremental changes later with a basic git pull.

git pull and git fetch will use the same bandwidth. The difference between the two is git pull will also perform a merge. But you could do a git fetch and then a merge to achieve the same results of a pull.

you'll still saving yourself a step by not deleting master off your local copy every time.

The method laid out by OP would only require deleting the local version of master one time, not every time.

But because both pull and fetch get all files. There isn't much saved by performing the process described in the original tweets.

[JavaScript Joel]

don't create extra work for yourself by deleting it (yes, locally) when you're only going to need it again.

The main point of OP's post was that you can delete the master branch locally because using the process laid out above, you would never need a local master branch again.

There is no extra work. It is actually less work. You would only need to run 2 commands instead of 3 and with any pull, there is the possibility of merge conflicts.

normal method

git checkout master
git pull # possible merge conflicts here
git checkout -b my-new-branch

OP's method

git fetch
git checkout -b my-new-branch origin/master