Re: [PATCH v5 1/2] branch: not report invalid tracking branch

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

Jiang Xin <worldhello.net@gmail.com> writes:

> Command "git branch -vv" will report tracking branches, but invalid
> tracking branches are also reported. This is because the function
> stat_tracking_info() can not distinguish whether the upstream branch
> does not exist, or nothing is changed between one branch and its
> upstream.

I am guessing that by "invalid", you used to have another branch
(possibly a remote one) you built a branch on (hence the upstream of
the latter is set to the former) and the former branch no longer
exists.

Shouldn't that case reported a bit more specially?  After doing this:

	git init
        git commit --allow-empty -m initial ;# on master
        git branch topicbase
        git checkout -t -b topic topicbase
        git commit --allow-empty -m topic ;# on topic
        git branch -d topicbase

the branch "topic" _thinks_ it is still based on "topicbase", but of
course "git log @{u}.." will fail.

A few thought-alouds:

 - Perhaps "git branch -d topicbase" should have warned that there
   are some branches that are based on it?  Should it have failed?
   Or should it automatically removed branch.*.merge entries that
   point at it (while warning)?

 - The operation that removes the @{u} of some branch does not have
   to be "git branch -d".  It could be "remote --prune", and it does
   not make much sense to fail that operation, as what is gone from
   the other side is gone, and the point of having remote tracking
   branches is to keep a faithful copy of the observed status of the
   remote.  It implies that failing "git branch -d topicbase" is not
   a good idea.  Also removing the branch.*.merge automatically is
   probably not what the user wants (at least, the name would hint
   something, even after the topicbase branch is gone).

So "git branch -v -v [topic]" would want to still say that topic is
based on topicbranch, even though the latter is gone and there is no
longer a real "building on" relationship.

E.g. before "git branch -d topicbase" we would see something like:

    $ git branch -v -v
      master    e67ac84 initial
    * topic     3fc0f2a [topicbase: ahead 1] topic
      topicbase e67ac84 [master] initial

and after it, we currently see:

    $ git branch -v -v
      master    e67ac84 initial
    * topic     3fc0f2a [topicbase] topic
      topicbase e67ac84 [master] initial

but we may want to say:

    $ git branch -v -v
      master    e67ac84 initial
    * topic     3fc0f2a [topicbase (gone)] topic
      topicbase e67ac84 [master] initial

or something.

In order to distinguish these three cases (i.e. no tracking, with
configured but no longer valid tracking, and with tracking), you
would need more than true/false.

> This patch changes the return value of function stat_tracking_info().
> Only returns false when there is no tracking branch or the tracking
> branch is invalid, otherwise true.

Instead, you would need -1 (with "gone" base), 0 (no base), 1 (with
base).

This is a tangent, but we might want to rename stat_tracking_info().
A branch A building on top of another branch B does not mean A
"tracks" B.  The wording is a source of confusion.