Another look?

[Harald Nordgren <haraldnordgren@gmail.com>]

> And if the new calling convention is to let the caller be responsible for
> calling stat_tracking_info() and figuring out the base branch name, it
> probably is also better to have the caller handle upstream_is_gone case.
> This is especially true if your plan is to reuse this "branch comparison"
> helper to compare a branch with another branch that is *NOT* its upstream
> (e.g., where the result is pushed to).

Done, will be in the next patch!

> IOW, it smells to me that leaving "sti" as a parameter to this function
> is an incomplete refactoring---I say "smell" because I haven't seen the
> other, new, caller that will be added in the future step of this patch
> series.
>
> [...]
>
> As the code already handled !sti, which is equivalent to (!theirs &&
> !ours), in the original, !theirs here meant (!theirs && ours), which is
> (ahead && !behind) in the new world order, which we see a few lines below.

This sounds reasonable, however, if I replace '!sti' with 'ahead && !behind'
then old tests are breaking, one why to avoid them breaking is to switch the
order of these cases, to this, would that be acceptable?

``` } else if (abf == AHEAD_BEHIND_QUICK) { strbuf_addf(sb, _("Your
branch and '%s' refer to different commits.\n"), branch_name); if
(advice_enabled(ADVICE_STATUS_HINTS)) strbuf_addf(sb, _(" (use \"%s\" for
details)\n"), "git status --ahead-behind"); } else if (!theirs && !ours) {
strbuf_addf(sb, _("Your branch is up to date with '%s'.\n"), branch_name);
```

> Do not compare with 0 for equality. Instead write it like so:

Good point! I will upate it!

Thanks for you continued attention to this, much appreciated!



Harald