2

Here's what the commit history looked like before I mucked it up:

A B C [master]
     \
      D E F G H I [refactor]

Here's what my current commit history looks like:

A --------------- E B C F D [master branch]
 \
  B C D E F G H I [refactor branch]

Here's how I want it to look:

A B C D F G       [master branch]
           \
            E H I [refactor branch]

I didn't fully understand what the rebase command was going to do, so I now have a bit of a mess. This leaves me with two questions:

  1. Is there a way to easily undo the effects of the last rebase command you ran? (Since I'll probably screw up again.)

  2. What series of commands should I be using to get me where I want to be? I suspect I want to use some combination of rebase and cherry_pick, but don't want to mess things up any further.

Thank you for your time and help.

Ray

Rben
  • 489
  • 1
  • 7
  • 18

2 Answers2

2

There shouldn't be any need for cherry picking -- the result you want is a single branch that already seems to exist (refactor). EDIT: I just realised it's not exactly the same. I'll add a note about it in the end.

Note that your first diagram cannot really exist: you can't have the exact same commits in separate branches (you might have different commit hashes with same changes in them).

Also note that what you are doing is going to make master incompatible with any repositories you may have already pushed to -- rebasing master is usually not what you want if you've already shared master with others. Normally you would rebase the branch on top of master (and then merge branch into master).

Anyway, this should do what you asked for, assuming the commits in 'refactor' are the good ones:

git branch old-master master # just so you don't lose anything...
git checkout refactor
git branch -d master
# git rebase --interactive D # commit D is the one in refactor branch
git branch master G # commit G is the one in refactor branch

I've added the rebase command commented out the middle: it will be useful if you really want to reorder E, F and G as the diagrams seem to say. in the rebase editor you can reorder commits as you wish and git will try to do it -- but do you may need to fix things by hand when asked.

As far as "undoing a rebase" goes, that's possible but requires poking a bit deeper into git: see e.g. this answer and git reflog output.

Community
  • 1
  • 1
Jussi Kukkonen
  • 13,857
  • 1
  • 37
  • 54
  • You are right that the SHA1 hashes differ for the commits that seem to be shared between the two branches. They do appear to be identical in relevant content, though. – Rben Jan 28 '15 at 00:32
  • I'm going to give this a try. What could possibly go wrong? :) – Rben Jan 28 '15 at 00:37
  • It does seem that a **git rebase --undo** command might be a valuable addition. – Rben Jan 28 '15 at 00:44
0

It is difficult to know what is the best option to "undo" what you did. You should indicate how your branch look like after your rebase and what command you actually typed.

Assuming your initial state is :

A --------------- E B C F D [master branch]
 \
  B C D E F G H I [refactor branch]

And you want 

A E B C F D       [master branch]
           \
            B' C' D' F' E' H' I' [refactor branch]

Please note that B becomes B', C becomes C', etc.

Then you should do:

$ git rebase <upstream> <branch>

i.e.

$ git rebase master refactor

If you want to squash the commits B', C' etc into one commit, you can do so with the -i option with the rebase command so that you finally get:

A E B C F D [master branch] \ B" [refactor branch]

where B" is the resulting squash commit from B, C, etc Please look at the git rebase documentation

iclman
  • 1,218
  • 9
  • 21