Hello, On Fri, 4 Oct 2013 20:28:54 +0000 "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html