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

From: Paul Sokolovsky <pmiscml@gmail.com>
Date: Oct 4, 2013, 20:45 UTC
Message-ID: <20131004234530.3d3a54cc@x34f>
In-Reply-To: <20131004202853.GB4165@vauxhall.crustytoothpaste.net>

Hello,

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

Show 18 quoted lines

> On Sat, Sep 28, 2013 at 02:32:44AM +0300, Paul Sokolovsky wrote:
> > $ 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.
> 
> 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.

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 ;-).

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com