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

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello,

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

> 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