Thread (71 messages) flat view 71 messages, 8 authors, 2016-06-15

Re: [PATCH v8 4/4] git-rebase: add keep_empty flag

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:54:16

Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman [off-list ref] wrote:
quoted
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help