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 <nhorman@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html