When switching branches from a subdirectory, checkout rewritten
in C extracted the toplevel of the tree in there.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking out a branch that is behind or forked from a
branch you are building on top of, we used to show full
left-right log but if you already _know_ you have long history
since you forked, it is a bit too much.
This tones down the message quite a bit, by only showing the
number of commits each side has since they diverged. Also the
message is not shown at all under --quiet.
Signed-off-by: Junio 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio 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: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio 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: Junio 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
