"Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.
