Re: [PATCH] rebase -i: reword empty commit after fast-forward

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2025, 18:26 UTC
Message-ID: <xmqqtt98nt89.fsf@gitster.g>
In-Reply-To: <pull.1860.git.1738751840816.gitgitgadget@gmail.com>

"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 12 quoted lines

> @@ -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.