| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
|
|
|
|
(Similar to git detached heads)
|
|
git-am also uses .git/rebase-apply for patch list but
the file original-commit does not exist (as no commit exist).
This patch handles both git rebase and git am. Also:
- get the first line (rather than the first char) when the message
contains only one line;
- remove unused function (ironically that should have been used here).
|
|
This will detect changes to submodules from the superproject's
perspective, e.g. after `git rm submodule`.
>From GIT-DIFF-INDEX(1)/GIT-DIFF(1):
Using "dirty" ignores all changes to the work tree of submodules,
only changes to the commits stored in the superproject are shown
(this was the behavior until 1.7.0).
|
|
Since a rebase contains a list of patches to re-apply, re-use the
facility for stgit to have the same mechanism.
The patch list given to the gen-{un,}applied-string hooks is an array
with the sha1 and the subject of the commit. On rebase merge, the
applied patches prior to current contains only a number and "?".
|
|
This would fix handling get-revision, check-for-changes or
check-for-staged-changes when set per repository.
|
