Thread (175 messages) flat view 175 messages, 9 authors, 9d ago

Re: [PATCH v14 7/8] history: create squashed commits without editing

From: Phillip Wood <hidden>
Date: 2026-08-25 09:08:27

On 24/08/2026 16:07, Junio C Hamano wrote:
Phillip Wood [off-list ref] writes:
quoted
On 20/08/2026 21:10, Junio C Hamano wrote:
quoted
"Harald Nordgren via GitGitGadget" [off-list ref] writes:
quoted
+	/*
+	 * Allow "fixup! <hex object id>", but not "fixup! HEAD^" or
+	 * "fixup! main". If the target is not being squshed check the subject
+	 * to allow "fixup! abc123" and "fixup! <subject of abc123>" to be
+	 * squashed together.
+	 */
+	target = lookup_commit_reference_by_name(s);
+	if (target && istarts_with(oid_to_hex(&target->object.oid), s)) {
Why istarts_with()?  "fixup! ABCdef" should not be accepted, should it?
I agree there isn't really a compelling case for mixed case oids, but
accepting all uppercase, or all lowercase seems reasonable, or are we
Tell that to brian who wrote the bc/restrict-hex-to-lowercase topic
in [ref].
quoted
quoted
planning to completely ban uppercase oids as brain has suggested? The
aim here is to accept any oid that rebase would, but not accept ref names.
I understand that we never emitted hexadecimal containing uppercase
letters ourselves, so 'commit --fixup' and friends wouldn't have
added anything that requires istarts_with().  So accepting any oid
that we would have given the users after "fixup!" but not refnames
can be achieved by starts_with() just fine, no?
If they're using "git commit --fixup" then yes. If we're going to reject 
uppercase hex everywhere then clearly we should be using starts_with() 
here, but if we keep accepting uppercase hex elsewhere why should we 
reject it here?

Thanks

Phillip
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help