The style was treated as "always true" rather than as "settable, false
by default" in the rebase-merge and cherry-pick cases. This affects the
gen-unapplied-string hook, and may also affect gen-applied-string and
set-patch-format hooks if they accessed VCS_INFO_get_data_git's internal
parameters directly.
If this affects you, just set the style in your zshrc:
.
zstyle ':vcs_info:git*:*:*' get-unapplied true
The vcs_info patch detection code attempted to interrogate StGit patch
stack state by inspecting .git/patches/applied and
.git/patches/unapplied.
As of StGit 0.15 (2009), patch stack metadata is captured in the repo's
object database. And as of StGit 1.0 (2021), no stack or patch state is
maintained in any files in the .git/ directory.
Zsh's approach for interrogating StGit patch state is thus obsoleted.
This patch updates vcs_info to determine whether StGit is initialized on a
branch by looking at the appropriate git refs and uses StGit's prescribed
interface for interrogating applied and unapplied patch state via the `stg
series` command. This approach will work with all versions of StGit >=0.15.
Signed-off-by: Peter Grayson <pete@jpgrayson.net>
For instance, with 4 applied patches, 5 unapplied patches, and no guards
involved, the patch-format style would indicate 9 (= 4+5) unapplied patches
and 4 applied patches.
This affects the post-quilt hook. Before this patch, if no patches have
been applied and get-unapplied hasn't been set, the second argument to
that hook would undergo null elision.
The generation of patch subjects for the gen-applied-string,
gen-unapplied-string, and set-patch-format hooks was unaffected since
it was guarded by [[ -n $patches ]].
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.
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/*
.)
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.
Additional lines between the |-separated header line and the actual
log message, as generated by 'svn log -v' and 'svn log -g', are now
supported.
This change affects you if you have quilt patches with 'svn log'-style
information in their headers, regardless of whether you use quilt
standalone, quilt over svn, or quilt over some other VCS.
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.
