From: Fabian Ruch <bafain@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [RFC PATCH 3/7] rebase -i: Stop on root commits with empty log messages
Date: Sun, 22 Jun 2014 02:32:14 +0200 [thread overview]
Message-ID: <53A6240E.9000201@gmail.com> (raw)
In-Reply-To: <CAPig+cS48D1GBX9duHLVWnsW+g5_8rBGOdU=UBRuxrS9JpUh_A@mail.gmail.com>
Hi Eric,
On 06/21/2014 02:33 AM, Eric Sunshine wrote:
> On Wed, Jun 18, 2014 at 11:28 PM, Fabian Ruch <bafain@gmail.com> wrote:
>> When `rebase` is executed with `--root` but no `--onto` is specified,
>> `rebase` creates a sentinel commit which is replaced with the root
>> commit in three steps. This combination of options results never in a
>> fast-forward.
>>
>> 1. The sentinel commit is forced into the authorship of the root
>> commit.
>>
>> 2. The changes introduced by the root commit are applied to the index
>> but not committed. If this step fails for whatever reason, all
>> commit information will be there and the user can safely run
>> `git-commit --amend` after resolving the problems.
>>
>> 3. The new root commit is created by squashing the changes into the
>> sentinel commit which already carries the authorship of the
>> cherry-picked root commit.
>>
>> The command line used to create the commit in the third step specifies
>> effectless and erroneous options. Remove those.
>>
>> - `--allow-empty-message` is erroneous: If the root's commit message is
>> empty, the rebase shall fail like for any other commit that is on the
>> to-do list and has an empty commit message.
>>
>> Fix the bug that git-rebase does not fail when the initial commit has
>> an empty log message but is replayed using `--root` is specified.
>> Add test.
>>
>> - `-C` is effectless: The commit being amended, which is the sentinel
>> commit, already carries the authorship and log message of the
>> cherry-picked root commit. The committer email and commit date fields
>> are reset either way.
>>
>> After all, if step two fails, `rebase --continue` won't include these
>> flags in the git-commit command line either.
>>
>> Signed-off-by: Fabian Ruch <bafain@gmail.com>
>> ---
>> git-rebase--interactive.sh | 4 ++--
>> t/t3412-rebase-root.sh | 39 +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> index fffdfa5..f09eeae 100644
>> --- a/git-rebase--interactive.sh
>> +++ b/git-rebase--interactive.sh
>> @@ -539,8 +539,8 @@ do_pick () {
>> git commit --allow-empty --allow-empty-message --amend \
>> --no-post-rewrite -n -q -C $1 &&
>> pick_one -n $1 &&
>> - git commit --allow-empty --allow-empty-message \
>> - --amend --no-post-rewrite -n -q -C $1 \
>> + git commit --allow-empty --amend \
>> + --no-post-rewrite -n -q \
>> ${gpg_sign_opt:+"$gpg_sign_opt"} ||
>> die_with_patch $1 "Could not apply $1... $2"
>> else
>> diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
>> index 0b52105..3608db4 100755
>> --- a/t/t3412-rebase-root.sh
>> +++ b/t/t3412-rebase-root.sh
>> @@ -278,4 +278,43 @@ test_expect_success 'rebase -i -p --root with conflict (second part)' '
>> test_cmp expect-conflict-p out
>> '
>>
>> +test_expect_success 'stop rebase --root on empty root log message' '
>> + # create a root commit with a non-empty tree so that rebase does
>> + # not fail because of an empty commit, and an empty log message
>> + echo root-commit >file &&
>> + git add file &&
>> + tree=$(git write-tree) &&
>> + root=$(git commit-tree $tree </dev/null) &&
>> + git checkout -b no-message-root-commit $root &&
>> + # do not ff because otherwise neither the patch nor the message
>> + # are looked at and checked for emptiness
>> + test_must_fail env EDITOR=true git rebase -i --force-rebase --root &&
>> + echo root-commit >file.expected &&
>> + test_cmp file file.expected &&
>
> It is customary, and provides nicer diagnostic output upon failure, to
> have the "expected" file mentioned first:
>
> test_cmp file.expected file &&
Ok.
>> + git rebase --abort
>
> Do you want to place this under control of test_when_finished
> somewhere above the "git rebase" invocation to ensure cleanup if
> something fails before this point?
Thanks a lot for the hint, I will place the test_when_finished directly
above the rebase -i command line because it is not relevant before, the
exact position shouldn't matter though. I didn't know that test_run_
skips the cleanup code if -i (for immediate mode) is passed to the test
driver and the test case fails.
Fabian
>> +'
>> +
>> +test_expect_success 'stop rebase --root on empty child log message' '
>> + # create a root commit with a non-empty tree and provide a log
>> + # message so that rebase does not fail until the root commit is
>> + # successfully replayed
>> + echo root-commit >file &&
>> + git add file &&
>> + tree=$(git write-tree) &&
>> + root=$(git commit-tree $tree -m root-commit) &&
>> + git checkout -b no-message-child-commit $root &&
>> + # create a child commit with a non-empty patch so that rebase
>> + # does not fail because of an empty commit, but an empty log
>> + # message
>> + echo child-commit >file &&
>> + git add file &&
>> + git commit --allow-empty-message --no-edit &&
>> + # do not ff because otherwise neither the patch nor the message
>> + # are looked at and checked for emptiness
>> + test_must_fail env EDITOR=true git rebase -i --force-rebase --root &&
>> + echo child-commit >file.expected &&
>> + test_cmp file file.expected &&
>> + git rebase --abort
>
> Same two comments as for previous test.
Ok.
>> +'
>> +
>> test_done
next prev parent reply other threads:[~2014-06-22 0:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1403146774.git.bafain@gmail.com>
2014-06-19 3:28 ` [RFC PATCH 1/7] rebase -i: Make option handling in pick_one more flexible Fabian Ruch
2014-06-20 13:40 ` Michael Haggerty
2014-06-20 19:53 ` Junio C Hamano
2014-06-23 0:04 ` Fabian Ruch
2014-06-21 23:21 ` Fabian Ruch
2014-06-23 16:09 ` Johannes Schindelin
2014-06-19 3:28 ` [RFC PATCH 2/7] rebase -i: Teach do_pick the option --edit Fabian Ruch
2014-06-20 13:41 ` Michael Haggerty
2014-06-22 0:09 ` Fabian Ruch
2014-06-19 3:28 ` [RFC PATCH 3/7] rebase -i: Stop on root commits with empty log messages Fabian Ruch
2014-06-21 0:33 ` Eric Sunshine
2014-06-22 0:32 ` Fabian Ruch [this message]
2014-06-19 3:28 ` [RFC PATCH 4/7] rebase -i: Commit only once when rewriting picks Fabian Ruch
2014-06-19 3:28 ` [RFC PATCH 5/7] rebase -i: Do not die in do_pick Fabian Ruch
2014-06-19 3:28 ` [RFC PATCH 6/7] rebase -i: Prepare for squash in terms of do_pick --amend Fabian Ruch
2014-06-19 3:28 ` [RFC PATCH 7/7] rebase -i: Teach do_pick the options --amend and --file Fabian Ruch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53A6240E.9000201@gmail.com \
--to=bafain@gmail.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).