Thread (1 message) 1 message, 1 author, 2025-02-05

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

From: Junio C Hamano <hidden>
Date: 2025-02-05 18:26:17

"Phillip Wood via GitGitGadget" [off-list ref] writes:
quoted hunk
@@ -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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help