Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
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 signature.asc Description: Digital signature
Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
Hello, On Fri, 4 Oct 2013 20:28:54 + 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 ;-). -- Best regards, Paul mailto:pmis...@gmail.com -- 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
Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
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 signature.asc Description: Digital signature
Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
Hello Brian, On Fri, 27 Sep 2013 22:28:07 + brian m. carlson sand...@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:pmis...@gmail.com -- 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
git rebase is confused about commits w/o textual changes (e.g. chmod's)
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:pmis...@gmail.com -- 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
