Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
Sorry I'm commenting so late; I didn't have time to look at your
patches when you sent them, but I'm currently working on the code
touched by this patch.
--
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: [PATCH v8 4/4] git-rebase: add keep_empty flag
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
-- Hannes
--
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: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Wed, Jul 18, 2012 at 12:10 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
Ah, makes sense. Thanks!
--
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: [PATCH v8 4/4] git-rebase: add keep_empty flag
On Wed, Jul 18, 2012 at 09:10:06AM +0200, Johannes Sixt wrote:
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman nhor...@tuxdriver.com wrote:
pick_one () {
ff=--ff
+
case $1 in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
case $force_rebase in '') ;; ?*) ff= ;; esac
output git rev-parse --verify $sha1 || die Invalid commit name:
$sha1
+
+ if is_empty_commit $sha1
+ then
+ empty_args=--allow-empty
+ fi
+
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $ff $@
+ output git cherry-pick $empty_args $ff $@
The is_empty_commit check seems to mean that if $sha1 is an empty
commit, we pass the --allow-empty option to cherry-pick. If it's not
empty, we don't. The word allow in allow-empty suggests that even
if the commit is not empty, cherry-pick would not mind. So, can we
always pass allow-empty to cherry-pick (i.e. even if the commit to
pick is not empty)?
I don't think so. If the commit is not empty, but all its changes are
already in HEAD, then it will become empty when cherry-picked to HEAD.
In such a case, we usually do not want to record an empty commit, but stop
rebase to give to user a chance to deal with the situation.
-- Hannes
Yes, this is the meaning. Allow was used in the sense of a filter, in that we
are allowing an empty commit to make it into the history, whereas a rebase or
cherry-pick would normally exclude it.
Neil
--
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
