Git Mailing List Archive on
 help / color / Atom feed
From: Phil Hord <>
To: Neal Kreitzinger <>
Cc: Neil Horman <>,
	Junio C Hamano <>,
Subject: Re: odd behavior with git-rebase
Date: Mon, 26 Mar 2012 18:53:32 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Mar 26, 2012 at 5:53 PM, Neal Kreitzinger
<> wrote:
> On 3/26/2012 12:20 PM, Neil Horman wrote:
>> On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:
>>> Neil Horman<>  writes:
>>>> 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.
>>> Yeah, that probably may make sense.
>> Ok, cool, I'll have a patch in a few days, thanks!
> IMO, it seems like --allow-empty is an appropriate patch for git-rebase
> (non-interactive), and that git-rebase -i would need a command like "k"eep
> to distinguish which empty commits are not to be discarded and which empty
> commits are ok to discard automatically.  git-rebase -i should allow
> explicit control on a commit by commit basis as opposed to blanket rules
> like "discard all empty commits" or "keep all empty commits" that apply to
> all commits in the rebase-to-do list based on a single cli option.

But I don't want a 'keep-even-if-empty' option in interactive.  I want
a 'purge-if-empty' option instead.  But I don't want to be bothered
with telling git this for every commit.

I recently had a long-running branch to clean up.  It was polluted
with commits pulled in by a ham-fisted  developer collaborating on
this and another branch.  He's not quite got the git mental model yet
and he had lots of commits doing things and then undoing them later
on.  Rebase scares him.

So I did a lot of interactive rebasing on this branch to reorder the
"good" change commits to the front of the line where they could be
pushed to code review sooner.  In the meantime, I wanted to keep the
rest of the branch in place so I could see what was left to tackle.

I cherry-picked replacements for many of the "good" commits -- from
their original topic branches HamFist swiped them from -- so I would
have the current, reviewable commit to push. Then I tested the
long-running branch on top of these commits.  This involved about 8 or
10 passes through 'git rebase -i master' for one reason or another.

On this branch of 40 commits, git interrupted me about 10 times on
each pass to ask me what to do.  The reason is always one of these:

  1. There is a new conflict I need to resolve
      examine / mergetool / test / --continue

  2. There is a rerere autoresolved conflict git wants me to approve
      examine / test / --continue

  3. There are no changes left in this commit because either
        a. they were introduced into earlier commits, or
        b. git-rerere-membered that I don't want those changes
      examine / --skip

I went through this process about 5 or 6 times as I massaged the stink
out of this branch.  Cases 2 and 3 became more common as I went along.
 But git always wanted to stop and ask my approval before continuing.
It was frustrating.

I always had my original branch to go compare to.  This one is really
a trial rework of these commits.  So I wish I could tell git to only
bother me when he sees a new conflict.  Don't stop and ask me for
something every 3 or 4 commits.

I really wanted something like this:

   $ git rebase --purge-empty --accept-rerere-authority -i master

So, even though this is an "interactive" rebase, I wish git would do
more of the busywork for me.  That is, I only want it to be as
interactive as it needs to be, and no more so.


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