Re: [PATCH v8 4/4] git-rebase: add keep_empty flag
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Jul 18, 2012, 07:10 UTC
- Message-ID
- <5006614E.8090601@viscovery.net>
- In-Reply-To
- <CAOeW2eEchYzRYYUBySKg5xYY3vBDy8GVcAd=ay-HoAGDLZtORw@mail.gmail.com>
Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
Show 24 quoted lines
> On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman <nhorman@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