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

Re: odd behavior with git-rebase

From
Jeff King <peff@peff.net>
Date
Mar 26, 2012, 19:56 UTC
Message-ID
<20120326195619.GB13098@sigill.intra.peff.net>
In-Reply-To
<CABURp0qeJEwELpg_YKxn9Ghb6EMphrwwfueM2XCqua3X_dacdA@mail.gmail.com>
On Mon, Mar 26, 2012 at 02:31:05PM -0400, Phil Hord wrote:
Show 22 quoted lines
> Coincidentally I ran into this same behavior this week.  But what
> bothered me about it was the messages git gave me.  The empty commit
> gave me cherry-pick hints instead of rebase ones, including advising
> me to "use 'git reset'" to resolve the problem if I don't want this
> commit after all.
> 
> $ git rebase -i HEAD~10
> ...
> The previous cherry-pick is now empty, possibly due to conflict resolution.
> If you wish to commit it anyway, use:
> 
>     git commit --allow-empty
> 
> Otherwise, please use 'git reset'
> # Not currently on any branch.
> nothing to commit (working directory clean)
> Could not apply d513504... Some commit message
> 
> 
> I'm not sure if this is the norm or if it's a result of some other
> things I did in this sequence.  But I've seen it several times now.
> I've only tested it on 1.7.10 versions, including RC2.
This is easily reproducible on a simple test case:
  commit() {
    echo $1 >$1 && git add $1 && git commit -m $1 && git tag $1
  }
  git init repo &&
  cd repo &&
  commit one &&
  commit two &&
  git commit --allow-empty -m empty &&
  commit three &&
  git checkout -b fork one &&
  commit four &&
  git rebase -i fork master
  git --no-pager log --oneline

(this is the same test case I used without "-i" to check the rebase skipping behavior).

I agree the mention of cherry-pick is a little confusing. I think the advice to use "git commit --allow-empty" is still the right thing (although better still would be to recognize that the commit was empty in the first place and not stop at all). I think the message is showing the fact that "rebase -i" is cobbled together from other pieces. I wonder if the sequencer work would make this a little smoother (I confess I have not paid much attention to what is happening in that area).

-Peff
Previous: Phil HordNext: Junio C Hamano
Message 4 of 17 in “odd behavior with git-rebase”
  1. Neil HormanMar 23, 2012
  2. Jeff KingMar 23, 2012
  3. Phil HordMar 26, 2012
  4. Jeff KingMar 26, 2012
  5. Junio C HamanoMar 23, 2012
  6. Neil HormanMar 24, 2012
  7. Junio C HamanoMar 26, 2012
  8. Neil HormanMar 26, 2012
  9. Neal KreitzingerMar 26, 2012
  10. Phil HordMar 26, 2012
  11. Phil HordMar 26, 2012
  12. Neil HormanMar 26, 2012
  13. Jay SoffianMar 27, 2012
  14. Neal KreitzingerMar 26, 2012
  15. Neil HormanMar 26, 2012
  16. Phil HordMar 28, 2012
  17. Junio C HamanoMar 28, 2012

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.