1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-12 04:46:08 +02:00
git/t/t3424-rebase-empty.sh
Elijah Newren e98c4269c8 rebase (interactive-backend): fix handling of commits that become empty
As established in the previous commit and commit b00bf1c9a8
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design.  This commit addresses
another such corner case: commits which "become empty".

A careful reader may note that there are two types of commits which would
become empty due to a rebase:

  * [clean cherry-pick] Commits which are clean cherry-picks of upstream
    commits, as determined by `git log --cherry-mark ...`.  Re-applying
    these commits would result in an empty set of changes and a
    duplicative commit message; i.e. these are commits that have
    "already been applied" upstream.

  * [become empty] Commits which are not empty to start, are not clean
    cherry-picks of upstream commits, but which still become empty after
    being rebased.  This happens e.g. when a commit has changes which
    are a strict subset of the changes in an upstream commit, or when
    the changes of a commit can be found spread across or among several
    upstream commits.

Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.

When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes.  Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical).  As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around.  All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.

For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case.  Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes.  Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way.  As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.

Junio commented on the "become-empty" types of commits as follows[1]:

    WRT a change that ends up being empty (as opposed to a change that
    is empty from the beginning), I'd think that the current behaviour
    is desireable one.  "am" based rebase is solely to transplant an
    existing history and want to stop much less than "interactive" one
    whose purpose is to polish a series before making it publishable,
    and asking for confirmation ("this has become empty--do you want to
    drop it?") is more appropriate from the workflow point of view.

[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/

I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases.  Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.

Introduce a new command line flag for selecting the desired behavior:
    --empty={drop,keep,ask}
with the definitions:
    drop: drop commits which become empty
    keep: keep commits which become empty
    ask:  provide the user a chance to interact and pick what to do with
          commits which become empty on a case-by-case basis

In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
    explicitly interactive: ask
    otherwise: drop

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 15:40:42 -08:00

127 lines
3.1 KiB
Bash
Executable File

#!/bin/sh
test_description='git rebase of commits that start or become empty'
. ./test-lib.sh
test_expect_success 'setup test repository' '
test_write_lines 1 2 3 4 5 6 7 8 9 10 >numbers &&
test_write_lines A B C D E F G H I J >letters &&
git add numbers letters &&
git commit -m A &&
git branch upstream &&
git branch localmods &&
git checkout upstream &&
test_write_lines A B C D E >letters &&
git add letters &&
git commit -m B &&
test_write_lines 1 2 3 4 five 6 7 8 9 ten >numbers &&
git add numbers &&
git commit -m C &&
git checkout localmods &&
test_write_lines 1 2 3 4 five 6 7 8 9 10 >numbers &&
git add numbers &&
git commit -m C2 &&
git commit --allow-empty -m D &&
test_write_lines A B C D E >letters &&
git add letters &&
git commit -m "Five letters ought to be enough for anybody"
'
test_expect_failure 'rebase (am-backend)' '
test_when_finished "git rebase --abort" &&
git checkout -B testing localmods &&
# rebase (--am) should not drop commits that start empty
git rebase upstream &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --merge --empty=drop' '
git checkout -B testing localmods &&
git rebase --merge --empty=drop upstream &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --merge uses default of --empty=drop' '
git checkout -B testing localmods &&
git rebase --merge upstream &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --merge --empty=keep' '
git checkout -B testing localmods &&
git rebase --merge --empty=keep upstream &&
test_write_lines D C2 C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --merge --empty=ask' '
git checkout -B testing localmods &&
test_must_fail git rebase --merge --empty=ask upstream &&
git rebase --skip &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --interactive --empty=drop' '
git checkout -B testing localmods &&
git rebase --interactive --empty=drop upstream &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --interactive --empty=keep' '
git checkout -B testing localmods &&
git rebase --interactive --empty=keep upstream &&
test_write_lines D C2 C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --interactive --empty=ask' '
git checkout -B testing localmods &&
test_must_fail git rebase --interactive --empty=ask upstream &&
git rebase --skip &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_expect_success 'rebase --interactive uses default of --empty=ask' '
git checkout -B testing localmods &&
test_must_fail git rebase --interactive upstream &&
git rebase --skip &&
test_write_lines D C B A >expect &&
git log --format=%s >actual &&
test_cmp expect actual
'
test_done