"git branch" and "git checkout -b" now honor --track option even when
the upstream branch is local.  Previously --track was silently ignored
when forking from a local branch.  Also the command did not error out
when --track was explicitly asked for but the forked point specified
was not an existing branch (i.e. when there is no way to set up the
tracking configuration), but now it correctly does.

The configuration setting branch.autosetupmerge can now be set to
"always", which is equivalent to using --track from the command line.
Setting branch.autosetupmerge to "true" will retain the former behavior
of only setting up branch.*.merge for remote upstream branches.

Includes test cases for the new functionality.
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This also changes it such that:

$ git checkout

will give the same information without changing branches. This is good
for finding out if the fetch you did recently had anything to say
about the branch you've been on, whose name you don't remember at the
moment.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Not terminating the options[] array with OPT_END can cause
usage ("git checkout -h") output to segfault.
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When you are switching to a branch that is marked to merge from
somewhere else, e.g. when you have:

    [branch "next"]
            remote = upstream
            merge = refs/heads/next
    [remote "upstream"]
            url = ...
            fetch = refs/heads/*:refs/remotes/linus/*

and you say "git checkout next", the branch you checked out
may be behind, and you may want to update from the upstream
before continuing to work.

This patch makes the command to check the upstream (in this
example, "refs/remotes/linus/next") and our branch "next", and:

    (1) if they match, nothing happens;

    (2) if you are ahead (i.e. the upstream is a strict ancestor
        of you), one line message tells you so;

    (3) otherwise, you are either behind or you and the upstream
        have forked.  One line message will tell you which and
        then you will see a "log --pretty=oneline --left-right".

We could enhance this with an option that tells the command to
check if there is no local change, and automatically fast
forward when you are truly behind.  But I ripped out that change
because I was unsure what the right way should be to allow users
to control it (issues include that checkout should not become
automatically interactive).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The only differences in behavior should be:

 - git checkout -m with non-trivial merging won't print out
   merge-recursive messages (see the change in t7201-co.sh)

 - git checkout -- paths... will give a sensible error message if
   HEAD is invalid as a commit.

 - some intermediate states which were written to disk in the shell
   version (in particular, index states) are only kept in memory in
   this version, and therefore these can no longer be revealed by
   later write operations becoming impossible.

 - when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
   rr-cache/MERGE_RR, like reset always has.

I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.

Other than these items, the results should be identical to the shell
version, so far as I can tell.

[jc: squashed lock-file fix from Dscho in]
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>