0

After mangling a git rebase -i, I eventually got the code into the state I want.

$ git log
55c602ed1c (HEAD -> main) 
6c3fa102c2 (detached-branch) 
6ec87486d1 
89dd40a86a 
f6f4b6edb2 
77742d9d69 
32b67d2a01 
...

The commit 55c602ed1c is exactly correct.

However, when I now call git rebase -i 6c3fa102c2 I get unexpected editor content:

pick 77742d9d69
pick f6f4b6edb2
pick 89dd40a86a

# Rebase 6c3fa102c2..55c602ed1c onto 6c3fa102c2 (3 commands)
#
# Commands:
# ...

Of course I was expecting to see

pick 6c3fa102c2
pick 55c602ed1c

# Rebase 6c3fa102c2..55c602ed1c onto 6c3fa102c2 (3 commands)
#
# Commands:
# ...

Now I quit the editor without saving and get a message and errors:

Auto-merging ...
CONFLICT ... 
<more conflicts>

so I do git rebase --abort to get out of that, which leaves the branch in the correct state, but still unable to rebase.

How can I get back the normal rebasing function?

EDIT:
Removing reflog output, and removing the question, while adding new content and question.

$ git log --oneline --graph
*   55c602ed1c (HEAD -> main)
r|g\  
r|   * 6c3fa102c2 (detached-branch) 
r|   * 6ec87486d1
 *  g| 89dd40a86a
 *  g| f6f4b6edb2
 *  g| 77742d9d69 
r|g/  
* 32b67d2a01

The actual graph output is color coded red and green , so I prefixed |,/, and \ with a letter to indicate actual color.

For the record, the command used to create the final, good, commit 55c602ed1c were:

git checkout main
git merge detached-branch

and it required manual conflict resolution.

I have tried rebasing to the common ancestor 32b67d2a01, which is suggested in this answer to a similar question, but oddly neither the HEAD commit 55c602ed1c nor the common ancestor 32b67d2a01 appear in the list shown in the editor:

git rebase -i 32b67d2a01

pops up editor with

pick 77742d9d69 
pick f6f4b6edb2 
pick 89dd40a86a 
pick 6ec87486d1 
pick 6c3fa102c2

# Rebase 32b67d2a01..55c602ed1c onto 6ec87486d1 (5 commands)
#
# Commands:

Using a tilde as in the hint given by @eftshift0 (without understanding the principle behind it and not seeing it on the git man mage for rebase)

git rebase -i 32b67d2a01~

gives

pick 32b67d2a01
pick 77742d9d69 
pick f6f4b6edb2 
pick 89dd40a86a 
pick 6ec87486d1 
pick 6c3fa102c2

# Rebase db737eb68b..55c602ed1c onto 89dd40a86a (6 commands)
#
# Commands:

but still, the HEAD commit 55c602ed1c is not listed on the bottom. If I go ahead and do the rebase with that selection, 55c602ed1c is ignored and I am asked to resolve conflicts all over again, which obviously I don't want to do because 55c602ed1c is already merged and satisfactory.

The new question is how can I remove the commits between but not including HEAD and the common ancestor, while keeping HEAD (obviously)?

Craig Hicks
  • 2,199
  • 20
  • 35
  • `(detached-branch)` ... are you working from the detached HEAD state? – Tim Biegeleisen Apr 05 '23 at 07:17
  • In the course of getting back to where I wanted I was in detached head and from that created a branch "detached-head", then merged than back into main and resolved some conflicts manually. The criitcal point is - unlike other question I could find, I have the correct code already (finally) in branch "main". Now I just can't get `git rebase -i` to work correctly. – Craig Hicks Apr 05 '23 at 07:27
  • Note that rebasing over merge commits does probably not work as you think. – Tim Biegeleisen Apr 05 '23 at 07:28
  • That's interesting. In what way does it work - and why can it not work as I expect? – Craig Hicks Apr 05 '23 at 07:31
  • 1
    When you rebase over merge commits, you need to manually tell Git which parent you want to follow. – Tim Biegeleisen Apr 05 '23 at 07:31
  • Thanks for the advice, I've moved forward in understanding the problem and updated it - but still am unable to clean up - it won't let me keep the the already merged and satisfactory HEAD commit, at least not using `rebase -i `. – Craig Hicks Apr 05 '23 at 17:16

2 Answers2

1

I there there are a few things there. Let's solve the easy one.

You were expecting to see:

pick 6c3fa102c2
pick 55c602ed1c

That's not gonna happen. Well... only one part of it would happen, the second pick... but you will not get the first one because that is the commit you used as the base in the interactive call.... that commit is not rebased. If you had done git rebase -i 6c3fa102c2~, tnen you would see that commit show up in the list.

Then, the second one is a little trickier. I think 55c602ed1c is a merge commit (can you check using git log --oneline --graph?). One of the parents being 6c3fa102c2... so, git rebase -i 6c3fa102c2 will list the commits that are part of the other side of the merge commit (and given that 55c602ed1c is a merge commit and you did not use --rebase-merges, it doesn't show up in the list of commits to rebase).

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • `git rebase -i 6c3fa102c2` shows up in the editor with a line 'noop' and completes successfully. But I see you have written `git rebase -i 6c3fa102c2~`, what does the tilde mean? (Sorry I will offline for a while now). – Craig Hicks Apr 05 '23 at 08:05
  • 1
    That is not what you state in the question: _I get unexpected editor content_ then you list 3 picks, none of them is `6c3fa102c2`. Perhaps you are referring to another rebase attempt you tried? `~` means _the first parent of_. `6c3fa102c2~` is _the first parent of `6c3fa102c2`_. – eftshift0 Apr 05 '23 at 08:09
  • Sorry I meant 55c602ed1c produced "noop". – Craig Hicks Apr 05 '23 at 14:07
  • Thanks for the advice which I have followed as best I can, but am still unable to clean up. The question has been updated. – Craig Hicks Apr 05 '23 at 17:11
1

Here is an answer to the final question:

git reset --soft 32b67d2a01
git commit -m "everything past 32b67d2a01 in a single shot"

That should work, no conflict to resolve. You are losing (and rewriting) history, of course, but I think that is the ultimate goal, right?

eftshift0
  • 26,375
  • 3
  • 36
  • 60