t7512: test "detached from" as well

b397ea4863a1 (status: show more info than "currently not on any
branch", 2013-03-13) wanted to make sure that after a checkout to
detach HEAD, the user can see where the HEAD was originally detached
from.  The last test added by that commit to t7512 shows one
example, immediately after HEAD is detached.  Enhance that test to
show "detached HEAD from" form that should be shown when the user
further resetted to another commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: remove unused field in grab_1st_switch_cbdata

The struct grab_1st_switch_cbdata has the field "found", which is
set in grab_1st_switch() when a match is found.  This information is
redundant and unused by any code.  The return value of the function
serves to communicate this information anyway.

Remove the field.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t2021-checkout-last: "checkout -" should work after a rebase finishes

  $ git checkout -

does not work as expected after a rebase.  This is because the
reflog records "checkout" made by "rebase" as its implementation
detail the same way as end-user initiated "checkout", and makes it
count as the branch that was previously checked out.

Add four failing tests documenting this bug: two for a normal rebase,
and another two for an interactive rebase.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: do not depend on rebase reflog messages

b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD.  Before this patch, with a detached
HEAD, we saw:

  $ git status
  # Not currently on any branch.

But after the patch, we see:

  $ git checkout v1.8.2
  $ git status
  # HEAD detached at v1.8.2.

It works by digging the reflog for the most recent message of the
form "checkout: moving from xxxx to yyyy".  It then asserts that
HEAD and "yyyy" are the same, and displays this message.  When they
aren't equal, it displays:

  $ git status
  # HEAD detached from fe11db.

so that the user can see where the HEAD was first detached.

In case of a rebase [-i] operation in progress, this message depends
on the implementation of rebase writing "checkout: " messages to the
reflog, but that is an implementation detail of "rebase".  To remove
this dependency so that rebase can be updated to write better reflog
messages, replace this "HEAD detached from" message with:

  # rebase in progress; onto $ONTO

Changes to the commit object name in the expected output for some of
the tests shows that what the test expected "status" to show during
"rebase -i" was not consistent with the output during a vanilla
"rebase", which showed on top of what commit the series is being
replayed.  Now we consistently expect something meaningful to the
end user.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash prompt: fix redirection coding style in tests

Use '>file' instead of '> file', in accordance with the coding
guidelines.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: use 'write_script' helper in interactive rebase test

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
completion, bash prompt: move __gitdir() tests to completion test suite

Currently __gitdir() is duplicated in the git completion and prompt
scripts, while its tests are in the prompt test suite.  This patch
series is about to change __git_ps1() in a way that it won't need
__gitdir() anymore and __gitdir() will be removed from the prompt
script.

So move all __gitdir() tests from the prompt test suite over to the
completion test suite.  Update the setup tests so that they perform
only those steps that are necessary for each test suite.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: add a test for symbolic link symbolic refs

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: print unique detached HEAD abbreviated object name

When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs 'cut -c1-7 .git/HEAD' to
show the 7 hexdigits abbreviated commit object name in the prompt.
Obviously, this neither respects core.abbrev nor produces a unique
object name.

Fix this by using 'git rev-parse --short HEAD' instead and adjust the
corresponding test to use non-standard number of hexdigits.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: return early from __git_ps1() when not in a git repository

... to gain one level of indentation for the bulk of the function.

(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: run 'git rev-parse --git-dir' directly instead of __gitdir()

__git_ps1() finds out the path to the repository by using the
__gitdir() helper function.  __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few shortcuts to recognize a git
repository in cwd or at $GIT_DIR quickly without actually running 'git
rev-parse'.  However, the former two is only necessary for the
completion script but makes no sense for the bash prompt, while the
latter shortcuts are performance optimizations __git_ps1() can do
without (they just avoid the overhead of fork()+exec()ing a git
process).

Run 'git rev-parse --git-dir' directly in __git_ps1(), because it will
allow this patch series to combine several $(git rev-parse ...)
command substitutions in the main code path, and the overall
performance benefit will far outweigh the loss of those few shortcuts
in __gitdir().  Furthermore, since __gitdir() is not needed anymore
for the prompt, remove it from the prompt script finally eliminating
its duplication between the prompt and completion scripts.  Also
remove the comment from the completion script warning about this code
duplication.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: use bash builtins to find out rebase state

During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/<FILE>)' command
substitution for each.  That is not quite the most efficient way to
read single line single word files, because it imposes the overhead of
fork()ing a subshell and fork()+exec()ing 'cat' several times.

Use the 'read' bash builtin instead to avoid those overheads.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: use bash builtins to find out current branch

__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch.  This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.

Since HEAD is in most cases a single-line file and the symbolic ref
format is quite simple to recognize and parse, read and parse it using
only bash builtins, thereby sparing all that fork()+exec() overhead.
Don't display the git prompt if reading HEAD fails, because a readable
HEAD is required for a git repository.  HEAD can also be a symlink
symbolic ref (due to 'core.preferSymlinkRefs'), so use bash builtins
for reading HEAD only when HEAD is not a symlink.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: combine 'git rev-parse' executions in the main code path

There are a couple of '$(git rev-parse --<opt>)' command substitutions
in __git_ps1() and three of them are executed in the main code path:

 - the first to get the path to the .git directory ('--git-dir'),
 - the second to check whether we're inside the .git directory
   ('--is-inside-git-dir'),
 - and the last, depending on the results of the second, either
   * to check whether it's a bare repo ('--is-bare-repository'), or
   * to check whether inside a work tree ('--is-inside-work-tree').

Naturally, this imposes the overhead of fork()ing three subshells and
fork()+exec()ing three git commands.

Combine these four 'git rev-parse' queries into a single one and use
bash parameter expansions to parse the combined output, i.e. to
separate the path to the .git directory from the true/false of
'--is-inside-git-dir', etc.  This way we can eliminate two of the
three subshells and git commands.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: combine 'git rev-parse' for detached head

When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() now runs the '$(git rev-parse
--short HEAD)' command substitution to get the abbreviated detached
HEAD commit object name.  This imposes the overhead of fork()ing a
subshell and fork()+exec()ing a git process.

