Git: "Re-targeting" origin/master and origin/head to current branch

[Pack34]

I'm fairly new to some of the additional features in Git regarding branching and merging.

What I've done was that I started developing my firmware linearly but at a certain point I felt that I was going down the wrong "rabbit hole". So I went back a series of commits, started and branch and continued on from there. This new branch is what I want to stick with. It's much cleaner and works better.

What's the best way to resolve this? I'm using SourceTree and I just want to change the commit that origin/master and origin/HEAD point to. I would think that merging isn't what I want to do since I want to discard all changes in that branch, but hopefully keep it there for reference.

I could just continue along and ignore it, but I really want to start another branch at this point to do some refactoring of some of it.

Does anyone here have suggestions for the proper workflow for this?

[Jeroen3]

Git is designed to not lose commits.
You can however try to just rename the master branch and do a new clone.

Make a backup of your remote and local and start playing around. Learning in the process.
Much better than simply running some lines found online if you ask me.

[c4757p]

Just to confirm: this is what you've done:

Start working from point 5:

Code: [Select]

1 ... 2 ... 3 ... 4 ... (5) ... 6 ... 7 ... 8

Pull 5-8 off into a branch:

Code: [Select]

1 ... 2 ... 3 ... 4 ... 5 ... 6 ... 7 ... 8     (master)
                  \ ... 5 ... 6 ... 7 ... 8    (work)

And now you want master to look like this:

Code: [Select]

1 ... 2 ... 3 ... 4      (master)
                  \ ... 5 ... 6 ... 7 ... 8    (work)

If that's so, here's how you can do it locally (read disclaimer below!!)

1. Switch branch to master: git checkout master
2. Reset master to the state in commit 4: git reset --hard 4 (where 4 is the actual commit ID of commit "4")

DIsclaimer:
This deletes commits! You should generally never do this on a remote repository (though it's fine to do locally). To make origin/master reflect your local master, you'll have to do git push -f, which you've probably heard a million times is a Bad Idea. It'll piss off any collaborators you have royally.

But if it's your own repository and nobody else is sharing it with you, you could consider doing that. It's reversible as long as you don't run git gc haphazardly (just git reset --hard back to the original state, you can use git reflog to help you find its ID)

SECOND disclaimer:
Only do this if I'm right about the assumptions I've listed!

[Pack34]

The first two are correct. What I want to try make happen is to make the (work) branch the (master) branch without losing those commits.

I could keep working as-is but I feel that the current state of the commit tree looks confusing. because the (master) branch is supposed to be that.

[c4757p]

I might not be understanding you completely. So, you have this:

Code: [Select]

1 ... 2 ... 3 ... 4 ... 5 ... 6 ... 7 ... 8     (master)
                  \ ... 5 ... 6 ... 7 ... 8    (work)

And you want this?

Code: [Select]

1 ... 2 ... 3 ... 4 ... 5 ... 6 ... 7 ... 8     (master)

If the 'work' branch is local, just delete it. Otherwise just abandon it. Though personally, in the situation I think you're in, I'd rather keep working on 'work' until that bit is done, then merge it back into master. That's the whole idea behind feature branches, really...

[mich41]

I think this should create "old_garbage" branch pointing to the current "master" (if you want to save it):

Code: [Select]

git checkout -b old_garbage masterand this should re-point "master" to the current "work":

Code: [Select]

git checkout master
git reset --hard work
If you don't feel confident, run this on a copy of your source directory and check if everything went as expected. You may also want to consult the built-in help before using advice from random dudes on the 'net:

Code: [Select]

git help checkout
git help reset
Since you said that currently "master" has commits which don't exist in "work" and we are removing these commits from "master", you'll need to use "-f" the next time you push to your remote repo. And probably anybody pulling later from there will need something similar to force removal of "old_garbage" commits from "master" in their local repo.

[Sal Ammoniac]

I think he wants this:

Code: [Select]

1 ... 2 ... 3 ... 4     
                  \ ... 5 ... 6 ... 7 ... 8    (master)