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