Git Mailing List Archive on
 help / color / Atom feed
From: Jeff King <>
To: Neil Horman <>
Subject: Re: odd behavior with git-rebase
Date: Fri, 23 Mar 2012 15:54:56 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Mar 23, 2012 at 02:52:05PM -0400, Neil Horman wrote:

> 	I hit a strange problem with git rebase and I can't quite decide if its
> a design point of the rebase command, or if its happening in error.  When doing
> upstream backports of various kernel components I occasionally run accross
> commits that, for whatever reason, I don't want/need or can't backport.  When
> that happens, I insert an empty commit in my history noting the upstream commit
> hash and the reasoning behind why I skipped it (I use git commit -c <hash>
> --allow-empty).  If I later rebase this branch, I note that all my empty commits
> fail indicating the commit cannot be applied.  I can of course do another git
> commit --allow-empty -c <hash>; git rebase --continue, and everything is fine,
> but I'd rather it just take the empty commit in the rebase if possible.

I think it is even odder than that. If you use plain rebase, the empty
commits are silently omitted. If you do an interactive rebase, you get
the "could not apply" message (and just doing a "continue" creates some
funny error messages and ends up omitting the commit).

I think both of these are bugs. In the first case, the empty commit
appears to be already applied, because it does nothing. But if somebody
bothered to create an empty commit in the first place, they probably
want to keep it, and we should special-case it.

As you've probably guessed, empty commits are not all that common, and I
think this area of git is not well-tested.


  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23 18:52 Neil Horman
2012-03-23 19:54 ` Jeff King [this message]
2012-03-26 18:31   ` Phil Hord
2012-03-26 19:56     ` Jeff King
2012-03-23 20:33 ` Junio C Hamano
2012-03-24 16:55   ` Neil Horman
2012-03-26 17:12     ` Junio C Hamano
2012-03-26 17:20       ` Neil Horman
2012-03-26 21:53         ` Neal Kreitzinger
2012-03-26 22:53           ` Phil Hord
     [not found]             ` <>
2012-03-28  6:58               ` Phil Hord
2012-03-28 17:08               ` Junio C Hamano
2012-03-26 18:29       ` Phil Hord
2012-03-26 20:04         ` Neil Horman
2012-03-27  1:58         ` Jay Soffian
2012-03-26 15:27 ` Neal Kreitzinger
2012-03-26 17:18   ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone