rebase -i: reword empty commit after fast-forward

[phillipwood]

Thanks to Junio for his comments on V1. I've added a comment explaining why we use a fixed set of commits flags as he suggested.

Cc: Junio C Hamano [email protected]

[phillipwood]

/submit

[gitgitgadget]

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1860/phillipwood/rebase-reword-empty-commit-v1

To fetch this version to local tag pr-1860/phillipwood/rebase-reword-empty-commit-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1860/phillipwood/rebase-reword-empty-commit-v1

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Phillip Wood via GitGitGadget" <[email protected]> writes:

> @@ -2510,9 +2510,8 @@ static int do_pick_commit(struct repository *r,
>  		*check_todo = !!(flags & EDIT_MSG);
>  		if (!res && reword) {
>  fast_forward_edit:
> -			res = run_git_commit(NULL, opts, EDIT_MSG |
> -					     VERIFY_MSG | AMEND_MSG |
> -					     (flags & ALLOW_EMPTY));
> +			flags = EDIT_MSG | VERIFY_MSG | AMEND_MSG | ALLOW_EMPTY;
> +			res = run_git_commit(NULL, opts, flags);
>  			*check_todo = 1;
>  		}
>  	}

I am perfectly OK with the idea of run_git_commit() with the fixed
set of flags bits, ignoring everything the preceding code did to
incrementally compute it before the control reaches this point.  In
the fast-forward-edit scenario in which the control reaches this
point, the flag bits like CREATE_ROOT_COMMIT the earlier steps may
have added to "flags".

But the way "flags" variable is used elsewhere in this function is
"we check how this 'pick' step needs to work, and compute bits to
pass when we eventually call run_git_commit() or do_commit(),
incrementally", so making an unconditional assignment to it looked
a bit surprising.  At least the unconditional assignment deserves
a bit of comment explaining why other bits do not matter and these
bits are what we want to use here.

Thanks.

[gitgitgadget]

This patch series was integrated into seen via git@4826972.

[gitgitgadget]

This branch is now known as pw/rebase-i-ff-empty-commit.

[gitgitgadget]

This patch series was integrated into seen via git@e854fdd.

[gitgitgadget]

This patch series was integrated into seen via git@7a7f5d0.

[gitgitgadget]

There was a status update in the "New Topics" section about the branch pw/rebase-i-ff-empty-commit on the Git mailing list:

"git rebase -i" failed to allow rewording an empty commit that has
been fast-forwarded.

Expecting a reroll.
cf. <[email protected]>
source: <[email protected]>

[gitgitgadget]

This patch series was integrated into seen via git@d13b7aa.

[gitgitgadget]

There was a status update in the "Cooking" section about the branch pw/rebase-i-ff-empty-commit on the Git mailing list:

"git rebase -i" failed to allow rewording an empty commit that has
been fast-forwarded.

Expecting a reroll.
cf. <[email protected]>
source: <[email protected]>

[phillipwood]

/submit

[gitgitgadget]

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1860/phillipwood/rebase-reword-empty-commit-v2

To fetch this version to local tag pr-1860/phillipwood/rebase-reword-empty-commit-v2:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1860/phillipwood/rebase-reword-empty-commit-v2

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Phillip Wood via GitGitGadget" <[email protected]> writes:

> As "git commit" will happily create empty merge commits without
> "--allow-empty" we do not need to pass that flag when rewording merge
> commits.

Thanks, will queue.  Let's mark it for 'next'.

[gitgitgadget]

This patch series was integrated into seen via git@d40271f.

[gitgitgadget]

This patch series was integrated into seen via git@cd33264.