3

I've packed commits using git rebase -i HEAD~5 After this operation I've noticed that one of them must be separated. I've tried to use interactive mode from this manual https://git-scm.com/docs/git-rebase#_splitting_commits

git rebase --interactive

But there is only

noop

# Rebase 0349ada..0349ada onto 0349ada (1 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

So i do not understand how to indicate commit for splitting

Mike
  • 43
  • 1
  • 5
  • 1
    I think this is really just a duplicate of https://stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits. Are you providing any arguments to your `git rebase --interactive` command? – larsks Sep 06 '17 at 16:23
  • git rebase --interactive – Mike Sep 06 '17 at 17:21

2 Answers2

3

You have two options.

You can set the commit you want to pick apart as edit, and then make changes at that point. Typically, you'd reset to before the commit, and then make the two commits you want:

$ git reset HEAD^
$ git add file1 file2 file3
$ git commit
$ git add file4 file5 file6
$ git commit
$ git rebase --continue

Of course, real world examples are unlikely to be commits with edits to separate files, but after you've done the git reset, you're at the point before the commit to be picked apart, but with the changes from that commit in your working directory. What you need to do to make the two commits you want depends on your situation.

The other option, is just to go back to before your first rebase, and do it again taking care not to make the same mistake. The commits from before the rebase won't be garbage collected right away, so you can simply reset to the relevant commit:

git reset --hard <hash of the HEAD commit before the rebase>

I say 'simply', but I realise that it's unlikely you made a note of the commit hash before you did the rebase. Fear not though, you can discover it using it reflog:

git reflog

This lists which commit was HEAD at each operation that was carried out. You should see a bunch of commits labelled as rebase -i, pick the commit hash from the commit before these.

Then you can just do your original rebase again, and make different choices.

SpoonMeiser
  • 19,918
  • 8
  • 50
  • 68
  • 1
    Use `git add -p` – o11c Sep 06 '17 at 16:31
  • +1. I would add: in my opinion, it usually makes the most sense to go back to the pre-rebase commits since otherwise you're trying to recreate information you've discarded. Note that if new changes have been made after the original rebase, those changes will need to be rebased onto the result of the new rebase (or, if things have gotten too far out of hand for that, they can be re-parented since the two rebases will end in commits with the same `TREE`). – Mark Adelsberger Sep 06 '17 at 19:39
  • that works in case if you haven't removed original branch. Otherwise you need to move into .git folder and look HEADS data into logs folder. – Mike Sep 09 '17 at 12:56
  • @Mike I don't think having removed the branch would make any difference - the commits probably aren't garbage collected yet, and should still show up in the reflog. – SpoonMeiser Sep 11 '17 at 09:00
1

You would need to perform certain steps

  1. Check the Reflog

    git reflog

It will show output like

some-sha HEAD@{4}: some message
some-sha HEAD@{5}: another message
some-sha HEAD@{6}: rebase -i (squash): Last commit message (after the temporary commit)
some-sha HEAD@{7}: rebase -i (squash): updating HEAD
some-sha HEAD@{8}: checkout: message some-sha

  1. Reset the rebase action. (Reset to the commit previous to the first rebase action)

    git reset --hard your-picked-sha-value

    or

    git reset --hard HEAD@{pickedValue}

  2. Rebase again

    git rebase -i HEAD~5
Shubham Khatri
  • 270,417
  • 55
  • 406
  • 400
  • reflog returns https://pastebin.com/E13HK90B . Using hard reset for this sha doesnt change anything. – Mike Sep 06 '17 at 17:34
  • That is strange, It shows the sha-ids properly for me – Shubham Khatri Sep 06 '17 at 19:01
  • @Mike is that the full reflog? That looks like you've been trying to rebase a single commit a bunch of times (all of which have resulted in no change). If you go back further, do you find reference to your original commits and the initial rebase? – SpoonMeiser Sep 07 '17 at 11:31