git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Confusion with git rebase -i

From
JHJean-Luc Herren <jlh@gmx.ch>
Date
Nov 24, 2008, 23:02 UTC
Message-ID
<492B326D.1050901@gmx.ch>
Hi list!

I often edit recent commits I haven't pushed out yet using "git rebase -i HEAD~5". And it's very helpful that whenever "git rebase" stops, it tells me what to do next. So normally it stops and tells me that I can now ammend the commit and then run "git rebase --continue", or if a conflict happens, it tells to fix that, "git add", "git rebase --continue". But I stumbled over a situation where doing what it says doesn't do what I want.

Let's say my HEAD commit is fine, but I want to edit HEAD~1 and HEAD~2, so I run "git rebase -i HEAD~3" and change 'pick' to 'edit' on the two lines I'm interested in. It stops after the first commit, letting me amend it and then I do "git rebase --continue". Unfortunately my fix to the first commit conflicts with the second commit, and I get this:

    Auto-merged filename
    CONFLICT (content): Merge conflict in filename
    Automatic cherry-pick failed.  After resolving the conflicts,
    mark the corrected paths with 'git add <paths>', and
    run 'git rebase --continue'
    Could not apply abcdefa... Commit message

Reading this message, I understand this isn't yet my chance to amend the second commit, this is merely a rebase conflict I need to fix before I can proceed. So I do what it says and fix only the conflict and do "git add" and "git rebase --continue", but then to my surprise I now won't get a chance to edit the second commit.

What I have to do instead in that situation, is to resolve the conflict *and also* add my fix to the second commit, and then remember to do "git add" and "git commit" *without the --amend*. And then finally "git rebase --continue". But it doesn't tell me any of that...

I don't know if the message above is wrong, or if there's a bug that just prevents it to stop again after a conflict of a commit that has been marked "edit". Though stopping twice (once to resolve conflict, once to amend the commit) at almost the same place can be just as confusing, so fixing the conflict *and* introduce my change to the commit at once is fine, but then it should say so, or I'll be confused.

Or am I missing something?  Using git 1.6.0.4.

Thanks, jlh

Message 1 of 1 in “Confusion with git rebase -i”
  1. Jean-Luc HerrenNov 24, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.