Avoid this overhead by combining this command substitution with the
"main" 'git rev-parse' execution for getting the path to the .git
directory & co.  This means that we'll look for the abbreviated commit
object name even when it's not necessary, because we're on a branch or
the detached HEAD can be described.  It doesn't matter, however,
because once 'git rev-parse' is up and running to fulfill all those
other queries, the additional overhead of looking for the abbreviated
commit object name is not measurable because it's lost in the noise.

There is a caveat, however, when we are on an unborn branch, because
in that case HEAD doesn't point to a valid commit, hence the query for
the abbreviated commit object name fails.  Therefore, '--short HEAD'
must be the last options to 'git rev-parse' in order to get all the
other necessary information for the prompt even on an unborn branch.
Furthermore, in that case, and in that case only, 'git rev-parse'
doesn't output the last line containing the abbreviated commit object
name, obviously, so we have to take care to only parse it if 'git
rev-parse' exited without any error.

Although there are tests already excercising __git_ps1() on unborn
branches, they all do so implicitly.  Add a test that checks this
explicitly.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: use bash builtins to check for unborn branch for dirty state

When the dirty work tree and index status indicator is enabled,
__git_ps1() checks for changes in the index by running 'git diff-index
--cached --quiet HEAD --' and looking at its exit code.  However, that
makes sense only when HEAD points to a valid commit: on an unborn
branch the failure of said command would be caused by the invalid
HEAD, not by changes in the index.  Therefore, __git_ps1() first
checks for a valid HEAD by running 'git rev-parse --quiet --verify
HEAD'.

Since the previous patch we implicitly check HEAD's validity by
running 'git rev-parse ... --short HEAD', making the dirty status
indicator's 'git rev-parse' check redundant.  It's sufficient to check
for non-emptyness of the variable holding the abbreviated commit
object name, thereby sparing the overhead of fork()+exec()ing a git
process.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: use bash builtins to check stash state

When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'.  This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.

However, we don't need to be that thorough for the bash prompt.  We
can omit that verification and only check whether 'refs/stash' exists
or not.  Since 'git pack-refs' never packs 'refs/stash', it's a matter
of checking the existence of a ref file.  Perform this check using
only bash builtins to spare the overhead of fork()+exec()ing a git
process.

Also run 'git pack-refs --all' in the corresponding test to document
that the prompt script depends on 'git pack-refs' not packing
'refs/stash' and to catch possible breakages should this behavior ever
change.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: avoid command substitution when checking for untracked files

When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign.  __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.

Avoid this command substitution by additionally passing
'--error-unmatch *', and checking the command's return value.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: avoid command substitution when finalizing gitstring

Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable.  Spare the overhead
of fork()ing a subshell by using 'printf -v <var>' to directly assign
the output to that variable.

zsh's printf doesn't support the '-v <var>' option, so stick with the
command substitution when under zsh.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
bash prompt: mention that PROMPT_COMMAND mode is faster

__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell.  Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.

Mention this in the comments about setting up the git prompt.

The whole series speeds up the bash prompt on Windows/MSysGit
considerably.  Here are some timing results in three scenarios, each
repeated 10 times:

At the top of the work tree, before:

    $ time for i in {0..9} ; do prompt="$(__git_ps1)" ; done

    real    0m1.716s
    user    0m0.301s
    sys     0m0.772s

  After:

    real    0m0.687s
    user    0m0.075s
    sys     0m0.396s

  After, from $PROMPT_COMMAND:

    $ time for i in {0..9} ; do __git_ps1 '\h:\w' '$ ' ; done

    real    0m0.546s
    user    0m0.075s
    sys     0m0.181s

At the top of the work tree, detached head, before:

    real    0m2.574s
    user    0m0.376s
    sys     0m1.207s

  After:

    real    0m1.139s
    user    0m0.151s
    sys     0m0.500s

  After, from $PROMPT_COMMAND:

    real    0m1.030s
    user    0m0.245s
    sys     0m0.336s

In a subdirectory, during rebase, stash status indicator enabled,
before:

    real    0m3.557s
    user    0m0.495s
    sys     0m1.767s

  After:

    real    0m0.717s
    user    0m0.120s
    sys     0m0.300s

  After, from $PROMPT_COMMAND:

    real    0m0.577s
    user    0m0.047s
    sys     0m0.258s

On Linux the speedup ratio is comparable to Windows, but overall it
was about an order of magnitude faster to begin with.  The last case
from above, repeated 100 times, before:

    $ time for i in {0..99} ; do prompt="$(__git_ps1)" ; done

    real    0m2.806s
    user    0m0.180s
    sys     0m0.264s

  After:

    real    0m0.857s
    user    0m0.020s
    sys     0m0.028s

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>