Re: [PATCH] status: reword message for a missing upstream branch

[Junio C Hamano <gitster@pobox.com>]

Elia Pinto <gitter.spiros@gmail.com> writes:

> The message was added in f2e087395b (branch: report invalid tracking
> branch as gone, 2013-08-26), assuming that a configured upstream that
> cannot be resolved must have been deleted. But "git clone" of an empty
> repository configures the upstream anyway, and Git has no way to tell
> "deleted" from "not created yet".

I am totally with you up to this point.  This is a great issue to
tackle.  I am curious to learn how you would solve it without
throwing the baby with bathwater, though.  Let me read on.

> Since we cannot tell the two cases apart, change the message for both,
> including the "deleted" case that has been reported as "gone" since
> 2013, so that it is correct either way:
>
>     Your branch is set up to track 'origin/master', which does not exist.
>       (use "git push" to create it)
>       (use "git branch --unset-upstream" to stop tracking it)

Ahh, "does not exist".  Clever.  That does cover both cases and
reads reasonably natural.  If we wanted to have something short that
we can reuse elsewhere (like inside [] in place of [gone]), we could
say which is "missing", perhaps.

Do we emit "git push" suggestion unconditionally (meaning, does "git
push" immediately in this state always create the "upstream" that
does not exist yet), or do we have to check if "git push" will
create it before saying so?

> Only suggest "git push" when it would actually create the upstream,
> that is when the push destination of the branch (what "@{push}"
> resolves to) is the upstream itself.

Ah, your flow of explanation exactly matches how I explore the
possibilities in my head, given the thinking of the author revealed
so far.  Excellent log message that is very easy to follow.

> This is not the case, for
> example, with push.default set to "nothing", or when pushing to a
> different remote (branch.<name>.pushRemote or remote.pushDefault).
> It is also not the case with push.default set to "matching": it only
> pushes branches that already exist on the remote, so it would not
> create the missing upstream. In all these cases only suggest
> "git branch --unset-upstream".

Indeed.  That sounds like a good way to go.

> "git checkout" prints the same message, so it changes too. The
> "[gone]" shown by "git status -sb", "git branch -vv" and
> "%(upstream:track)" is not changed, as scripts may depend on it.

Does this refer to what wt_shortstatus_print_tracking() says?  It is
_(translated), so in a sense it is a fair game to be improved.