| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
gen-applied-string, gen-unapplied-string, and set-patch-format hooks
I use that in my gen-applied-string hook.
|
|
|
|
| |
to global scope
|
| |
|
|
|
|
| |
Work around <https://github.com/chrisbra/vim-zsh/issues/39>.
|
|
|
|
|
|
|
| |
vcs_info
If someone does 'HGPLAIN=1 vcs_info', any vcs_info hooks should be called with
HGPLAIN set. Declaring it 'local' broke that.
|
|
|
|
|
|
|
|
| |
get-revision is set and check-for-changes is not
Tweak: Simplify an always-true condition.
Review-by: Manuel Jacob
|
|
|
|
|
|
|
| |
cvs, git: Set ${vcs_comm[basedir]} like all other backends do.
That doesn't affect anything, not even other vcs_info internals; it's
just for consistency across backends.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the set-patch-format hook (regression from workers/40480).
To reproduce, go to a hg repository with active mq guards and configure
vcs_info as follows:
zstyle '*' get-unapplied true
zstyle ':vcs_info:*set-patch-format*' hooks f
zstyle '*' patch-format '[%g : %G]'
zstyle '*' nopatch-format '[%g : %G]'
zstyle '*' formats '%m'
+vi-f () {
hook_com[guards]+=XXX
}
The regression was first released in 5.3.1-test-2, over three years ago.
|
|
|
|
|
|
|
|
| |
"Topics" is an experimental concept in Mercurial that augments the
current branching concept (called "named branches").
For more information, see the not always up-to-date Mercurial Wiki page
https://www.mercurial-scm.org/wiki/TopicPlan.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen-applied-string hook information on already-applied patches.
The hook already receives information about the current (topmost
applied) patch and, if the get-unapplied style is set, about future
(unapplied) patches.
Tested in the Functions/VCS_Info/test-repo-git-rebase-apply scenario,
after manually converting the rebase to a «git am». (Specifically,
I ran:
mkdir d
git rebase --abort
git format-patch rebase_from_this..HEAD -o d
git checkout rebase_onto_this
git am d/*
.)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
unapplied patches.
|
|
|
|
|
|
|
| |
arguments like gen-applied-string arguments are processed.
I consider this a bugfix, since it's unexpected for -applied and
-unapplied to differ about this.
|
|
|
|
|
|
|
|
|
|
| |
of the "exec" verb.
The code before this commit happened to have done the right thing:
"exec" lines were handled by the catchall forward compatibility case,
which happened to have had virtually the same effect as the correct
case. However, that was merely an accidental result. This patch makes
the code do the right thing deliberately, rather than by accident.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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).
|