Re: [PATCH v17 1/2] refactor format_branch_comparison in preparation

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Jan 10, 2026, 20:04 UTC
Message-ID: <20260110200431.53479-1-haraldnordgren@gmail.com>
In-Reply-To: <xmqqfr8ds7br.fsf@gitster.g>

Show 9 quoted lines

> Not at all.  Unless the contrast were "something_fetch" vs
> "something_push", that is.  And that something being cryptic "sti"
> (recall my comment on it, being the name of the function that
> returns the value, which is less understandable than using words
> that signals what the variable _means_), would not make much sense
> for the "push" direction, as "sti" is not even an abbreviation for
> the function that gives the value.  "cmp" (or "compare" for that
> matter) still has the ambiguity "compare with what and what for?",
> but at least it would be better than "sti".

Maybe simplest would be 'upstream_diff' and 'push_diff'? But this begs the question of why not all the old 'ours', 'theirs', etc variables are missing an 'upstream_' prefix.

I feel like this can turn into endless refactoring, latest version now has 'cmp_fetch' and 'push_cmp_fetch'.

I have on my TODO list to fix the pluralization of the "diverged" text after this patch series has been merged. I'm also working on refactoring this by introducing a struct to pass data to 'format_branch_comparison'. This has the very nice benefit on natural namespacing of variables when they become fields in struct variables like 'upstream_branch' and 'push_branch'.

In the meantime I think I will leave this patch series for now 🤗

Harald