How can I update remote branches, after I make a series of commits from a Detached HEAD locally?

Question

The only reasonable way to explain what happened is with diagrams (commits are alphabeti-chronological)

Starting state:

C (master, HEAD, origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
|
B
|
A

Then I went back to A because I went in the wrong direction with B and C: git checkout A

C (master, origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
|
B
|
A (HEAD)

Now I make a string of new good changes:

E (HEAD)
|
D
|
| C (master, origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
| |
| B
| |
|/
A

Crap. Forgot I left my HEAD detached. Okay. Let's try this! git branch -f master E

E (master, HEAD)
|
D
|
| C (origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
| |
| B
| |
|/
A

Here is where I am now. I recognize that if I run git pull, I'm gonna pull in crappy changes from B and C. I am unsure what will happen if I try to git push.

Do I have to go to all remotes and do git revert and then get those new "revert" commits to be merged back in on here? Is that the way to go about it? Having extra merge-related commit clutter is okay, but I am hoping that there is a way to get out of this situation without leaving a mess.

I'd ideally like to keep the history of B and C in case I do want them back. I guess I need to make a branch to do that properly, but for now these changes are not important enough even to warrant the effort required to configure (and think of a name for) a branch for them.

I did some searching and find that git revert -m-something is likely appropriate, but I'm unsure how to apply it (i.e., I'm not sure how i can be sure that B and C are thrown out when merging). As you can see I have many remotes and would prefer a command I can safely and easily apply to all the remotes (or even more awesome maybe theres something I can list all the remotes to run it for).

Update:

I have now dug a slightly deeper hole:

I ran git push -f on all my remotes.

So, a fresh user would pull in this:

E (master, HEAD, origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
|
D
|
A

However I forgot about how I have stuff set up on ec2, where that server's bare repo has a post-receive hook which cd's to a local regular repo, and runs git pull from there. So I do have a virtual user who is pulling all the branches all the damn time.

For this repo it now looks like this, because this user has only one remote, origin, which is the same remote as ec2 from my macbook (all other diagrams):

E (origin/master, origin/HEAD)
|
D
|
| C (HEAD, master)
| |
| B
| |
|/
A

At this point I figured, okay I will just go and save B and C after all (and push them in later as a branch to remote and it should be safely propagatable):

E (origin/master, origin/HEAD)
|
D
|
| C (HEAD, saving-B-C, master)
| |
| B
| |
|/
A

But here's where I get stuck:

$ git branch -f master E
fatal: Cannot force update the current branch.

Help!

Are you the only one to use those remotes or have others pulled B and C already? — onionjake, Aug 02 '13 at 03:37
I am the only user but hopefully it can be made clear in any answers whether a particular approach will cause history inconsistency for other pullers. My guess is that to avoid such inconsistency (for any other coders who've pulled in master at this point) that it will be necessary to make commits which effectively *undo* B and C (and therefore I'll need to merge those ones back in as well? -- well what do I do about my newly split master?) Maybe I need to do this: new commit C.5 (parent C) undoes B and C; rebase D and E on top of C.5. — Steven Lu, Aug 02 '13 at 03:38
+1 for providing us with tons of detailed and clear information about your problem. It's very refreshing. It's not uncommon for people to just leave behind vague questions with no graphs and no commands, which usually results in a ton of back and forth asking for more details. — , Aug 02 '13 at 03:48
Thanks @Cupcake. I figured I wouldn't ever bother reading through a question with more incomplete information than this, and simply trying different suggestions and seeing what sticks (which is the only outcome that I can expect with a shoddy question) is not something I can afford to do with this particular project. — Steven Lu, Aug 02 '13 at 04:00
@StevenLu join me in a chat room to solve your problem? Actually, let me read what you have so far first. — , Aug 02 '13 at 04:16
Appreciate the offer. But I think I've got the problem licked. — Steven Lu, Aug 02 '13 at 04:21

score 1 · Accepted Answer · edited May 23 '17 at 11:45

1

This will solve the case when git push -f and git reset --hard origin/master are not an option (i.e. the problem before the update in the question).

Create a branch pointing at commit C:

git checkout -b temp origin/master

Then follow the instructions here to revert B and C.

So now your history looks like this:

E (master)
|
D (BC)' (temp, HEAD)
| |
| C (origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
| |
| B
| |
|/
A

Now you want to move commits D and E so they are after the revert. There are several ways to do this, one could be:

git checkout master
git rebase temp
git branch -d temp

Now your history looks like this:

E (master, HEAD)
|
D
|
(BC)'
|
C (origin/master, origin/HEAD, ec2/master, devserver/master, devserver/HEAD)
|
B
|
A

Which is safe to push to all of your remotes.

edited May 23 '17 at 11:45

Community

1
1

answered Aug 02 '13 at 03:47

onionjake

3,905
27
46

Thanks. `git push -f` was far too sexy for me to avoid (since I can get away with it). It's interesting: now B and C are really actually totally gone! Not too shabby – Steven Lu Aug 02 '13 at 03:56
Oh crap. Can you take a look at OP again? – Steven Lu Aug 02 '13 at 04:15
There, flushed it out to handle the case where a `git push -f` isn't an option. – onionjake Aug 02 '13 at 05:11

score 1 · Answer 2 · answered Aug 02 '13 at 04:19

1

Aha! I looked at the error message a second time, and interpreted it more literally. It then occurred to me that I just gotta hop off the rock I was standing on to move it.

git checkout saving-B-C
git branch -f master E

Success!

answered Aug 02 '13 at 04:19

Steven Lu

41,389
58
210
364

+1 for cleverly figuring out the answer yourself. Also, instead of using `branch -f` to force `master` to `E`, you could also checkout `master` and do a hard reset with `git reset --hard E`, which is more common. But please...do be careful with both commands. – Aug 02 '13 at 04:22
1

So far the track record has been at least 20 minutes of googling and SO-ing before I ever run either of those commands... I do find that it's not too easy to completely break or lose things so long as one commits prior to attempting anything adventurous. Also, each host *and* cloned repository serving as a full backup is very reassuring. – Steven Lu Aug 02 '13 at 04:25

How can I update remote branches, after I make a series of commits from a Detached HEAD locally?

2 Answers2