| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
gen-unapplied-string in.
This is an incompatible change; see README for details.
Tweaks (relative to posted version): tweaked README, removed scalpel (debug print).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computer the %b expando correctly.
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.
|
|
|
|
| |
$hook_com[git_patches_applied] to a string of the form 'foo bar', never just 'foo'.
|
|
|
|
|
|
|
| |
autoloadable outer function.
This allows enabling tracing of the helper functions without fned'ing
the outer function.
|
|
|
|
| |
applied-patches, handle an edge case where the subject is not available.
|
|
|
|
|
|
|
|
|
|
|
|
| |
$subject" --- that is, has a space and a non-empty second argument --- even with future 'git rebase -i' verbs.
Use of '?' is consistent with these precedents:
Backends/VCS_INFO_get_data_git:220: printf -v "git_patches_applied[$p]" "%04d ?" "$p"
Backends/VCS_INFO_get_data_git:242: git_patches_applied+=("? $subject")
Backends/VCS_INFO_get_data_git:244: git_patches_applied+=("?")
VCS_INFO_quilt:160: applied[$i]+=" ?"
VCS_INFO_quilt:168: unapplied[$i]+=" ?"
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a symbolic name before falling back to a raw commit hash.
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".
|
|
|
|
| |
No functional change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Test case: a patch whose subject is '%Sfoo%sbar'. ('S' and 's' are
expandos both in prompts and in the 'formats' style.)
|
| |
|
| |
|
|
|
|
|
|
| |
callers.
This changes hook invocation order in the hg backend.
|
| |
|
|
|
|
|
| |
This also fixes the %a (${hook_com[all-n]}) expando in the hg backend:
before this change, it counted only unapplied changes.
|
| |
|
|
|
|
|
| |
Not all callers reset ${hook_com}, but those that don't, immediately
overwrite it a few lines later.
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
Review-by: Frank Terbeck
|
|
|
|
|
|
|
|
| |
msg-clean is unavailable.
Example (in this repository):
git -c merge.merge-changelog.driver=/bin/false rebase --onto=1955cce^^ 1955cce^ 1955cce
|
| |
|
|
|
|
|
|
|
|
|
| |
command.
Fixes issue whereby the external command would print "*" for repeated
octets.
Includes comment change, cf 39790.
|
|
|
|
|
| |
This changes the behaviour on "unknown" git-rebase actions (those other
than pick/reword/edit/fixup/squash/execute).
|
| |
|
|
|
|
|
|
| |
case.
This manifested, e.g., in 'git am' of a single patch that had a conflict.
|
|
|
|
| |
heads. (Follow-up to 36725.)
|
| |
|
|
|
|
|
|
| |
The "seq" utility is usually available on GNU systems only. This
exchanges calls to seq with pure zsh features. Also: Less forks are
good.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The %b expando should be the hash prior to the merge. The hash of the merge
result is available as the %i expando and 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.
|
| |
|
| |
|