git rebase is confused about commits w/o textual changes (e.g. chmod's)

Hello,

git rebase is confused about commits like
https://github.com/pfalcon/civetweb/commit/ce8493837bf7676c6d824cdcb1d5e3a7ed476fe1
- it stops, telling user to just run rebase --continue. I remember like
few years ago rebase was confused like that oftentimes, which is in turn
confused novices trying rebase-based workflow. There's big progress
over years, and it would be nice to make it just perfect.

The exact messages are:

+ git rebase --preserve-merges --onto upstream-master e61d4efbe4d34d64e6be50ad5009045e4ff06764 HEAD
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' # rebase in progress; onto a0b43ae # You are currently rebasing. # (all conflicts fixed: run "git rebase --continue") # nothing to commit, working directory clean Could not pick 5831bf1affad12bfa3146c37b8b622ba4e584ca3

On Tue, Sep 24, 2013 at 10:56:48PM +0300, Paul Sokolovsky wrote:

I'm interested in solving this, but I can't seem to reproduce it with the following script. Can you provide more information about which branches specifically you were using (as well as which git version) so I can reproduce the problem and look into fixing it?

  git checkout -b test-base
  printf "line 1\n" >example
  git add example
  git commit -m "add line 1"

  git checkout -b to-rebase
  chmod 755 example
  git add example
  git commit -m "change permissions"

  git checkout test-base
  printf "line 2\n" >>example
  git add example
  git commit -m "add line"

  git checkout to-rebase
  git rebase test-base
  test -x example

Hello Brian,

On Fri, 27 Sep 2013 22:28:07 +0000 "brian m. carlson" <sandals@crustytoothpaste.net> wrote:

[]

Thanks for your reply - I wondered if my message went thru (I'm not subscribed to the list). I'm running:

$ git --version git version 1.8.4

Specifically from Ubuntu PPA: http://ppa.launchpad.net/git-core/ppa/ubuntu

Script to reproduce the issue is: https://gist.github.com/pfalcon/6736632 , based on a real-world case of merging histories of a fork created from a flat tree snapshot with the original project it was created from.

Thanks,
 Paul                          mailto:pmiscml@gmail.com

On Sat, Sep 28, 2013 at 02:32:44AM +0300, Paul Sokolovsky wrote:

Okay, as I suspected, the rebase would have resulted in an empty commit. In this particular case, the commit being rebased changed the permissions on the files, but those permissions are already correct, so the commit really is empty, even considering permissions. It looks like git is doing the right thing here.

Hello,

On Fri, 4 Oct 2013 20:28:54 +0000 "brian m. carlson" <sandals@crustytoothpaste.net> wrote:

Hmm, ok, thanks for investigation!

But then, about this empty commit handling behavior by rebase. Low-level developer in me understands the current behavior - if we expect changes, but there're none, then it as well may be something wrong, so let's not play smartass, but tell user outright what's happening. But higher-level user in me knows that rebase is pretty trusty nowadays, and real-world cause of empty commits during rebase is that the change is already upstream. So, can we have something like --skip-empty? Then some good time later, we can talk about changing defaults ;-).