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

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

[Paul Sokolovsky]

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


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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Tue, Sep 24, 2013 at 10:56:48PM +0300, Paul Sokolovsky wrote:
> 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

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

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Paul Sokolovsky]

Hello Brian,

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

> On Tue, Sep 24, 2013 at 10:56:48PM +0300, Paul Sokolovsky wrote:
> > 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
[]

> 
> 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?

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

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.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Paul Sokolovsky]

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