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

Re: Confusing error message in rebase when commit becomes empty

From
Phil Hord <phil.hord@gmail.com>
Date
Jun 11, 2014, 19:04 UTC
Message-ID
<CABURp0q1c+75VzMfttDWVXhTFma3g=Tj938J_9i9xhG1yuMpdQ@mail.gmail.com>
In-Reply-To
<alpine.DEB.2.00.1406111854180.21431@ds9.cixit.se>
On Wed, Jun 11, 2014 at 1:57 PM, Peter Krefting <peter@softwolves.pp.se> wrote:
Show 14 quoted lines
> Phil Hord:
>
>
>> What does it mean when you say it worked as expected?  Did it leave
>> the empty commit, omit the empty commit, or leave some un-squashed
>> commit?
>
>
> Actually, it did not work as expected I noted afterward, it just dropped the
> reversion commit, and did not squash the next commit into it as I had asked,
> so from three commits, "change", "revert", "new-change" I had two, "change",
> "new-change" with the end result being the same (i.e., instead of squashing
> all three into one "new-change", I had "change" and "revert" +
> "new-change").

Did you have a series of three commits being squashed in your to-do list? I mean, did you have a list like this:

   pick ...  do foo
   squash ...  revert "do foo"
   squash ...  What I really meant to do.

I suppose the rebase stopped after the first squash failed due to the emptiness of the proposed result. Then rebase --continue proceeded, having decided that you were finished with the 'revert' commit. Then ... I would expect the next commit would actually be squashed, but I can only speculate at the reasons it might have decided not to after your continue.

This actually sounds like another case of a bug I reported a few weeks ago[1] and which Fabian Ruch was kindly investigating[2] and trying to fix. I don't think his fix would have helped in this case, but I do think it is worthy of consideration for that same patch series.

Show 6 quoted lines
>> It's not clear to me what --continue _should_ do in this case, but it does
>> seem like the two options here should be
>
> I sort of expect a squashed commit of "change" + "revert" to be an empty
> commit, and of "change" + "revert" + "new-change" to be a commit of
> "new-change".

Yes, but empty commits are discouraged on some projects. If you want your "change + revert = empty" commit to appear after the squash, I would expect you would want to use --keep-empty on your inital rebase command. But I'm not sure that will do what you expected either; it may only keep previously-empty commits during the rebase.

[1] http://article.gmane.org/gmane.comp.version-control.git/245688 [2] http://www.mail-archive.com/git%40vger.kernel.org/msg51703.html

Previous: Peter KreftingNext: Peter Krefting
Message 4 of 7 in “Confusing error message in rebase when commit becomes empty”
  1. Peter KreftingJun 11, 2014
  2. Phil HordJun 11, 2014
  3. Peter KreftingJun 11, 2014
  4. Phil HordJun 11, 2014
  5. Peter KreftingJun 13, 2014
  6. Jeff KingJun 13, 2014
  7. Jeff KingJun 13, 2014

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.