We currently detect Git repositories by finding the top level of the
working tree, and if we fail to detect it, assume that we're not in a
repository. However, there's a case we don't consider: a bare
repository.
Let's detect if the user is in a bare repository by checking if gitdir
is set, and if so, using that if there is no working tree. We now
detect bare Git repositories with vcs_info, as expected.
Git 2.25 introduced a change to how git rev-parse --show-toplevel
behaves. Traditionally, it succeeded with no output if the user was
in a bare repository. Now it dies, printing an error to standard error.
Consequently, when the user is in a bare repository with a newer Git,
vcs_info prints noisily to standard error.
While this is functionally harmless, it is annoying for the shell to
print messages from Git every time the prompt is printed, so let's
silence the error message.
Before this commit, the following use-case:
git checkout foo^
git show foo | git am
would result in a fatal error, with vcs_info_msg_N_ not set:
VCS_INFO_git_getbranch:18: no such file or directory: .git/rebase-apply/onto
Now they are set correctly, and HEAD's commit hash is used.
Before this commit, the value of %b was the hash of the commit from the
"source" side of the rebase, from .git/rebase-apply/orig-head and
.git/rebase-apply/original-commit. This broke the invariant that
%b expands to a git-rev-parse(1) expression resolving to what %r
expands to.
Use .git/rebase-apply/onto instead as, empirically, it contains the
correct value.
Ask git-describe(1) and git-name-rev(1) to compute a gitrevisions(7)
name in terms of a branch or tag that contains (= is a descendant of,
is younger than) HEAD.
In this repository, the output changes from "9567bfe..." to
"master~1" or "remotes/origin/HEAD~1". This would also happen
during bisects, e.g., "bisect/bad~22".
Fixes prompt indicator in case if the repository requires a non-default
feature. With HGRCPATH, it results in:
abort: repository requires features unknown to this Mercurial: ...
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
Which, in turn, results in "default" getting reported regardless of what
is the current state of the repo.
Before this change, ${git_unapplied_s} was unused and the %c
(${hook_com[unapplied]}) expando evaluated to the number of digits in
the string returned by the gen-unapplied-string hook (or to the number
of digits in the number of unapplied patches, when there was no such
hook).
Mikael informs me on IRC, that in new versions of git (he used 2.6.1)
where the "am" subcommand is now a builtin, a file that is used by the
git backend of vcs_info (namely .git/rebase-apply/msg-clean) is not
available anymore, leading to an annoying error message:
VCS_INFO_get_data_git:232: no such file or directory: .git/rebase-apply/msg-clean
This patch checks for the availabiliy of the file before using it,
and adjusts the value of the dependant values accordingly.
Before this patch, $gitbranch would be set to empty, which caused
VCS_INFO_get_data_git to early out with a failure status¹, consequently
$vcs_info_msg_0_ would be empty.
¹ via the 'if [[ -z ]]' block around line 170.
This sets the %b expando to the hash of the before-the-merge HEAD, rather
than to the literal string "detached HEAD". That hash is already available
via the gen-applied-string hook.
When pressing Ctrl-C after `git am`, only `last` exists in
`.git/rebase-apply/`, which is empty.
This patch fixes it to fall back to "no patch applied" then.
This shows, during 'git merge', the revision hashes of the "remote" head
(the one that will become second parent of the commit) in the %m expando.
Review-by: Frank Terbeck
When running git rebase -m and a conflict occurs, the git-rebase-todo
file is not present. This leads to an error from grep every time the
shell prompt is printed when vcs_info is enabled. Avoid this message by
checking if the file exists before trying to grep it.
