Git Mailing List Archive on
 help / color / Atom feed
From: Neil Horman <>
To: Junio C Hamano <>
Subject: Re: odd behavior with git-rebase
Date: Sat, 24 Mar 2012 12:55:36 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Mar 23, 2012 at 01:33:30PM -0700, Junio C Hamano wrote:
> Neil Horman <> writes:
> > I know that git cherry-pick allows for picking of empty commits, and it appears
> > the rebase script uses cherry-picking significantly, so I'm not sure why this
> > isn't working, or if its explicitly prevented from working for some reason.
> The primary purpose of "rebase" is (or at least was when it was conceived)
> to clean up the existing history, and a part of the cleaning up is not to
I can understand that, although IMHO it seems equally usefull as a tool for
simply doing what its name implies, moving a history to a new starting point,
e.g. to plainly rebase it.  Thats the use that I have for it anyway.

> replay a patch that ends up being empty.  Even though we try to omit an
> already applied patch by using "git cherry" internally when choosing which
> commits to replay, a commit that by itself is *not* empty could end up
> being empty when a similar change has already been made to the updated
> base, and we do want to omit them.
Is there a way to differentiate a commit that is made empty as the result of a
previous patch in the rebase, and a commit that is simply empty?

> A commit that is empty (i.e. --allow-empty) by itself was a much later
> invention than the basic rebase logic, and the rebase may want to be
> updated to special case it, but as the default behaviour it is doing the
> right thing by not letting an empty commit into the cleaned up history.
I agree, I think perhaps adding an --allow-empty option to the rebase logic, so
that empty commits (or perhaps just initially empty, as opposed to commits made
empty) would be very beneficial.  

Thanks all, I'll start trying to pick through the rebase logic this week.



  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
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 [this message]
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