* [PATCH 02/12] completion: wrap __git_refs() for better option parsing
From: SZEDER Gábor @ 2017-02-03 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
__git_refs() currently accepts two optional positional parameters: a
remote and a flag for 'git checkout's tracking DWIMery. To fix a
minor bug, and, more importantly, for faster refs completion, this
series will add three more parameters: a prefix, the current word to
be completed and a suffix, i.e. the options accepted by __gitcomp() &
friends, and will change __git_refs() to list only refs matching that
given current word and to add that given prefix and suffix to the
listed refs.
However, __git_refs() is the helper function that is most likely used
in users' custom completion scriptlets for their own git commands, and
we don't want to break those, so
- we can't change __git_refs()'s default output format, i.e. we
can't by default append a trailing space to every listed ref,
meaning that the suffix parameter containing the default trailing
space would have to be specified on every invocation, and
- we can't change the position of existing positional parameters
either, so there would have to be plenty of set-but-empty
placeholder positional parameters all over the completion script.
Furthermore, with five positional parameters it would be really hard
to remember which position means what.
To keep callsites simple, add the new wrapper function
__git_complete_refs() around __git_refs(), which:
- instead of positional parameters accepts real '--opt=val'-style
options and with minimalistic option parsing translates them to
__git_refs()'s and __gitcomp_nl()'s positional parameters, and
- includes the '__gitcomp_nl "$(__git_refs ...)" ...' command
substitution to make its behavior match its name and the behavior
of other __git_complete_* functions, and to limit future changes
in this series to __git_refs() and this new wrapper function.
Call this wrapper function instead of __git_refs() wherever possible
throughout the completion script, i.e. when __git_refs()'s output is
fed to __gitcomp_nl() right away without further processing, which
means all callsites except a single one in the __git_refs2() helper.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 102 ++++++++++++++++++++-----------
t/t9902-completion.sh | 106 +++++++++++++++++++++++++++++++++
2 files changed, 173 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f20d4600c..7f19e2a4f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -354,6 +354,8 @@ __git_tags ()
# Can be the name of a configured remote, a path, or a URL.
# 2: In addition to local refs, list unique branches from refs/remotes/ for
# 'git checkout's tracking DWIMery (optional; ignored, if set but empty).
+#
+# Use __git_complete_refs() instead.
__git_refs ()
{
local i hash dir track="${2-}"
@@ -446,6 +448,36 @@ __git_refs ()
esac
}
+# Completes refs, short and long, local and remote, symbolic and pseudo.
+#
+# Usage: __git_complete_refs [<option>]...
+# --remote=<remote>: The remote to list refs from, can be the name of a
+# configured remote, a path, or a URL.
+# --track: List unique remote branches for 'git checkout's tracking DWIMery.
+# --pfx=<prefix>: A prefix to be added to each ref.
+# --cur=<word>: The current ref to be completed. Defaults to the current
+# word to be completed.
+# --sfx=<suffix>: A suffix to be appended to each ref instead of the default
+# space.
+__git_complete_refs ()
+{
+ local remote track pfx cur_="$cur" sfx=" "
+
+ while test $# != 0; do
+ case "$1" in
+ --remote=*) remote="${1##--remote=}" ;;
+ --track) track="yes" ;;
+ --pfx=*) pfx="${1##--pfx=}" ;;
+ --cur=*) cur_="${1##--cur=}" ;;
+ --sfx=*) sfx="${1##--sfx=}" ;;
+ *) return 1 ;;
+ esac
+ shift
+ done
+
+ __gitcomp_nl "$(__git_refs "$remote" "$track")" "$pfx" "$cur_" "$sfx"
+}
+
# __git_refs2 requires 1 argument (to pass to __git_refs)
__git_refs2 ()
{
@@ -554,15 +586,15 @@ __git_complete_revlist_file ()
*...*)
pfx="${cur_%...*}..."
cur_="${cur_#*...}"
- __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
+ __git_complete_refs --pfx="$pfx" --cur="$cur_"
;;
*..*)
pfx="${cur_%..*}.."
cur_="${cur_#*..}"
- __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
+ __git_complete_refs --pfx="$pfx" --cur="$cur_"
;;
*)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
esac
}
@@ -649,21 +681,21 @@ __git_complete_remote_or_refspec ()
if [ $lhs = 1 ]; then
__gitcomp_nl "$(__git_refs2 "$remote")" "$pfx" "$cur_"
else
- __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
+ __git_complete_refs --pfx="$pfx" --cur="$cur_"
fi
;;
pull|remote)
if [ $lhs = 1 ]; then
- __gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
+ __git_complete_refs --remote="$remote" --pfx="$pfx" --cur="$cur_"
else
- __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
+ __git_complete_refs --pfx="$pfx" --cur="$cur_"
fi
;;
push)
if [ $lhs = 1 ]; then
- __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
+ __git_complete_refs --pfx="$pfx" --cur="$cur_"
else
- __gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
+ __git_complete_refs --remote="$remote" --pfx="$pfx" --cur="$cur_"
fi
;;
esac
@@ -1061,7 +1093,7 @@ _git_bisect ()
case "$subcommand" in
bad|good|reset|skip|start)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
*)
;;
@@ -1083,7 +1115,7 @@ _git_branch ()
case "$cur" in
--set-upstream-to=*)
- __gitcomp_nl "$(__git_refs)" "" "${cur##--set-upstream-to=}"
+ __git_complete_refs --cur="${cur##--set-upstream-to=}"
;;
--*)
__gitcomp "
@@ -1097,7 +1129,7 @@ _git_branch ()
if [ $only_local_ref = "y" -a $has_r = "n" ]; then
__gitcomp_nl "$(__git_heads)"
else
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
fi
;;
esac
@@ -1140,18 +1172,18 @@ _git_checkout ()
*)
# check if --track, --no-track, or --no-guess was specified
# if so, disable DWIM mode
- local flags="--track --no-track --no-guess" track=1
+ local flags="--track --no-track --no-guess" track_opt="--track"
if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
- track=''
+ track_opt=''
fi
- __gitcomp_nl "$(__git_refs '' $track)"
+ __git_complete_refs $track_opt
;;
esac
}
_git_cherry ()
{
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_cherry_pick ()
@@ -1166,7 +1198,7 @@ _git_cherry_pick ()
__gitcomp "--edit --no-commit --signoff --strategy= --mainline"
;;
*)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
esac
}
@@ -1216,7 +1248,7 @@ _git_commit ()
{
case "$prev" in
-c|-C)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
return
;;
esac
@@ -1229,7 +1261,7 @@ _git_commit ()
;;
--reuse-message=*|--reedit-message=*|\
--fixup=*|--squash=*)
- __gitcomp_nl "$(__git_refs)" "" "${cur#*=}"
+ __git_complete_refs --cur="${cur#*=}"
return
;;
--untracked-files=*)
@@ -1267,7 +1299,7 @@ _git_describe ()
"
return
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
__git_diff_algorithms="myers minimal patience histogram"
@@ -1453,7 +1485,7 @@ _git_grep ()
;;
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_help ()
@@ -1621,7 +1653,7 @@ _git_merge ()
--rerere-autoupdate --no-rerere-autoupdate --abort --continue"
return
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_mergetool ()
@@ -1646,7 +1678,7 @@ _git_merge_base ()
return
;;
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_mv ()
@@ -1684,7 +1716,7 @@ _git_notes ()
,*)
case "$prev" in
--ref)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
*)
__gitcomp "$subcommands --ref"
@@ -1693,7 +1725,7 @@ _git_notes ()
;;
add,--reuse-message=*|append,--reuse-message=*|\
add,--reedit-message=*|append,--reedit-message=*)
- __gitcomp_nl "$(__git_refs)" "" "${cur#*=}"
+ __git_complete_refs --cur="${cur#*=}"
;;
add,--*|append,--*)
__gitcomp '--file= --message= --reedit-message=
@@ -1712,7 +1744,7 @@ _git_notes ()
-m|-F)
;;
*)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
esac
;;
@@ -1750,10 +1782,10 @@ __git_complete_force_with_lease ()
--*=)
;;
*:*)
- __gitcomp_nl "$(__git_refs)" "" "${cur_#*:}"
+ __git_complete_refs --cur="${cur_#*:}"
;;
*)
- __gitcomp_nl "$(__git_refs)" "" "$cur_"
+ __git_complete_refs --cur="$cur_"
;;
esac
}
@@ -1829,7 +1861,7 @@ _git_rebase ()
return
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_reflog ()
@@ -1840,7 +1872,7 @@ _git_reflog ()
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
else
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
fi
}
@@ -1986,7 +2018,7 @@ _git_config ()
return
;;
branch.*.merge)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
return
;;
branch.*.rebase)
@@ -2460,7 +2492,7 @@ _git_remote ()
_git_replace ()
{
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_reset ()
@@ -2473,7 +2505,7 @@ _git_reset ()
return
;;
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_revert ()
@@ -2489,7 +2521,7 @@ _git_revert ()
return
;;
esac
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
}
_git_rm ()
@@ -2597,7 +2629,7 @@ _git_stash ()
;;
branch,*)
if [ $cword -eq 3 ]; then
- __gitcomp_nl "$(__git_refs)";
+ __git_complete_refs
else
__gitcomp_nl "$(__git stash list \
| sed -n -e 's/:.*//p')"
@@ -2755,7 +2787,7 @@ _git_tag ()
fi
;;
*)
- __gitcomp_nl "$(__git_refs)"
+ __git_complete_refs
;;
esac
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index d711bef24..50c534072 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -775,6 +775,112 @@ test_expect_success '__git_refs - unique remote branches for git checkout DWIMer
test_cmp expected "$actual"
'
+test_expect_success '__git_complete_refs - simple' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ HEAD Z
+ master Z
+ matching-branch Z
+ other/branch-in-other Z
+ other/master-in-other Z
+ matching-tag Z
+ EOF
+ (
+ cur= &&
+ __git_complete_refs &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - matching' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ matching-branch Z
+ matching-tag Z
+ EOF
+ (
+ cur=mat &&
+ __git_complete_refs &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - remote' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ HEAD Z
+ branch-in-other Z
+ master-in-other Z
+ EOF
+ (
+ cur=
+ __git_complete_refs --remote=other &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - track' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ HEAD Z
+ master Z
+ matching-branch Z
+ other/branch-in-other Z
+ other/master-in-other Z
+ matching-tag Z
+ branch-in-other Z
+ master-in-other Z
+ EOF
+ (
+ cur=
+ __git_complete_refs --track &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - current word' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ matching-branch Z
+ matching-tag Z
+ EOF
+ (
+ cur="--option=mat" &&
+ __git_complete_refs --cur="${cur#*=}" &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - prefix' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ v1.0..matching-branch Z
+ v1.0..matching-tag Z
+ EOF
+ (
+ cur=v1.0..mat &&
+ __git_complete_refs --pfx=v1.0.. --cur=mat &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
+test_expect_success '__git_complete_refs - suffix' '
+ cat >expected <<-EOF &&
+ HEAD.
+ master.
+ matching-branch.
+ other/branch-in-other.
+ other/master-in-other.
+ matching-tag.
+ EOF
+ (
+ cur= &&
+ __git_complete_refs --sfx=. &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
test_expect_success 'teardown after ref completion' '
git branch -d matching-branch &&
git tag -d matching-tag &&
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 07/12] completion: let 'for-each-ref' and 'ls-remote' filter matching refs
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
When completing refs, several __git_refs() code paths list all the
refs from the refs/{heads,tags,remotes}/ hierarchy and then
__gitcomp_nl() iterates over those refs in a shell loop to filter out
refs not matching the current word to be completed. This comes with a
considerable performance penalty when a repository contains a lot of
refs but the current word can be uniquely completed or when only a
handful of refs match the current word.
Specify appropriate globbing patterns to 'git for-each-ref' and 'git
ls-remote' to list only those refs that match the current word to be
completed. This reduces the number of iterations in __gitcomp_nl()
from the number of refs to the number of matching refs.
This speeds up refs completion considerably when there are a lot of
non-matching refs to be filtered out. Uniquely completing a branch in
a repository with 100k local branches, all packed, best of five:
On Linux, before:
$ time __git_complete_refs --cur=maste
real 0m0.831s
user 0m0.808s
sys 0m0.028s
After:
real 0m0.119s
user 0m0.104s
sys 0m0.008s
On Windows, before:
real 0m1.480s
user 0m1.031s
sys 0m0.060s
After:
real 0m0.377s
user 0m0.015s
sys 0m0.030s
Strictly speaking this is a fundamental behavior change in
__git_refs(), a helper function that is likely used in users' custom
completion scriptlets. However, arguably this change should be
harmless, because:
- __git_refs() was only ever intended to feed refs to Bash's
completion machinery, for which non-matching refs have to be
filtered out anyway.
- There were already code paths that list only matching refs
(listing unique remote branches for 'git checkout's tracking
DWIMery and listing full remote refs via 'git ls-remote').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 14 +++--
t/t9902-completion.sh | 102 +++++++++++++++++++++++++++++++++
2 files changed, 111 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d55eadfd1..615292f8b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -394,7 +394,7 @@ __git_refs ()
case "$cur_" in
refs|refs/*)
format="refname"
- refs="${cur_%/*}"
+ refs=("$cur_*" "$cur_*/**")
track=""
;;
*)
@@ -402,11 +402,13 @@ __git_refs ()
if [ -e "$dir/$i" ]; then echo $pfx$i; fi
done
format="refname:strip=2"
- refs="refs/tags refs/heads refs/remotes"
+ refs=("refs/tags/$cur_*" "refs/tags/$cur_*/**"
+ "refs/heads/$cur_*" "refs/heads/$cur_*/**"
+ "refs/remotes/$cur_*" "refs/remotes/$cur_*/**")
;;
esac
__git_dir="$dir" __git for-each-ref --format="$pfx%($format)" \
- $refs
+ "${refs[@]}"
if [ -n "$track" ]; then
# employ the heuristic used by git checkout
# Try to find a remote branch that matches the completion word
@@ -438,10 +440,12 @@ __git_refs ()
if [ "$list_refs_from" = remote ]; then
echo "HEAD"
__git for-each-ref --format="%(refname:strip=2)" \
- "refs/remotes/$remote/" | sed -e "s#^$remote/##"
+ "refs/remotes/$remote/$cur_*" \
+ "refs/remotes/$remote/$cur_*/**" | sed -e "s#^$remote/##"
else
__git ls-remote "$remote" HEAD \
- "refs/tags/*" "refs/heads/*" "refs/remotes/*" |
+ "refs/tags/$cur_*" "refs/heads/$cur_*" \
+ "refs/remotes/$cur_*" |
while read -r hash i; do
case "$i" in
*^{}) ;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 7b42a686c..499be5879 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -837,6 +837,108 @@ test_expect_success '__git refs - exluding full refs' '
test_cmp expected "$actual"
'
+test_expect_success 'setup for filtering matching refs' '
+ git branch matching/branch &&
+ git tag matching/tag &&
+ git -C otherrepo branch matching/branch-in-other &&
+ git fetch --no-tags other &&
+ rm -f .git/FETCH_HEAD
+'
+
+test_expect_success '__git_refs - only matching refs' '
+ cat >expected <<-EOF &&
+ HEAD
+ matching-branch
+ matching/branch
+ matching-tag
+ matching/tag
+ EOF
+ (
+ cur=mat &&
+ __git_refs >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - only matching refs - full refs' '
+ cat >expected <<-EOF &&
+ refs/heads/matching-branch
+ refs/heads/matching/branch
+ EOF
+ (
+ cur=refs/heads/mat &&
+ __git_refs >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - only matching refs - remote on local file system' '
+ cat >expected <<-EOF &&
+ HEAD
+ master-in-other
+ matching/branch-in-other
+ EOF
+ (
+ cur=ma &&
+ __git_refs otherrepo >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - only matching refs - configured remote' '
+ cat >expected <<-EOF &&
+ HEAD
+ master-in-other
+ matching/branch-in-other
+ EOF
+ (
+ cur=ma &&
+ __git_refs other >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - only matching refs - remote - full refs' '
+ cat >expected <<-EOF &&
+ refs/heads/master-in-other
+ refs/heads/matching/branch-in-other
+ EOF
+ (
+ cur=refs/heads/ma &&
+ __git_refs other >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - only matching refs - checkout DWIMery' '
+ cat >expected <<-EOF &&
+ HEAD
+ matching-branch
+ matching/branch
+ matching-tag
+ matching/tag
+ matching/branch-in-other
+ EOF
+ for remote_ref in refs/remotes/other/ambiguous \
+ refs/remotes/remote/ambiguous \
+ refs/remotes/remote/branch-in-remote
+ do
+ git update-ref $remote_ref master &&
+ test_when_finished "git update-ref -d $remote_ref"
+ done &&
+ (
+ cur=mat &&
+ __git_refs "" 1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'teardown after filtering matching refs' '
+ git branch -d matching/branch &&
+ git tag -d matching/tag &&
+ git update-ref -d refs/remotes/other/matching/branch-in-other
+'
+
test_expect_success '__git_complete_refs - simple' '
sed -e "s/Z$//g" >expected <<-EOF &&
HEAD Z
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 03/12] completion: support completing full refs after '--option=refs/<TAB>'
From: SZEDER Gábor @ 2017-02-03 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
Completing full refs currently only works when the full ref stands on
in its own on the command line, but doesn't work when the current word
to be completed contains a prefix before the full ref, e.g.
'--option=refs/<TAB>' or 'master..refs/bis<TAB>'.
The reason is that __git_refs() looks at the current word to be
completed ($cur) as a whole to decide whether it has to list full (if
it starts with 'refs/') or short refs (otherwise). However, $cur also
holds said '--option=' or 'master..' prefixes, which of course throw
off this decision. Luckily, the default action is to list short refs,
that's why completing short refs happens to work even after a
'master..<TAB>' prefix and similar cases.
Pass only the ref part of the current word to be completed to
__git_refs() as a new positional parameter, so it can make the right
decision even if the whole current word contains some kind of a
prefix.
Make this new parameter the 4. positional parameter and leave the 3.
as an ignored placeholder for now (it will be used later in this patch
series).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 21 ++++++++++++++-------
t/t9902-completion.sh | 31 +++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 7f19e2a4f..67a03cfd4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -354,6 +354,8 @@ __git_tags ()
# Can be the name of a configured remote, a path, or a URL.
# 2: In addition to local refs, list unique branches from refs/remotes/ for
# 'git checkout's tracking DWIMery (optional; ignored, if set but empty).
+# 3: Currently ignored.
+# 4: The current ref to be completed (optional).
#
# Use __git_complete_refs() instead.
__git_refs ()
@@ -361,6 +363,7 @@ __git_refs ()
local i hash dir track="${2-}"
local list_refs_from=path remote="${1-}"
local format refs pfx
+ local cur_="${4-$cur}"
__git_find_repo_path
dir="$__git_repo_path"
@@ -384,14 +387,17 @@ __git_refs ()
fi
if [ "$list_refs_from" = path ]; then
- case "$cur" in
+ case "$cur_" in
refs|refs/*)
format="refname"
- refs="${cur%/*}"
+ refs="${cur_%/*}"
track=""
;;
*)
- [[ "$cur" == ^* ]] && pfx="^"
+ if [[ "$cur_" == ^* ]]; then
+ pfx="^"
+ cur_=${cur_#^}
+ fi
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
if [ -e "$dir/$i" ]; then echo $pfx$i; fi
done
@@ -411,16 +417,16 @@ __git_refs ()
while read -r entry; do
eval "$entry"
ref="${ref#*/}"
- if [[ "$ref" == "$cur"* ]]; then
+ if [[ "$ref" == "$cur_"* ]]; then
echo "$ref"
fi
done | sort | uniq -u
fi
return
fi
- case "$cur" in
+ case "$cur_" in
refs|refs/*)
- __git ls-remote "$remote" "$cur*" | \
+ __git ls-remote "$remote" "$cur_*" | \
while read -r hash i; do
case "$i" in
*^{}) ;;
@@ -475,7 +481,8 @@ __git_complete_refs ()
shift
done
- __gitcomp_nl "$(__git_refs "$remote" "$track")" "$pfx" "$cur_" "$sfx"
+ __gitcomp_nl "$(__git_refs "$remote" "$track" "" "$cur_")" \
+ "$pfx" "$cur_" "$sfx"
}
# __git_refs2 requires 1 argument (to pass to __git_refs)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 50c534072..8fe748839 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -775,6 +775,37 @@ test_expect_success '__git_refs - unique remote branches for git checkout DWIMer
test_cmp expected "$actual"
'
+test_expect_success '__git_refs - after --opt=' '
+ cat >expected <<-EOF &&
+ HEAD
+ master
+ matching-branch
+ other/branch-in-other
+ other/master-in-other
+ matching-tag
+ EOF
+ (
+ cur="--opt=" &&
+ __git_refs "" "" "" "" >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git_refs - after --opt= - full refs' '
+ cat >expected <<-EOF &&
+ refs/heads/master
+ refs/heads/matching-branch
+ refs/remotes/other/branch-in-other
+ refs/remotes/other/master-in-other
+ refs/tags/matching-tag
+ EOF
+ (
+ cur="--opt=refs/" &&
+ __git_refs "" "" "" refs/ >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
test_expect_success '__git_complete_refs - simple' '
sed -e "s/Z$//g" >expected <<-EOF &&
HEAD Z
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 08/12] completion: let 'for-each-ref' strip the remote name from remote branches
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
The code listing unique remote branches for 'git checkout's tracking
DWIMery uses a shell parameter expansion in a loop iterating over each
listed ref to remove the remote's name from the remote branches, i.e.
the leading path component from the short ref. When listing refs from
a configured remote repository, '| sed s///' is used for the same
purpose.
Let 'git for-each-ref' strip one more leading path component from the
refs, i.e. use the format 'refname:strip=3' instead of '=2', making
that parameter expansion and 'sed' execution unnecessary.
This speeds up refs completion for 'git checkout'. Uniquely
completing a branch for 'git checkout maste<TAB>' in a repo with 100k
remote branches, all packed, best of five:
On Linux, near the beginning of this series, for reference:
$ time __git_complete_refs --cur=maste --track
real 0m8.185s
user 0m6.896s
sys 0m1.616s
Before this patch:
real 0m2.714s
user 0m2.344s
sys 0m0.436s
After:
real 0m1.993s
user 0m1.740s
sys 0m0.304s
On Windows, near the beginning:
real 1m8.421s
user 0m7.591s
sys 0m3.557s
Before this patch:
real 0m8.191s
user 0m4.638s
sys 0m2.918s
After:
real 0m6.187s
user 0m3.358s
sys 0m2.121s
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 615292f8b..8f1203025 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -414,11 +414,10 @@ __git_refs ()
# Try to find a remote branch that matches the completion word
# but only output if the branch name is unique
local ref entry
- __git for-each-ref --shell --format="ref=%(refname:strip=2)" \
+ __git for-each-ref --shell --format="ref=%(refname:strip=3)" \
"refs/remotes/" | \
while read -r entry; do
eval "$entry"
- ref="${ref#*/}"
if [[ "$ref" == "$cur_"* ]]; then
echo "$ref"
fi
@@ -439,9 +438,9 @@ __git_refs ()
*)
if [ "$list_refs_from" = remote ]; then
echo "HEAD"
- __git for-each-ref --format="%(refname:strip=2)" \
+ __git for-each-ref --format="%(refname:strip=3)" \
"refs/remotes/$remote/$cur_*" \
- "refs/remotes/$remote/$cur_*/**" | sed -e "s#^$remote/##"
+ "refs/remotes/$remote/$cur_*/**"
else
__git ls-remote "$remote" HEAD \
"refs/tags/$cur_*" "refs/heads/$cur_*" \
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 12/12] completion: fill COMPREPLY directly when completing refs
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
__gitcomp_nl() iterates over all the possible completion words it gets
as argument
- filtering matching words,
- appending a trailing space to each matching word (in all but two
cases),
- prepending a prefix to each matching word (when completing words
after e.g. '--option=<TAB>' or 'master..<TAB>'), and
- adding each matching word to the COMPREPLY array.
This takes a while when a lot of refs are passed to __gitcomp_nl().
The previous changes in this series ensure that __git_refs() lists
only refs matching the current word to be completed, making a second
filtering in __gitcomp_nl() redundant.
Adding the necessary prefix and suffix could be done in __git_refs()
as well:
- When refs come from 'git for-each-ref', then that prefix and
suffix could be added much more efficiently using a 'git
for-each-ref' format containing said prefix and suffix.
- When refs come from 'git ls-remote', then that prefix and suffix
can be added in the shell loop that has to process 'git
ls-remote's output anyway.
- Finally, the prefix and suffix can be added to that handful of
potentially matching symbolic and pseudo refs right away in the
shell loop listing them.
And then all what is still left to do is to assign a bunch of
newline-separated words to a shell array, which can be done without a
shell loop iterating over each word, basically making all of
__gitcomp_nl() unnecessary for refs completion.
Add the helper function __gitcomp_direct() to fill the COMPREPLY array
with prefiltered and preprocessed words without any additional
processing, without a shell loop, with just one single compound
assignment. Modify __git_refs() to accept prefix and suffix
parameters and add them to each and every listed ref. Modify
__git_complete_refs() to pass the prefix and suffix parameters to
__git_refs() and to feed __git_refs()'s output to __gitcomp_direct()
instead of __gitcomp_nl().
This speeds up refs completion when there are a lot of refs matching
the current word to be completed. Listing all branches for completion
in a repo with 100k local branches, all packed, best of five:
On Linux, near the beginning of this series, for reference:
$ time __git_complete_refs
real 0m2.028s
user 0m1.692s
sys 0m0.344s
Before this patch:
real 0m1.135s
user 0m1.112s
sys 0m0.024s
After:
real 0m0.367s
user 0m0.352s
sys 0m0.020s
On Windows, near the beginning:
real 0m13.078s
user 0m1.609s
sys 0m0.060s
Before this patch:
real 0m2.093s
user 0m1.641s
sys 0m0.060s
After:
real 0m0.683s
user 0m0.203s
sys 0m0.076s
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 54 ++++++++++++++++++++++++----------
contrib/completion/git-completion.zsh | 9 ++++++
t/t9902-completion.sh | 16 ++++++++++
3 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0ad02cec6..dbbb62f5f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -213,6 +213,20 @@ _get_comp_words_by_ref ()
}
fi
+# Fills the COMPREPLY array with prefiltered words without any additional
+# processing.
+# Callers must take care of providing only words that match the current word
+# to be completed and adding any prefix and/or suffix (trailing space!), if
+# necessary.
+# 1: List of newline-separated matching completion words, complete with
+# prefix and suffix.
+__gitcomp_direct ()
+{
+ local IFS=$'\n'
+
+ COMPREPLY=($1)
+}
+
__gitcompappend ()
{
local x i=${#COMPREPLY[@]}
@@ -354,17 +368,19 @@ __git_tags ()
# Can be the name of a configured remote, a path, or a URL.
# 2: In addition to local refs, list unique branches from refs/remotes/ for
# 'git checkout's tracking DWIMery (optional; ignored, if set but empty).
-# 3: Currently ignored.
+# 3: A prefix to be added to each listed ref (optional).
# 4: List only refs matching this word instead of the current word being
-# completed (optional).
+# completed (optional; NOT ignored, if empty, but lists all refs).
+# 5: A suffix to be appended to each listed ref (optional; ignored, if set
+# but empty).
#
# Use __git_complete_refs() instead.
__git_refs ()
{
local i hash dir track="${2-}"
local list_refs_from=path remote="${1-}"
- local format refs pfx
- local cur_="${4-$cur}"
+ local format refs
+ local pfx="${3-}" cur_="${4-$cur}" sfx="${5-}"
__git_find_repo_path
dir="$__git_repo_path"
@@ -389,7 +405,7 @@ __git_refs ()
if [ "$list_refs_from" = path ]; then
if [[ "$cur_" == ^* ]]; then
- pfx="^"
+ pfx="$pfx^"
cur_=${cur_#^}
fi
case "$cur_" in
@@ -402,7 +418,7 @@ __git_refs ()
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
case "$i" in
$cur_*) if [ -e "$dir/$i" ]; then
- echo $pfx$i
+ echo "$pfx$i$sfx"
fi
;;
esac
@@ -413,13 +429,13 @@ __git_refs ()
"refs/remotes/$cur_*" "refs/remotes/$cur_*/**")
;;
esac
- __git_dir="$dir" __git for-each-ref --format="$pfx%($format)" \
+ __git_dir="$dir" __git for-each-ref --format="$pfx%($format)$sfx" \
"${refs[@]}"
if [ -n "$track" ]; then
# employ the heuristic used by git checkout
# Try to find a remote branch that matches the completion word
# but only output if the branch name is unique
- __git for-each-ref --format="%(refname:strip=3)" \
+ __git for-each-ref --format="$pfx%(refname:strip=3)$sfx" \
--sort="refname:strip=3" \
"refs/remotes/*/$cur_*" "refs/remotes/*/$cur_*/**" | \
uniq -u
@@ -432,16 +448,16 @@ __git_refs ()
while read -r hash i; do
case "$i" in
*^{}) ;;
- *) echo "$i" ;;
+ *) echo "$pfx$i$sfx" ;;
esac
done
;;
*)
if [ "$list_refs_from" = remote ]; then
case "HEAD" in
- $cur_*) echo "HEAD" ;;
+ $cur_*) echo "${pfx}HEAD$sfx" ;;
esac
- __git for-each-ref --format="%(refname:strip=3)" \
+ __git for-each-ref --format="$pfx%(refname:strip=3)$sfx" \
"refs/remotes/$remote/$cur_*" \
"refs/remotes/$remote/$cur_*/**"
else
@@ -455,8 +471,8 @@ __git_refs ()
while read -r hash i; do
case "$i" in
*^{}) ;;
- refs/*) echo "${i#refs/*/}" ;;
- *) echo "$i" ;; # symbolic refs
+ refs/*) echo "$pfx${i#refs/*/}$sfx" ;;
+ *) echo "$pfx$i$sfx" ;; # symbolic refs
esac
done
fi
@@ -491,8 +507,7 @@ __git_complete_refs ()
shift
done
- __gitcomp_nl "$(__git_refs "$remote" "$track" "" "$cur_")" \
- "$pfx" "$cur_" "$sfx"
+ __gitcomp_direct "$(__git_refs "$remote" "$track" "$pfx" "$cur_" "$sfx")"
}
# __git_refs2 requires 1 argument (to pass to __git_refs)
@@ -2975,6 +2990,15 @@ if [[ -n ${ZSH_VERSION-} ]]; then
esac
}
+ __gitcomp_direct ()
+ {
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -- ${=1} && _ret=0
+ }
+
__gitcomp_nl ()
{
emulate -L zsh
diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
index e25541308..c3521fbfc 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -67,6 +67,15 @@ __gitcomp ()
esac
}
+__gitcomp_direct ()
+{
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -- ${=1} && _ret=0
+}
+
__gitcomp_nl ()
{
emulate -L zsh
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 5e06acc17..1206a38ed 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -400,6 +400,22 @@ test_expect_success '__gitdir - remote as argument' '
test_cmp expected "$actual"
'
+test_expect_success '__gitcomp_direct - puts everything into COMPREPLY as-is' '
+ sed -e "s/Z$//g" >expected <<-EOF &&
+ with-trailing-space Z
+ without-trailing-spaceZ
+ --option Z
+ --option=Z
+ $invalid_variable_name Z
+ EOF
+ (
+ cur=should_be_ignored &&
+ __gitcomp_direct "$(cat expected)" &&
+ print_comp
+ ) &&
+ test_cmp expected out
+'
+
test_expect_success '__gitcomp - trailing space - options' '
test_gitcomp "--re" "--dry-run --reuse-message= --reedit-message=
--reset-author" <<-EOF
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 10/12] completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
When listing unique remote branches for 'git checkout's tracking
DWIMery, __git_refs() runs the classic '... |sort |uniq -u' pattern to
filter out duplicate remote branches.
Let 'git for-each-ref' do the sorting, sparing the overhead of
fork()+exec()ing 'sort' and a stage in the pipeline where potentially
relatively large amount of data can be passed between two subsequent
pipeline stages.
This speeds up refs completion for 'git checkout' a bit when a lot of
remote branches match the current word to be completed. Listing a
single local and 100k remote branches, all packed, best of five:
On Linux, before:
$ time __git_complete_refs --track
real 0m1.856s
user 0m1.816s
sys 0m0.060s
After:
real 0m1.550s
user 0m1.512s
sys 0m0.060s
On Windows, before:
real 0m3.128s
user 0m2.155s
sys 0m0.183s
After:
real 0m2.781s
user 0m1.826s
sys 0m0.136s
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e2c4794f3..9f5a6f44e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -414,8 +414,9 @@ __git_refs ()
# Try to find a remote branch that matches the completion word
# but only output if the branch name is unique
__git for-each-ref --format="%(refname:strip=3)" \
+ --sort="refname:strip=3" \
"refs/remotes/*/$cur_*" "refs/remotes/*/$cur_*/**" | \
- sort | uniq -u
+ uniq -u
fi
return
fi
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 11/12] completion: list only matching symbolic and pseudorefs when completing refs
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
The previous changes in this series ensure that __git_refs() lists
only refs that match the current word to be completed, but
non-matching symbolic and pseudo refs still show up in its output.
Filter out non-matching symbolic and pseudo refs as well, so anything
__git_refs() outputs matches the current word to be completed, as it
will allow us to optimize how refs are placed into the COMPREPLY
array.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 20 ++++++++++++++++----
t/t9902-completion.sh | 4 ----
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9f5a6f44e..0ad02cec6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -355,7 +355,8 @@ __git_tags ()
# 2: In addition to local refs, list unique branches from refs/remotes/ for
# 'git checkout's tracking DWIMery (optional; ignored, if set but empty).
# 3: Currently ignored.
-# 4: The current ref to be completed (optional).
+# 4: List only refs matching this word instead of the current word being
+# completed (optional).
#
# Use __git_complete_refs() instead.
__git_refs ()
@@ -399,7 +400,12 @@ __git_refs ()
;;
*)
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
- if [ -e "$dir/$i" ]; then echo $pfx$i; fi
+ case "$i" in
+ $cur_*) if [ -e "$dir/$i" ]; then
+ echo $pfx$i
+ fi
+ ;;
+ esac
done
format="refname:strip=2"
refs=("refs/tags/$cur_*" "refs/tags/$cur_*/**"
@@ -432,12 +438,18 @@ __git_refs ()
;;
*)
if [ "$list_refs_from" = remote ]; then
- echo "HEAD"
+ case "HEAD" in
+ $cur_*) echo "HEAD" ;;
+ esac
__git for-each-ref --format="%(refname:strip=3)" \
"refs/remotes/$remote/$cur_*" \
"refs/remotes/$remote/$cur_*/**"
else
- __git ls-remote "$remote" HEAD \
+ local query_symref
+ case "HEAD" in
+ $cur_*) query_symref="HEAD" ;;
+ esac
+ __git ls-remote "$remote" $query_symref \
"refs/tags/$cur_*" "refs/heads/$cur_*" \
"refs/remotes/$cur_*" |
while read -r hash i; do
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 499be5879..5e06acc17 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -847,7 +847,6 @@ test_expect_success 'setup for filtering matching refs' '
test_expect_success '__git_refs - only matching refs' '
cat >expected <<-EOF &&
- HEAD
matching-branch
matching/branch
matching-tag
@@ -874,7 +873,6 @@ test_expect_success '__git_refs - only matching refs - full refs' '
test_expect_success '__git_refs - only matching refs - remote on local file system' '
cat >expected <<-EOF &&
- HEAD
master-in-other
matching/branch-in-other
EOF
@@ -887,7 +885,6 @@ test_expect_success '__git_refs - only matching refs - remote on local file syst
test_expect_success '__git_refs - only matching refs - configured remote' '
cat >expected <<-EOF &&
- HEAD
master-in-other
matching/branch-in-other
EOF
@@ -912,7 +909,6 @@ test_expect_success '__git_refs - only matching refs - remote - full refs' '
test_expect_success '__git_refs - only matching refs - checkout DWIMery' '
cat >expected <<-EOF &&
- HEAD
matching-branch
matching/branch
matching-tag
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 06/12] completion: don't disambiguate short refs
From: SZEDER Gábor @ 2017-02-03 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
When the completion script lists short refs it does so using the 'git
for-each-ref' format 'refname:short', which makes sure that all listed
refs are unambiguous. While disambiguating refs is technically
correct in this case, as opposed to the cases discussed in the
previous patch, this disambiguation involves several stat() syscalls
for each ref, thus, unfortunately, comes at a steep cost especially on
Windows and/or when there are a lot of refs to be listed. A user of
Git for Windows reported[1] 'git checkout <TAB>' taking ~11 seconds in
a repository with just about 4000 refs.
However, it's questionable whether ambiguous refs are really that bad
to justify that much extra cost:
- Ambiguous refs are not that common,
- even if a repository contains ambiguous refs, they only hurt when
the user actually happens to want to do something with one of the
ambiguous refs, and
- the issue can be easily circumvented by renaming those ambiguous
refs.
- On the other hand, apparently not that many refs are needed to
make refs completion unacceptably slow on Windows,
- and this slowness bites each and every time the user attempts refs
completion, even when the repository doesn't contain any ambiguous
refs.
- Furthermore, circumventing the issue might not be possible or
might be considerably more difficult and requires various
trade-offs (e.g. working in a repository with only a few selected
important refs while keeping a separate repository with all refs
for reference).
Arguably, in this case the benefits of technical correctness are
rather minor compared to the price we pay for it, and we are better
off opting for performance over correctness.
Use the 'git for-each-ref' format 'refname:strip=2' to list short refs
to spare the substantial cost of disambiguating.
This speeds up refs completion considerably. Uniquely completing a
branch in a repository with 100k local branches, all packed, best of
five:
On Linux, before:
$ time __git_complete_refs --cur=maste
real 0m1.662s
user 0m1.368s
sys 0m0.296s
After:
real 0m0.831s
user 0m0.808s
sys 0m0.028s
On Windows, before:
real 0m12.457s
user 0m1.016s
sys 0m0.092s
After:
real 0m1.480s
user 0m1.031s
sys 0m0.060s
[1] - https://github.com/git-for-windows/git/issues/524
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 19799e3ba..d55eadfd1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -401,7 +401,7 @@ __git_refs ()
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
if [ -e "$dir/$i" ]; then echo $pfx$i; fi
done
- format="refname:short"
+ format="refname:strip=2"
refs="refs/tags refs/heads refs/remotes"
;;
esac
@@ -412,7 +412,7 @@ __git_refs ()
# Try to find a remote branch that matches the completion word
# but only output if the branch name is unique
local ref entry
- __git for-each-ref --shell --format="ref=%(refname:short)" \
+ __git for-each-ref --shell --format="ref=%(refname:strip=2)" \
"refs/remotes/" | \
while read -r entry; do
eval "$entry"
@@ -437,7 +437,7 @@ __git_refs ()
*)
if [ "$list_refs_from" = remote ]; then
echo "HEAD"
- __git for-each-ref --format="%(refname:short)" \
+ __git for-each-ref --format="%(refname:strip=2)" \
"refs/remotes/$remote/" | sed -e "s#^$remote/##"
else
__git ls-remote "$remote" HEAD \
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 04/12] completion: support excluding full refs
From: SZEDER Gábor @ 2017-02-03 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
Commit 49416ad22 (completion: support excluding refs, 2016-08-24) made
possible to complete short refs with a '^' prefix.
Extend the support to full refs to make completing '^refs/...' work.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 8 ++++----
t/t9902-completion.sh | 31 +++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 67a03cfd4..63e803154 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -387,6 +387,10 @@ __git_refs ()
fi
if [ "$list_refs_from" = path ]; then
+ if [[ "$cur_" == ^* ]]; then
+ pfx="^"
+ cur_=${cur_#^}
+ fi
case "$cur_" in
refs|refs/*)
format="refname"
@@ -394,10 +398,6 @@ __git_refs ()
track=""
;;
*)
- if [[ "$cur_" == ^* ]]; then
- pfx="^"
- cur_=${cur_#^}
- fi
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
if [ -e "$dir/$i" ]; then echo $pfx$i; fi
done
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 8fe748839..7b42a686c 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -806,6 +806,37 @@ test_expect_success '__git_refs - after --opt= - full refs' '
test_cmp expected "$actual"
'
+test_expect_success '__git refs - exluding refs' '
+ cat >expected <<-EOF &&
+ ^HEAD
+ ^master
+ ^matching-branch
+ ^other/branch-in-other
+ ^other/master-in-other
+ ^matching-tag
+ EOF
+ (
+ cur=^ &&
+ __git_refs >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success '__git refs - exluding full refs' '
+ cat >expected <<-EOF &&
+ ^refs/heads/master
+ ^refs/heads/matching-branch
+ ^refs/remotes/other/branch-in-other
+ ^refs/remotes/other/master-in-other
+ ^refs/tags/matching-tag
+ EOF
+ (
+ cur=^refs/ &&
+ __git_refs >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
test_expect_success '__git_complete_refs - simple' '
sed -e "s/Z$//g" >expected <<-EOF &&
HEAD Z
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 05/12] completion: don't disambiguate tags and branches
From: SZEDER Gábor @ 2017-02-03 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
When the completion script has to list only tags or only branches, it
uses the 'git for-each-ref' format 'refname:short', which makes sure
that all listed tags and branches are unambiguous. However,
disambiguating tags and branches in these cases is wrong, because:
- __git_tags(), the helper function listing possible tagname
arguments for 'git tag', lists an ambiguous tag
'refs/tags/ambiguous' as 'tags/ambiguous'. Its only consumer,
'git tag' expects its tagname argument to be under 'refs/tags/',
thus it interprets that abgiguous tag as
'refs/tags/tags/ambiguous'. Clearly wrong.
- __git_heads() lists possible branchname arguments for 'git branch'
and possible 'branch.<branchname>' configuration subsections.
Both of these expect branchnames to be under 'refs/heads/' and
misinterpret a disambiguated branchname like 'heads/ambiguous'.
Furthermore, disambiguation involves several stat() syscalls for each
tag or branch, thus comes at a steep cost especially on Windows and/or
when there are a lot of tags or branches to be listed.
Use the 'git for-each-ref' format 'refname:strip=2' instead of
'refname:short' to avoid harmful disambiguation of tags and branches
in __git_tags() and __git_heads().
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 63e803154..19799e3ba 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -340,12 +340,12 @@ __git_index_files ()
__git_heads ()
{
- __git for-each-ref --format='%(refname:short)' refs/heads
+ __git for-each-ref --format='%(refname:strip=2)' refs/heads
}
__git_tags ()
{
- __git for-each-ref --format='%(refname:short)' refs/tags
+ __git for-each-ref --format='%(refname:strip=2)' refs/tags
}
# Lists refs from the local (by default) or from a remote repository.
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* [PATCH 09/12] completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
From: SZEDER Gábor @ 2017-02-03 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
The code listing unique remote branches for 'git checkout's tracking
DWIMery outputs only remote branches that match the current word to be
completed, but the filtering is done in a shell loop iterating over
all remote refs.
Let 'git for-each-ref' do the filtering, as it can do so much more
efficiently and we can remove that shell loop entirely.
This speeds up refs completion for 'git checkout' considerably when
there are a lot of non-matching remote refs to be filtered out.
Uniquely completing a branch in a repository with 100k remote
branches, all packed, best of five:
On Linux, before:
$ time __git_complete_refs --cur=maste --track
real 0m1.993s
user 0m1.740s
sys 0m0.304s
After:
real 0m0.266s
user 0m0.248s
sys 0m0.012s
On Windows, before:
real 0m6.187s
user 0m3.358s
sys 0m2.121s
After:
real 0m0.750s
user 0m0.015s
sys 0m0.090s
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8f1203025..e2c4794f3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -413,15 +413,9 @@ __git_refs ()
# employ the heuristic used by git checkout
# Try to find a remote branch that matches the completion word
# but only output if the branch name is unique
- local ref entry
- __git for-each-ref --shell --format="ref=%(refname:strip=3)" \
- "refs/remotes/" | \
- while read -r entry; do
- eval "$entry"
- if [[ "$ref" == "$cur_"* ]]; then
- echo "$ref"
- fi
- done | sort | uniq -u
+ __git for-each-ref --format="%(refname:strip=3)" \
+ "refs/remotes/*/$cur_*" "refs/remotes/*/$cur_*/**" | \
+ sort | uniq -u
fi
return
fi
--
2.11.0.555.g967c1bcb3
^ permalink raw reply related
* possible bug: inconsistent CLI behaviour for empty user.name
From: bs.x.ttp @ 2017-02-03 4:13 UTC (permalink / raw)
To: git
The problem is that GIT accepts a user.name of " " for some operations (for example when doing a simple "git commit"), but does require a "non-empty" user.name for others (like git commit --amend and git rebase). In case of the latter commands GIT fails with the message "fatal: empty ident name (for <email@address>) not allowed".
As people tend to do simple commits first, before amending or rebasing something, they may have to change their name after some dozen of commits which doesn't look nice.
This is certainly not a big issue, but it turns out to be quite annoying and I've already rewritten the history of a GIT repository once because of it, so that all my commits had the same author.
Proposed solution: GIT's requirements for user.name should not depend on the operation. Either user.name should be enforced to be non-empty everywhere or an empty user.name should be accepted everywhere. Perhaps filling out one of user.name and user.email could be sufficient.
^ permalink raw reply
* Re: [PATCH 00/12] completion: speed up refs completion
From: Jacob Keller @ 2017-02-03 4:15 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
On Thu, Feb 2, 2017 at 6:53 PM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> This series speeds up refs completion for large number of refs, partly
> by giving up disambiguating ambiguous refs (patch 6) and partly by
> eliminating most of the shell processing between 'git for-each-ref'
> and 'ls-remote' and Bash's completion facility. The rest is a bit of
> preparatory reorganization, cleanup and bugfixes.
>
> The last patch touches the ZSH wrapper, too. By a lucky educated
> guess I managed to get it work on the first try, but I don't really
> know what I've actually done, so... ZSH users, please have a closer
> look.
>
> At the end of this series refs completion from a local repository is
> as fast as it can possibly get, at least as far as the completion
> script is concerned, because it basically does nothing anymore :) All
> it does is run 'git for-each-ref' with assorted options to do all the
> work, and feed its output directly, without any processing into Bash's
> COMPREPLY array. There is still room for improvements in the code
> paths using 'git ls-remote', but for that we would need enhancements
> to 'ls-remote'.
>
> It goes on top of the __gitdir() improvements series I just posted at:
>
> http://public-inbox.org/git/20170203024829.8071-1-szeder.dev@gmail.com/T/
>
> This series is also available at:
>
> https://github.com/szeder/git completion-refs-speedup
>
Nice! This is something i've been bothered by in the past since
completion would take a rather long time!
Regards,
Jake
^ permalink raw reply
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: G. Sylvie Davies @ 2017-02-03 4:19 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi0-8JnnZbdm9vu1RwTU1mXr7dboLC3ito3LcvK9gkNi_A@mail.gmail.com>
On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Hi all,
>
> I'm trying to get the committer date printed in a custom fashion.
> Using "%cI" gets me close:
>
> $ git show --format="%cI | %an" master | head -n 1
> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>
> I would like to get rid of the "-08:00" bit at the end of the
> timestamp. According to the "git show" manual I should be able to use
> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>
> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
> cI | Hilco Wijbenga
>
> Mmm, it seems to be recognized as a valid "something" but it's not
> working as I had expected. :-) I tried several other versions of this
> but no luck. Clearly, I'm misunderstanding the format description. How
> do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>
Will this work for you?
$ git show -s --pretty='%cd | %an' --date=format:%FT%R:%S
2017-02-02T10:01:36 | G. Sylvie Davies
I have no idea how portable this might be. As "git help log" says:
--date=format:... feeds the format ... to your system
strftime. Use --date=format:%c to show the date in your system
locale’s preferred format. See the strftime manual for a complete list
of format placeholders.
- Sylvie
^ permalink raw reply
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Hilco Wijbenga @ 2017-02-03 4:32 UTC (permalink / raw)
To: G. Sylvie Davies; +Cc: Git Users
In-Reply-To: <CAAj3zPz8wFc_5dRmM=-jMnqp6a7fGtc4XSyU5meF6mO5me47Dw@mail.gmail.com>
On 2 February 2017 at 20:19, G. Sylvie Davies <sylvie@bit-booster.com> wrote:
> On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> Hi all,
>>
>> I'm trying to get the committer date printed in a custom fashion.
>> Using "%cI" gets me close:
>>
>> $ git show --format="%cI | %an" master | head -n 1
>> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>>
>> I would like to get rid of the "-08:00" bit at the end of the
>> timestamp. According to the "git show" manual I should be able to use
>> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>>
>> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
>> cI | Hilco Wijbenga
>>
>> Mmm, it seems to be recognized as a valid "something" but it's not
>> working as I had expected. :-) I tried several other versions of this
>> but no luck. Clearly, I'm misunderstanding the format description. How
>> do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>>
>
> Will this work for you?
>
> $ git show -s --pretty='%cd | %an' --date=format:%FT%R:%S
> 2017-02-02T10:01:36 | G. Sylvie Davies
Ah, that does indeed do exactly what I want. Thank you.
> I have no idea how portable this might be. As "git help log" says:
>
> --date=format:... feeds the format ... to your system
> strftime. Use --date=format:%c to show the date in your system
> locale’s preferred format. See the strftime manual for a complete list
> of format placeholders.
It should be fine for my purposes.
Any idea why "%<(19,trunc)cl" doesn't work? (Your solution solves my
original problem perfectly but I'd like to understand how I'm
misreading the spec.)
^ permalink raw reply
* Re: difflame
From: Edmundo Carmona Antoranz @ 2017-02-03 4:46 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <CAOc6etYzAeD32oSjrvmv-PBJTdAGobsQ30iH8Q+Z9ShWOqiHfQ@mail.gmail.com>
I have been "scripting around git blame --reverse" for some days now.
Mind taking a look? I've been working on blame-deletions for this.
22:41 $ ../difflame/difflame.py HEAD~5 HEAD
diff --git a/file b/file
index b414108..051c298 100644
--- a/file
+++ b/file
@@ -1,6 +1,9 @@
^1513353 (Edmundo 2017-02-02 22:41:45 -0600 1) 1
f20952eb (Edmundo 2017-02-02 22:41:45 -0600 2) 2
bb04dc7c (Edmundo 2017-02-02 22:41:45 -0600 3) 3
-de3c07b (Edmundo 2017-02-02 22:41:47 -060 4) 4
058ea125 (Edmundo 2017-02-02 22:41:45 -0600 4) 5
85fc6b81 (Edmundo 2017-02-02 22:41:45 -0600 5) 6
+2cd990a6 (Edmundo 2017-02-02 22:41:45 -0600 6) 7
+ab0be970 (Edmundo 2017-02-02 22:41:45 -0600 7) 8
+944452c0 (Edmundo 2017-02-02 22:41:45 -0600 8) 9
+6641edb0 (Edmundo 2017-02-02 22:41:45 -0600 9) 10
$ git show de3c07b
commit de3c07bc21a83472d5c5ddf172dcb742665924dd (HEAD -> master)
Author: Edmundo <eantoranz@gmail.com>
Date: Thu Feb 2 22:41:47 2017 -0600
drop 4
diff --git a/file b/file
index f00c965..051c298 100644
--- a/file
+++ b/file
@@ -1,7 +1,6 @@
1
2
3
-4
5
6
7
Next step: solve the
find-real-deletion-revision-when-there-are-multiple-child-nodes
problem.... and let me read the discussion around git blame --reverse.
Thanks in advance.
On Mon, Jan 30, 2017 at 8:37 PM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> Maybe a little work on blame to get the actual revision where some
> lines were "deleted"?
>
> Something like git blame --blame-deletion that could be based on --reverse?
>
> On Mon, Jan 30, 2017 at 7:35 PM, Edmundo Carmona Antoranz
> <eantoranz@gmail.com> wrote:
>> I'm thinking of something like this:
>>
>> Say I just discovered a problem in a file.... I want to see who worked
>> on it since some revision that I know is working fine (or even
>> something as generic as HEAD~100..). It could be a number of people
>> with different revisions. I would diff to see what changed.... and
>> blame the added lines (blame reverse to try to get as close as
>> possible with a single command in case I want to see what happened
>> with something that was deleted). If I could get blame information of
>> added/deleted lines in a single run, that would help a lot.
>>
>> Lo and behold: difflame.
>>
>>
>>
>> On Mon, Jan 30, 2017 at 5:26 PM, Jeff King <peff@peff.net> wrote:
>>> On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote:
>>>
>>>> Jeff King <peff@peff.net> writes:
>>>>
>>>> > On Tue, Jan 17, 2017 at 11:24:02PM -0600, Edmundo Carmona Antoranz wrote:
>>>> >
>>>> >> For a very long time I had wanted to get the output of diff to include
>>>> >> blame information as well (to see when something was added/removed).
>>>> >
>>>> > This is something I've wanted, too. The trickiest part, though, is
>>>> > blaming deletions, because git-blame only tracks the origin of content,
>>>> > not the origin of a change.
>>>>
>>>> Hmph, this is a comment without looking at what difflame does
>>>> internally, so you can ignore me if I am misunderstood what problem
>>>> you are pointing out, but I am not sure how "tracks the origin of
>>>> content" could be a problem.
>>>>
>>>> If output from "git show" says this:
>>>>
>>>> --- a/file
>>>> +++ b/file
>>>> @@ -1,5 +1,6 @@
>>>> a
>>>> b
>>>> -c
>>>> +C
>>>> +D
>>>> d
>>>> e
>>>>
>>>> in order to annotate lines 'a', 'b', 'd', and 'e' for their origin,
>>>> you would run 'blame' on the commit the above output was taken from
>>>> (or its parent---they are in the context so either would be OK).
>>>>
>>>> You know where 'C' and 'D' came from already. It's the commit you
>>>> are feeding "git show".
>>>
>>> I think the point (or at least as I understand it) is that the diff is
>>> not "git show" for a particular commit. It could be part of a much
>>> larger diff that covers many commits.
>>>
>>> As a non-hypothetical instance, I have a fork of git.git that has
>>> various enhancements. I want to feed those enhancements upstream. I need
>>> to know which commits should be cherry-picked to get those various
>>> enhancements.
>>>
>>> Looking at "log origin..fork" tells me too many commits, because it
>>> includes ones which aren't useful anymore. Either because they already
>>> went upstream, or because they were cherry-picked to the fork and their
>>> upstream counterparts merged (or even equivalent commits made upstream
>>> that obsoleted the features).
>>>
>>> Looking at "git diff origin fork" tells me what the actual differences
>>> are, but it doesn't show me which commits are responsible for them.
>>>
>>> I can "git blame" each individual line of the diff (starting with "fork"
>>> as the tip), but that doesn't work for lines that no longer exist (i.e.,
>>> when the interesting change is a deletion).
>>>
>>>> In order to run blame to find where 'c' came from, you need to start
>>>> at the _parent_ of the commit the above output came from, and the
>>>> hunk header shows which line range to find the final 'c'.
>>>
>>> So perhaps that explains my comment more. "blame" is not good for
>>> finding which commit took away a line. I've tried using "blame
>>> --reverse", but it shows you the parent of the commit you are looking
>>> for, which is slightly annoying. :)
>>>
>>> "git log -S" is probably a better tool for finding that.
>>>
>>> -Peff
^ permalink raw reply related
* Re: difflame
From: Edmundo Carmona Antoranz @ 2017-02-03 4:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <CAOc6etabV=h6fEVee=N2-3ERUU7_w6eCM006mSMPqiwkRycQBw@mail.gmail.com>
On Thu, Feb 2, 2017 at 10:46 PM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> I have been "scripting around git blame --reverse" for some days now.
> Mind taking a look? I've been working on blame-deletions for this.
blame-deletions branch, that is
Sorry for the previous top-posting.
^ permalink raw reply
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Duy Nguyen @ 2017-02-03 8:06 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi0-8JnnZbdm9vu1RwTU1mXr7dboLC3ito3LcvK9gkNi_A@mail.gmail.com>
On Fri, Feb 3, 2017 at 12:51 AM, Hilco Wijbenga
<hilco.wijbenga@gmail.com> wrote:
> Hi all,
>
> I'm trying to get the committer date printed in a custom fashion.
> Using "%cI" gets me close:
>
> $ git show --format="%cI | %an" master | head -n 1
> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>
> I would like to get rid of the "-08:00" bit at the end of the
> timestamp. According to the "git show" manual I should be able to use
> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>
> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
You're almost there. Just insert another '%' between "trunc)" and "cI".
> How do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
You'll get an ellipsis at the end though.. (i.e. 02:13... | Hilco)
--
Duy
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Duy Nguyen @ 2017-02-03 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <xmqqmve4s5r2.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Also, the more important reply was Peff's reply that suggested that the
>> proposed fix was incomplete, as it misses --unpack-unreachable:
>> https://public-inbox.org/git/20160601160143.GA9219@sigill.intra.peff.net/
>
> While I think that --unpack-unreachable thing is a symptom of the
> basic approach of patching things up at the wrong level, if you are
> hinting that fix to the issue that gc does not pay attention to
> various anchoring point in other worktrees is more important than
> adding new commands to "worktree", I fully agree with that.
Just to make it clear. It's not like I put new worktree commands on
higher priority. "worktree move/remove" was more or less ready for a
long time and the gc problem was blocked by ref-iterator series (which
entered master a few moths ago, but then I was busy with other things
and couldn't get right back to the gc issue).
You didn't answer Johannes's rhetoric question though: "It should be
possible to do that redesign work while having a small workaround in
place that unbreaks, say, me?"
I assume "the right way" is still updating refs subsystem so that we
can have a ref iterator to traverse all refs, or just one worktree,
etc. Should I keep looking for a middle ground (maybe better than the
linked series) to "unbreak Johannes"? I ignored all those comments
(about --unpack-reachable and bisect refs) because I saw no chance of
an updated series getting in git.git anyway.
--
Duy
^ permalink raw reply
* Re: [PATCH] reset: add an example of how to split a commit into two
From: Duy Nguyen @ 2017-02-03 9:05 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git Mailing List, Jacob Keller
In-Reply-To: <20170203003038.22278-1-jacob.e.keller@intel.com>
On Fri, Feb 3, 2017 at 7:30 AM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> It is sometimes useful to break a commit into parts to more logically
> show how the code changes. There are many possible ways to achieve this
> result, but one simple and powerful one is to use git reset -p.
>
> Add an example to the documentation showing how this can be done so that
> users are more likely to discover this, instead of inventing more
> painful methods such as re-writing code from scratch, or duplicating git
> add -p more times than necessary.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> ---
> Documentation/git-reset.txt | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> index 25432d9257f9..4adac7a25bf9 100644
> --- a/Documentation/git-reset.txt
> +++ b/Documentation/git-reset.txt
> @@ -292,6 +292,29 @@ $ git reset --keep start <3>
> <3> But you can use "reset --keep" to remove the unwanted commit after
> you switched to "branch2".
>
> +Split a commit into two::
> ++
> +Suppose that you have created a commit, but later decide that you want to split
> +the changes into two separate commits, including only part of the old commit
> +into the first commit, and including the rest as a separate commit on top. You
> +can use git reset in patch mode to interactively select which hunks to split
> +out into a separate commit.
> ++
> +------------
> +$ git reset -p HEAD^ <1>
For good practice, perhaps put "git diff --cached HEAD^" before "git commit".
I tend to avoid "reset -p" and "checkout -p" though because sometimes
it does not work. Not sure if it's just me, I think it may have
something to do with splitting hunks. So I usually go with "reset
HEAD^" then "add -p" and "commit -c HEAD@{1}" instead.
> +$ git commit --amend <2>
> +$ git commit ... <3>
> +------------
> ++
> +<1> This lets you interactively undo changes between HEAD^ and HEAD, so you can
> + select which parts to remove from the initial commit. The changes are
> + placed into the index, leaving the working tree untouched.
> +<2> Now, you ammend the initial commit with the modifications that you just
s/ammend/amend/
> + made in the index.
> +<3> Finally, you can add and then commit the final original unmodified files
> + back as the second commit, enabling you to logically separate a commit
> + into a sequence of two commits instead.
--
Duy
^ permalink raw reply
* [ANNOUNCE] Git for Windows 2.11.1
From: Johannes Schindelin @ 2017-02-03 9:19 UTC (permalink / raw)
To: git-for-windows, git; +Cc: Johannes Schindelin
MIME-Version: 1.0
Fcc: Sent
Dear Git users,
It is my pleasure to announce that Git for Windows 2.11.1 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.11.0(3) (January 14th 2017)
New Features
• Comes with Git v2.11.1.
• Performance was enhanced when using fscache in a massively sparse
checkout.
• Git hooks can now be .exe files.
Bug Fixes
• Git GUI will no longer set GIT_DIR when calling Git Bash after
visualizing the commit history.
• When the PATH contains UNC entries, Git Bash will no longer error
out with a "Bad address" error message.
Filename | SHA-256
-------- | -------
Git-2.11.1-64-bit.exe | 2c6408f98297b8f4ad0df36f3aabab67164b3b3d7bb3d91d49f237aba566f8ac
Git-2.11.1-32-bit.exe | a556c6f65c13f54dcce64df96bbc94a156bb7c9025a27cf0caa329648adaac06
PortableGit-2.11.1-64-bit.7z.exe | 47058bbfb815ec3e9247b96aedcaea21df58db59c3a73594ffcbd4171ac2cb11
PortableGit-2.11.1-32-bit.7z.exe | 2f76bed9b649d990cf6999674e11e6cf5d502d25b89072b34c984f6aa86dafbb
MinGit-2.11.1-64-bit.zip | 668d16a799dd721ed126cc91bed49eb2c072ba1b25b50048280a4e2c5ed56e59
MinGit-2.11.1-32-bit.zip | 6ca79af09015625f350ef4ad74a75cfb001b340aec095b6963be9d45becb3bba
Git-2.11.1-64-bit.tar.bz2 | 06b066c7a3f1934d96f2a838b64cbf1aced8578e5321bf6ff0e7bd65e6c34988
Git-2.11.1-32-bit.tar.bz2 | f06e3d78ca25ae8def8dac3e584912c74d0d819966772dfb965d78e1e462f0b0
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] document behavior of empty color name
From: Duy Nguyen @ 2017-02-03 9:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20170202124238.53k74cedpp2rcmzo@sigill.intra.peff.net>
On Thu, Feb 02, 2017 at 01:42:44PM +0100, Jeff King wrote:
> On Thu, Feb 02, 2017 at 04:16:15PM +0700, Duy Nguyen wrote:
>
> > > I hadn't heard anything back,
> >
> > Sorry I was accidentally busy during Luna new year holiday.
>
> No problem. That sounds much more fun than working on Git. :)
>
> > > - if (!len)
> > > - return -1;
> > > + if (!len) {
> > > + dst[0] = '\0';
> > > + return 0;
> > > + }
> > >
> > > if (!strncasecmp(ptr, "reset", len)) {
> > > xsnprintf(dst, end - dst, GIT_COLOR_RESET);
> >
> > I wonder if it makes more sense to do this in builtin/config.c. The
> > "default value" business is strictly git-config command's. The parsing
> > function does not need to know. Maybe something like this?
>
> I don't think so. The default value is a git-config thing, but you would
> want to be able to do the same thing in a config file. For example, to
> disable coloring entirely for part of the diff, you could do:
>
> [color "diff"]
> meta = ""
OK but it makes log.graphColors add empty colors though. In t4202.39,
we have " blue,invalid-color, cyan, red , ". With this patch the color
after red would be no color. Without it, we get a complaint and the
next color would be cycled back to blue. The test does not catch this
because the test graph does not have enough fork points to get to red
and back to blue.
I suppose this is ok after your documentation patch ("that's by
design!"). Just wanted to point it out in case I miss something.
--
Duy
^ permalink raw reply
* Re: mergetool and difftool inconsistency?
From: David Aguilar @ 2017-02-03 10:32 UTC (permalink / raw)
To: Denton Liu; +Cc: git
In-Reply-To: <20170126025810.GA3020@arch-attack.localdomain>
On Wed, Jan 25, 2017 at 06:58:10PM -0800, Denton Liu wrote:
> Hello all,
>
> I was wondering if there is any reason why 'git difftool' accepts the
> '-g|--gui' whereas 'git mergetool' does not have an option to accept
> that flag. Please let me know if this is intentional, otherwise I can
> write up a patch to add the GUI flag to 'mergetool'.
>
> Thanks!
Hello,
The difference was not intentional. The "--gui" feature was
added to difftool because that's where the feature was
originally requested, but there's no reason why mergetool
couldn't have a similar option.
cheers,
--
David
^ permalink raw reply
* [PATCH v2 3/7] completion: improve bash completion for git-add
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Command completion for git-add did not recognize some long-options.
This commits adds completion for all long-options that are mentioned in
the man-page synopsis. In addition, if the user specified `--update` or
`-u`, path completion will only suggest modified tracked files.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8329f09..652c7e2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -947,13 +947,17 @@ _git_add ()
--*)
__gitcomp "
--interactive --refresh --patch --update --dry-run
- --ignore-errors --intent-to-add
+ --ignore-errors --intent-to-add --force --edit --chmod=
"
return
esac
- # XXX should we check for --update and --all options ?
- __git_complete_index_file "--others --modified --directory --no-empty-directory"
+ local complete_opt="--others --modified --directory --no-empty-directory"
+ if test -n "$(__git_find_on_cmdline "-u --update")"
+ then
+ complete_opt="--modified"
+ fi
+ __git_complete_index_file "$complete_opt"
}
_git_archive ()
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/7] completion: teach ls-remote to complete options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
ls-remote needs to complete remote names and its own options. In
addition to the existing remote name completions, do also complete
the options --heads, --tags, --refs, --get-url, and --symref.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 652c7e2..a355eeb 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1449,6 +1449,12 @@ _git_ls_files ()
_git_ls_remote ()
{
+ case "$cur" in
+ --*)
+ __gitcomp "--heads --tags --refs --get-url --symref"
+ return
+ ;;
+ esac
__gitcomp_nl "$(__git_remotes)"
}
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox