Subject: Re: [PATCH 2/2] status: improve rebase todo list parsing

From: Phillip Wood <[email-masked]>
Date: Tue, 21 Apr 2026 17:03:35 +0100

Hi Tian

On 20/04/2026 17:38, Tian Yuchen wrote:
> On 4/20/26 23:04, Phillip Wood wrote:
> 
>> +    if (!starts_with(p, abbrev))
>> +        goto out; /* object name was a refname containing only 
>> xdigits */
>> +    p += strlen(abbrev);
>> +    strbuf_remove(line, p - line->buf, end_of_object_name - p);
>> +    end_of_object_name = p;
> 
> 
>> -    if ((2 <= string_list_split(&split, line->buf, " ", 2)) &&
>> -        !repo_get_oid(r, split.items[1].string, &oid)) {
>> -        strbuf_reset(line);
>> -        strbuf_addf(line, "%s ", split.items[0].string);
>> -        strbuf_add_unique_abbrev(line, &oid, DEFAULT_ABBREV);
>> -        for (size_t i = 2; i < split.nr; i++)
>> -            strbuf_addf(line, " %s", split.items[i].string);
> 
> I noticed that after this patch, refnames shorter than seven characters 
> are no longer standardised to the standard seven-character length, 
> because the 'start_with()' function always returns FALSE. The code jumps 
> directly to 'out', without completing or cutting the refname.

Do you mean object id's rather than refnames? We do not want to alter 
refnames, but we do want to abbreviate object ids. You're right that if 
the todo list contains an object id that is shorter than the default 
abbreviation length it will not be expanded but "git rebase" rewrites 
the todo list to contain full length object ids after the user has 
edited it. If a user may edit the todo list directly without using "git 
rebase --edit-todo" and then run "git status" before "git rebase 
--continue" the todo list could contain shorter object ids but that 
seems pretty unlikely.
> 
> I’m not sure if this was your intention, but I just want to point it out 
> for your information.
> 
> (Also noted that there is a very rare scenario where the OID of a 
> refname longer than 7 characters happens to begin with the refname 
> itself; in this case, 'start_with' returns TRUE and the string is cut 
> incorrectly. However, I think we can safely ignore this.)

Yes, I think that's unlikely to happen in practice.

Thanks

Phillip
> Regards, Yuchen