* Re: git-reset man page
From: Krzysztof Mazur @ 2012-11-18 17:48 UTC (permalink / raw)
To: Drew Northup; +Cc: Angelo Borsotti, Junio C Hamano, git, peff
In-Reply-To: <CAM9Z-nkon5ZtPuqxL0HZPr1es9DSpLA+70++hYpTR4D7WTxbUA@mail.gmail.com>
On Sun, Nov 18, 2012 at 11:55:09AM -0500, Drew Northup wrote:
>
> > So we should always use "<path>" for exact path, and "<pathspec>" for
> > pathspecs patterns as defined in gitglossary. I think it's better
> > to avoid "<paths>" and always use "<path>..." or "<pathspec>..."
>
> I suspect that the only reason why the differentiation between
> "<path>" and "<paths>" happened is because there may be some places
> where it was seen that a _list of paths_ was acceptable (which isn't a
> pathspec, as it isn't a search expression) and other places where
<paths> is usually used for a list of <pathspec>, not just a list of <path>.
> _only_ a single path was acceptable. Should that fail to be the case
> then there would be a good argument for changing the affected
> instances of "<paths>" to "<path>" in the documentation. (I know of no
> other good way to pluralize "<path>" myself.)
>
I think it's best to just add "...":
<path> for single exact path,
<path>... for a list of exact paths,
<pathspec> for single pathspec,
<pathspec>... for a list of pathspecs.
Krzysiek
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Jörg Rosenkranz @ 2012-11-18 17:18 UTC (permalink / raw)
To: Javier Domingo; +Cc: git
In-Reply-To: <CAKs0BQ7RyLZr+ZU=hAC4U7xXpE0+xvORTrvfzFYb6muA2TgM4Q@mail.gmail.com>
2012/11/15 Javier Domingo <javierdo1@gmail.com>
>
> Is there any way to avoid this? I mean, can something be done in git,
> that it checks for (when pulling) the same objects in the other forks?
I've been using git-new-workdir
(https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir)
for a similar problem. Maybe that's what you're searching?
Joerg.
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Enrico Weigelt @ 2012-11-18 17:02 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Michael J Gruber, Andrew Ardill, Javier Domingo, git
In-Reply-To: <CAMK1S_hCk3QdDn8XnXVisL1i2V0iPCZBYN989JmZ3JYr7ckRrA@mail.gmail.com>
Hi,
> That's not the only problem. I believe you only get the savings when
> the main repo gets the commits first. Which is probably ok most of
> the time but it's worth mentioning.
Well, the saving will just be deferred to the point where the commit
finally went to the main repo and downstreams are gc'ed.
> > hmm, distributed GC is a tricky problem.
>
> Except for one little issue (see other thread, subject line "cloning
> a
> namespace downloads all the objects"), namespaces appear to do
> everything we want in terms of the typical use cases for alternates,
> and/or 'git clone -l', at least on the server side.
hmm, not sure about the actual internals, but that namespace filtering
should work in a way that local clone should never see (or consider)
remote refs that are outside of the requested namespace. Perhaps that
should be handled entirely on server side, so all called commands treat
these refs as nonexisting.
By the way: what happens if one tries to clone from an broken repo
(which has several refs pointing to nonexisting objects ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Auto-repo-repair
From: Enrico Weigelt @ 2012-11-18 16:55 UTC (permalink / raw)
To: Drew Northup; +Cc: Jeff King, git
In-Reply-To: <CAM9Z-nn1S9JvfcymotOvSis4CoYco0Htn4uoETZn2kCto0z9zw@mail.gmail.com>
> How would the broken repository be sure of what it is missing to
> request it from the other side?
fsck will find missing objects.
>
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
>
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: git-reset man page
From: Drew Northup @ 2012-11-18 16:55 UTC (permalink / raw)
To: Krzysztof Mazur, Angelo Borsotti; +Cc: Junio C Hamano, git, peff
In-Reply-To: <20121110204633.GA29363@shrek.podlesie.net>
On Sat, Nov 10, 2012 at 3:46 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>>
>> > Maybe we should just add that <paths> is an shortcut for <pathspec>
>> > and fix places where paths and pathspec are mixed or <path> is used as
>> > <pathspec>.
>>
>> We should unify uses of <paths> and <path> (the former should be
>> <path>... or something).
>
> Currently in most cases "<paths>..." is used ;)
> So we should always use "<path>" for exact path, and "<pathspec>" for
> pathspecs patterns as defined in gitglossary. I think it's better
> to avoid "<paths>" and always use "<path>..." or "<pathspec>..."
I suspect that the only reason why the differentiation between
"<path>" and "<paths>" happened is because there may be some places
where it was seen that a _list of paths_ was acceptable (which isn't a
pathspec, as it isn't a search expression) and other places where
_only_ a single path was acceptable. Should that fail to be the case
then there would be a good argument for changing the affected
instances of "<paths>" to "<path>" in the documentation. (I know of no
other good way to pluralize "<path>" myself.)
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Motd message on git cloning
From: Adam Stankiewicz @ 2012-11-18 16:51 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <CAM9Z-nkxLqrS5i6Ycz02Amit5itmGJojy=e8+SG9LQYcBHJVxQ@mail.gmail.com>
It we would agree that .git/motd should serve as MOTD file then at the
beginning there would be no noise at all, because currently no
repository contains that file.
I don't think developers would place there non-critical information
about the repository. The community would blame them for that.
Also if one does not like any additional noise, no one prevents him
from adding --no-motd flag as the default.
Thank you for attention.
On Sun, Nov 18, 2012 at 5:34 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Sun, Nov 18, 2012 at 11:04 AM, Adam Stankiewicz <sheerun@sher.pl> wrote:
>> I'm dreaming about git feature that shows custom message on git clone.
>> It would be extremely helpful for informing the person cloning about
>> init scripts he/she need to execute (for example submodule inits or
>> hooks set up). For now there is no way to make sure cloning person
>> will receive such message (unless he/she will read the README).
>
> So we should clog up the output (which may contain important error
> messages) just to protect the user from themselves?
>
>> The server does not need to know if it's fetch or clone, if programmer
>> executes git clone on client side, then the MOTD message would be
>> shown.
>>
>> I think good candidate for MOTD message is .git/description (because
>> for now no one seems to care about setting repository description).
>> Another option is to introduce .git/motd file that would consist of
>> some maximum number of non-control ASCII characters.
>>
>> I don't really see any security concerns. Git could filter any control
>> characters from MOTD out, and automation script could add --no-motd
>> flag. The could also be limit on MOTD file size so no one could
>> "flood" the terminal window with MOTD messages.
>
> While I think that it is helpful and sometimes important to set the
> description (especially for public repositories) I suspect that if
> somebody is cloning it then they already have a good chance of knowing
> what _should_ be in that file. This isn't a text-interactive session
> on an FTP server of yore.
>
>> Also it's important to me that such message would be shown
>> automatically by default and could be turned off, not the other way
>> (for example --motd flag).
>
> Ummm....NO. I cannot see this being an improvement for enough users to
> justify the extra noise.
>
> Granted, I am not the definitive word on much of anything around here,
> but I cannot see this making much sense in the big picture of things.
> If you wanted to make this change to something more like Google's
> "repo" wrapper script that would make at least some modicum of sense
> to me.
>
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Auto-repo-repair
From: Drew Northup @ 2012-11-18 16:37 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeff King, git
In-Reply-To: <075f74ff-cafb-4021-ba4d-2474b6fb1853@zcs>
On Sat, Nov 17, 2012 at 4:21 AM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
> Hi,
>
>> You can't reliably just grab the broken objects, because most
>> transports
>> don't support grabbing arbitrary objects (you can do it if you have
>> shell access to a known-good repository, but it's not automated).
>
> can we introduce a new or extend existing transports to support that ?
How would the broken repository be sure of what it is missing to
request it from the other side?
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Motd message on git cloning
From: Drew Northup @ 2012-11-18 16:34 UTC (permalink / raw)
To: Adam Stankiewicz; +Cc: git
In-Reply-To: <CANCidP-d0tXfo6ZsC80LmaS1CJ475rew2D7ztrx9TkNa94a-uw@mail.gmail.com>
On Sun, Nov 18, 2012 at 11:04 AM, Adam Stankiewicz <sheerun@sher.pl> wrote:
> I'm dreaming about git feature that shows custom message on git clone.
> It would be extremely helpful for informing the person cloning about
> init scripts he/she need to execute (for example submodule inits or
> hooks set up). For now there is no way to make sure cloning person
> will receive such message (unless he/she will read the README).
So we should clog up the output (which may contain important error
messages) just to protect the user from themselves?
> The server does not need to know if it's fetch or clone, if programmer
> executes git clone on client side, then the MOTD message would be
> shown.
>
> I think good candidate for MOTD message is .git/description (because
> for now no one seems to care about setting repository description).
> Another option is to introduce .git/motd file that would consist of
> some maximum number of non-control ASCII characters.
>
> I don't really see any security concerns. Git could filter any control
> characters from MOTD out, and automation script could add --no-motd
> flag. The could also be limit on MOTD file size so no one could
> "flood" the terminal window with MOTD messages.
While I think that it is helpful and sometimes important to set the
description (especially for public repositories) I suspect that if
somebody is cloning it then they already have a good chance of knowing
what _should_ be in that file. This isn't a text-interactive session
on an FTP server of yore.
> Also it's important to me that such message would be shown
> automatically by default and could be turned off, not the other way
> (for example --motd flag).
Ummm....NO. I cannot see this being an improvement for enough users to
justify the extra noise.
Granted, I am not the definitive word on much of anything around here,
but I cannot see this making much sense in the big picture of things.
If you wanted to make this change to something more like Google's
"repo" wrapper script that would make at least some modicum of sense
to me.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Motd message on git cloning
From: Adam Stankiewicz @ 2012-11-18 16:04 UTC (permalink / raw)
To: git
I'm dreaming about git feature that shows custom message on git clone.
It would be extremely helpful for informing the person cloning about
init scripts he/she need to execute (for example submodule inits or
hooks set up). For now there is no way to make sure cloning person
will receive such message (unless he/she will read the README).
The server does not need to know if it's fetch or clone, if programmer
executes git clone on client side, then the MOTD message would be
shown.
I think good candidate for MOTD message is .git/description (because
for now no one seems to care about setting repository description).
Another option is to introduce .git/motd file that would consist of
some maximum number of non-control ASCII characters.
I don't really see any security concerns. Git could filter any control
characters from MOTD out, and automation script could add --no-motd
flag. The could also be limit on MOTD file size so no one could
"flood" the terminal window with MOTD messages.
Also it's important to me that such message would be shown
automatically by default and could be turned off, not the other way
(for example --motd flag).
Some other tools like brew package manager have this feature from the
beginning and I find it extremely helpful.
What do you think?
^ permalink raw reply
* Re: t5801-remote-helpers.sh fails
From: Torsten Bögershausen @ 2012-11-18 15:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s22kuXqUjY2Oy2YtBfj1+kF2rHnRKcovV8sPkhu1oR+2A@mail.gmail.com>
On 18.11.12 09:23, Felipe Contreras wrote:
> Hi,
>
> On Sun, Nov 18, 2012 at 6:50 AM, Torsten Bögershausen <tboegi@web.de> wrote:
>
>> I managed to have a working solution for
>> "d) add a check for the bash version to the top of the test in t/"
>> Please see diff below.
>>
>> This unbreaks the test suite here.
>> Is this a good way forward?
>>
>> Filipe, does the code line you mention above work for you?
>>
>> If yes: I can test it here, if you send it as a patch.
>
> It's already sent:
> http://article.gmane.org/gmane.comp.version-control.git/209364
>
Thanks for working on it, and sorry that you need to remind me:
I had the V5 series already on my harddisk, but forgot to test it.
It applied on v.1.8.0 with the following results:
ok 1 - setup repository
ok 2 - cloning from local repo
ok 3 - create new commit on remote
ok 4 - pulling from local repo
ok 5 - pushing to local repo
ok 6 - fetch new branch
ok 7 - fetch multiple branches
ok 8 - push when remote has extra refs
ok 9 - push new branch by name
not ok 10 - push new branch with old:new refspec # TODO known breakage
ok 11 - cloning without refspec
ok 12 - pulling without refspecs
not ok 13 - pushing without refspecs # TODO known breakage
not ok 14 - pulling with straight refspec # TODO known breakage
not ok 15 - pushing with straight refspec # TODO known breakage
not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage
ok 18 - push ref with existing object
# still have 6 known breakage(s)
/Torsten
^ permalink raw reply
* [ANNOUNCE] namespace support in gitolite
From: Sitaram Chamarty @ 2012-11-18 11:41 UTC (permalink / raw)
To: Git Mailing List
Hello all,
Gitolite now supports namespaces on the server side (invisible
to the client side of course). See [1] for details.
A simple way to describe it would be that all the repos in the
top row of the picture in the "integration manager workflow" at
[2] are stored in one physical repo on the server, which saves a
lot of disk space as well as network traffic for pushes to a
"new" repo.
This is all on the server side. On the client side they
continue to look like separate repos, so nothing changes.
In addition, gitolite's 'upstream' trigger can be used to keep
the main repo in sync with the real upstream (somewhere on the
internet) if you wish.
A bit more detail and a small example is at [3].
[1]: http://sitaramc.github.com/gitolite/namespaces.html
[2]: http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow
[3]: http://groups.google.com/group/gitolite/browse_thread/thread/5efcbfb5ff3ebe88
--
Sitaram
^ permalink raw reply
* [PATCH v6 2/2] completion: start moving to the new zsh completion
From: Felipe Contreras @ 2012-11-18 11:08 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Marc Khouzam, Felipe Contreras,
Marius Storm-Olsen, Marius Storm-Olsen, Jonathan Nieder,
Peter van der Does, SZEDER Gábor, Mark Lodato
In-Reply-To: <1353236889-15052-1-git-send-email-felipe.contreras@gmail.com>
Zsh's bash completion emulation is buggy, not properly maintained, and
we have some workarounds in place for different bugs that appeared in
various versions.
Since I'm the only one that has worked on that code lately[1], it might make
snese to use the code I wrote specifically for git.
The advantages are:
1) Less workarounds
* No need to hack __get_comp_words_by_ref
* No need to hack IFS or words
2) Improved features
* 'git show master' now properly adds a space at the end (IFS bug)
* 'git checkout --conflict=' now properly returns the sub-items
(missing feature)
3) Consolidated code
* It's all now in a single chunk, and it's basically the same as
git-completion.zsh
Since there's some interest in moving the zsh-specific code out of this
script, lets go ahead and warn the users that they should be using
git-completion.zsh.
[1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/bashcompinit
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 104 +++++++++++++++++++--------------
1 file changed, 61 insertions(+), 43 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bc0657a..9cd58ca 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -23,10 +23,6 @@
# 3) Consider changing your PS1 to also show the current branch,
# see git-prompt.sh for details.
-if [[ -n ${ZSH_VERSION-} ]]; then
- autoload -U +X bashcompinit && bashcompinit
-fi
-
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -169,7 +165,6 @@ __git_reassemble_comp_words_by_ref()
}
if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
-if [[ -z ${ZSH_VERSION:+set} ]]; then
_get_comp_words_by_ref ()
{
local exclude cur_ words_ cword_
@@ -197,32 +192,6 @@ _get_comp_words_by_ref ()
shift
done
}
-else
-_get_comp_words_by_ref ()
-{
- while [ $# -gt 0 ]; do
- case "$1" in
- cur)
- cur=${COMP_WORDS[COMP_CWORD]}
- ;;
- prev)
- prev=${COMP_WORDS[COMP_CWORD-1]}
- ;;
- words)
- words=("${COMP_WORDS[@]}")
- ;;
- cword)
- cword=$COMP_CWORD
- ;;
- -n)
- # assume COMP_WORDBREAKS is already set sanely
- shift
- ;;
- esac
- shift
- done
-}
-fi
fi
# Generates completion reply with compgen, appending a space to possible
@@ -2430,20 +2399,69 @@ __gitk_main ()
__git_complete_revlist
}
-__git_func_wrap ()
-{
- if [[ -n ${ZSH_VERSION-} ]]; then
- emulate -L bash
- setopt KSH_TYPESET
+if [[ -n ${ZSH_VERSION-} ]]; then
+ echo "WARNING: this script is deprecated, please see git-completion.zsh" 1>&2
- # workaround zsh's bug that leaves 'words' as a special
- # variable in versions < 4.3.12
- typeset -h words
+ __gitcomp ()
+ {
+ emulate -L zsh
- # workaround zsh's bug that quotes spaces in the COMPREPLY
- # array if IFS doesn't contain spaces.
- typeset -h IFS
- fi
+ local cur_="${3-$cur}"
+
+ case "$cur_" in
+ --*=)
+ ;;
+ *)
+ local c IFS=$' \t\n'
+ local -a array
+ for c in ${=1}; do
+ c="$c${4-}"
+ case $c in
+ --*=*|*.) ;;
+ *) c="$c " ;;
+ esac
+ array+=("$c")
+ done
+ compset -P '*[=:]'
+ compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
+ ;;
+ esac
+ }
+
+ __gitcomp_nl ()
+ {
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
+ }
+
+ __git_zsh_helper ()
+ {
+ emulate -L ksh
+ local cur cword prev
+ cur=${words[CURRENT-1]}
+ prev=${words[CURRENT-2]}
+ let cword=CURRENT-1
+ __${service}_main
+ }
+
+ _git ()
+ {
+ emulate -L zsh
+ local _ret=1
+ __git_zsh_helper
+ let _ret && _default -S '' && _ret=0
+ return _ret
+ }
+
+ compdef _git git gitk
+ return
+fi
+
+__git_func_wrap ()
+{
local cur words cword prev
_get_comp_words_by_ref -n =: cur words cword prev
$1
--
1.8.0
^ permalink raw reply related
* [PATCH v6 1/2] completion: add new zsh completion
From: Felipe Contreras @ 2012-11-18 11:08 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Marc Khouzam, Felipe Contreras,
Marius Storm-Olsen, Marius Storm-Olsen, Jonathan Nieder,
Peter van der Does, SZEDER Gábor, Mark Lodato
In-Reply-To: <1353236889-15052-1-git-send-email-felipe.contreras@gmail.com>
It seems there's always issues with zsh's bash completion emulation.
I've tried to fix as many as I could[1], and most of the fixes are already
in the latest version of zsh, but still, there are issues.
There is no point going through all that pain; the emulation is easy to
achieve, and this patch works better than zsh's bash completion
emulation.
[1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=23907bb840c80eef99eabba17e086e44c9b2d3fc
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.zsh | 78 +++++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 contrib/completion/git-completion.zsh
diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
new file mode 100644
index 0000000..4577502
--- /dev/null
+++ b/contrib/completion/git-completion.zsh
@@ -0,0 +1,78 @@
+#compdef git gitk
+
+# zsh completion wrapper for git
+#
+# You need git's bash completion script installed somewhere, by default on the
+# same directory as this script.
+#
+# If your script is on ~/.git-completion.sh instead, you can configure it on
+# your ~/.zshrc:
+#
+# zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
+#
+# The recommended way to install this script is to copy to
+# '~/.zsh/completion/_git', and then add the following to your ~/.zshrc file:
+#
+# fpath=(~/.zsh/completion $fpath)
+
+complete ()
+{
+ # do nothing
+ return 0
+}
+
+zstyle -s ":completion:*:*:git:*" script script
+test -z "$script" && script="$(dirname ${funcsourcetrace[1]%:*})"/git-completion.bash
+ZSH_VERSION='' . "$script"
+
+__gitcomp ()
+{
+ emulate -L zsh
+
+ local cur_="${3-$cur}"
+
+ case "$cur_" in
+ --*=)
+ ;;
+ *)
+ local c IFS=$' \t\n'
+ local -a array
+ for c in ${=1}; do
+ c="$c${4-}"
+ case $c in
+ --*=*|*.) ;;
+ *) c="$c " ;;
+ esac
+ array+=("$c")
+ done
+ compset -P '*[=:]'
+ compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
+ ;;
+ esac
+}
+
+__gitcomp_nl ()
+{
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
+}
+
+_git ()
+{
+ local _ret=1
+ () {
+ emulate -L ksh
+ local cur cword prev
+ cur=${words[CURRENT-1]}
+ prev=${words[CURRENT-2]}
+ let cword=CURRENT-1
+ __${service}_main
+ }
+ let _ret && _default -S '' && _ret=0
+ return _ret
+}
+
+_git
--
1.8.0
^ permalink raw reply related
* [PATCH v6 0/2] New zsh wrapper
From: Felipe Contreras @ 2012-11-18 11:08 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Marc Khouzam, Felipe Contreras,
Marius Storm-Olsen, Marius Storm-Olsen, Jonathan Nieder,
Peter van der Does, SZEDER Gábor, Mark Lodato
Hi,
It looks like there's some resistance with the other patches this series was
depending upon, so lets get rid of them, they are not really needed.
This version should be ready to merge.
The second patch is new, in order for users to get the same features when
sourcing the bash script (they don't need to change anything). They'll get a
warning suggesting to check the new script git-completion.zsh. Eventually, that
support would be dropped from the bash script.
Some people were suggesting something like this, so here it is.
Can we merge the zsh wrapper now?
Felipe Contreras (2):
completion: add new zsh completion
completion: start moving to the new zsh completion
contrib/completion/git-completion.bash | 104 +++++++++++++++++++--------------
contrib/completion/git-completion.zsh | 78 +++++++++++++++++++++++++
2 files changed, 139 insertions(+), 43 deletions(-)
create mode 100644 contrib/completion/git-completion.zsh
--
1.8.0
^ permalink raw reply
* Re: using multiple version of git simultaneously
From: arif @ 2012-11-18 11:04 UTC (permalink / raw)
To: Jeff King; +Cc: Tomas Carnecky, git
In-Reply-To: <20121117161631.GA18844@sigill.intra.peff.net>
On 11/17/2012 10:16 PM, Jeff King wrote:
> On Sat, Nov 17, 2012 at 02:50:31PM +0000, Tomas Carnecky wrote:
>
>> On Sat, 17 Nov 2012 20:25:21 +0600, arif <aftnix@gmail.com> wrote:
<snip>
>
>> Install each version into its own prefix (~/git/1.8.0/, ~/git/1.7.0/ etc).
>
> Once you have done that, you can also symlink the binary from each into
> your regular PATH (e.g., ln -s ~/git/1.8.0/bin/git ~/bin/git.v1.8) to
> make it easy to switch between them. The installed exec-path is baked in
> at compile-time, so it finds the correct git sub-programs properly.
>
> I keep a couple dozen built versions of git around like this for quick
> regression testing of bugs we see on the list.
>
> -Peff
>
So what you are saying that, making a symlink for "git" is sufficient. I
don't need to make symlinks for ever git subbinaries.
Is that correct?
--
Cheers
arif
^ permalink raw reply
* [RFC/PATCH v2 8/8] completion: small optimization
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
No need to calculate a new $c with a space if we are not going to do
anything it with it.
There should be no functional changes, except that a word "foo " with no
suffixes can't be matched. But $cur cannot have a space at the end
anyway. So it's safe.
Based on the code from SZEDER Gábor.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 82ea7b1..e5f862c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -240,11 +240,11 @@ __gitcomp ()
local c i=0 IFS=$' \t\n'
for c in $1; do
c="$c${4-}"
- case $c in
- --*=*|*.) ;;
- *) c="$c " ;;
- esac
if [[ $c == "$cur_"* ]]; then
+ case $c in
+ --*=*|*.) ;;
+ *) c="$c " ;;
+ esac
COMPREPLY[i++]="${2-}$c"
fi
done
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 7/8] completion: get rid of __gitcomp_1
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
There's no point in calling a separate function that is only used in one
place. Specially considering that there's no need to call compgen, and
we traverse the words ourselves both in __gitcompadd, and __gitcomp_1.
So lets squash the functions together, and traverse only once.
This improves performance.
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b72f24..82ea7b1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -56,19 +56,6 @@ __gitdir ()
fi
}
-__gitcomp_1 ()
-{
- local c IFS=$' \t\n'
- for c in $1; do
- c="$c$2"
- case $c in
- --*=*|*.) ;;
- *) c="$c " ;;
- esac
- printf '%s\n' "$c"
- done
-}
-
# The following function is based on code from:
#
# bash_completion - programmable completion functions for bash 3.2+
@@ -250,8 +237,17 @@ __gitcomp ()
--*=)
;;
*)
- local IFS=$'\n'
- __gitcompadd "$(__gitcomp_1 "${1-}" "${4-}")" "${2-}" "$cur_" ""
+ local c i=0 IFS=$' \t\n'
+ for c in $1; do
+ c="$c${4-}"
+ case $c in
+ --*=*|*.) ;;
+ *) c="$c " ;;
+ esac
+ if [[ $c == "$cur_"* ]]; then
+ COMPREPLY[i++]="${2-}$c"
+ fi
+ done
;;
esac
}
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 6/8] tmp: completion: mark SZEDER's tests as fixed
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 7fb5b50..4e2f4fb 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -174,7 +174,7 @@ test_expect_success '__gitcomp - suffix' '
test_cmp expected out
'
-test_expect_failure '__gitcomp - doesnt fail because of invalid variable name' '
+test_expect_success '__gitcomp - doesnt fail because of invalid variable name' '
__gitcomp "$invalid_variable_name"
'
@@ -213,7 +213,7 @@ test_expect_success '__gitcomp_nl - no suffix' '
EOF
'
-test_expect_failure '__gitcomp_nl - doesnt fail because of invalid variable name' '
+test_expect_success '__gitcomp_nl - doesnt fail because of invalid variable name' '
__gitcomp_nl "$invalid_variable_name"
'
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 5/8] completion: get rid of compgen
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
The functionality we use from compgen is not much, we can do the same
manually, with drastical improvements in speed, specially when dealing
with only a few rods.
This patch also has the sideffect that brekage reported by Jeroen Meijer
and SZEDER Gábor gets fixed because we no longer expand the resulting
words.
Other solutions with awk and sed are possible and more efficient when
dealing with tens of thousands of words. But is rarely the case. For the
common cases, this solution is faster.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 15 ++++++++++-----
t/t9902-completion.sh | 2 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 19e18a8..0b72f24 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -227,11 +227,16 @@ fi
__gitcompadd ()
{
- COMPREPLY=($(compgen -W "$1" -P "$2" -S "$4" -- "$3"))
+ local i=0
+ for x in $1; do
+ if [[ "$x" == "$3"* ]]; then
+ COMPREPLY[i++]="$2$x$4"
+ fi
+ done
}
-# Generates completion reply with compgen, appending a space to possible
-# completion words, if necessary.
+# Generates completion reply, appending a space to possible completion words,
+# if necessary.
# It accepts 1 to 4 arguments:
# 1: List of possible completion words.
# 2: A prefix to be added to each possible completion word (optional).
@@ -251,8 +256,8 @@ __gitcomp ()
esac
}
-# Generates completion reply with compgen from newline-separated possible
-# completion words by appending a space to all of them.
+# Generates completion reply from newline-separated possible completion words
+# by appending a space to all of them.
# It accepts 1 to 4 arguments:
# 1: List of possible completion words, separated by a single newline.
# 2: A prefix to be added to each possible completion word (optional).
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 35fc31b..7fb5b50 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -340,7 +340,7 @@ test_expect_success 'complete tree filename with spaces' '
EOF
'
-test_expect_failure 'complete tree filename with metacharacters' '
+test_expect_success 'complete tree filename with metacharacters' '
echo content >"name with \${meta}" &&
git add . &&
git commit -m meta &&
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 4/8] tmp: completion: add SZEDER's tests
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
Separate patch series, but the results are relevant.
+ modifications from me.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 79a2453..35fc31b 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -73,6 +73,24 @@ test_completion_long ()
newline=$'\n'
+# Test __gitcomp_nl
+# Arguments are:
+# 1: current word (cur)
+# -: the rest are passed to __gitcomp_nl
+test_gitcomp_nl ()
+{
+ local -a COMPREPLY &&
+ sed -e 's/Z$//' > expected &&
+ cur="$1" &&
+ shift &&
+ __gitcomp_nl "$@" &&
+ print_comp &&
+ cp expected out /tmp
+ test_cmp expected out
+}
+
+invalid_variable_name="${foo.bar}"
+
test_expect_success '__gitcomp - trailing space - options' '
sed -e "s/Z$//" >expected <<-\EOF &&
--reuse-message=Z
@@ -156,6 +174,49 @@ test_expect_success '__gitcomp - suffix' '
test_cmp expected out
'
+test_expect_failure '__gitcomp - doesnt fail because of invalid variable name' '
+ __gitcomp "$invalid_variable_name"
+'
+
+read -r -d "" refs <<-\EOF
+maint
+master
+next
+pu
+EOF
+
+test_expect_success '__gitcomp_nl - trailing space' '
+ test_gitcomp_nl "m" "$refs" <<-EOF
+ maint Z
+ master Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - prefix' '
+ test_gitcomp_nl "--fixup=m" "$refs" "--fixup=" "m" <<-EOF
+ --fixup=maint Z
+ --fixup=master Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - suffix' '
+ test_gitcomp_nl "branch.ma" "$refs" "branch." "ma" "." <<-\EOF
+ branch.maint.Z
+ branch.master.Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - no suffix' '
+ test_gitcomp_nl "ma" "$refs" "" "ma" "" <<-\EOF
+ maintZ
+ masterZ
+ EOF
+'
+
+test_expect_failure '__gitcomp_nl - doesnt fail because of invalid variable name' '
+ __gitcomp_nl "$invalid_variable_name"
+'
+
test_expect_success 'basic' '
run_completion "git " &&
# built-in
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 2/8] completion: get rid of empty COMPREPLY assignments
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
There's no functional reason for those, the only purpose they are
supposed to serve is to say "we don't provide any words here", but even
for that it's not used consitently.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 27 ---------------------------
1 file changed, 27 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bc0657a..c2fb061 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -238,7 +238,6 @@ __gitcomp ()
case "$cur_" in
--*=)
- COMPREPLY=()
;;
*)
local IFS=$'\n'
@@ -486,7 +485,6 @@ __git_complete_remote_or_refspec ()
case "$cmd" in
push) no_complete_refspec=1 ;;
fetch)
- COMPREPLY=()
return
;;
*) ;;
@@ -502,7 +500,6 @@ __git_complete_remote_or_refspec ()
return
fi
if [ $no_complete_refspec = 1 ]; then
- COMPREPLY=()
return
fi
[ "$remote" = "." ] && remote=
@@ -776,7 +773,6 @@ _git_am ()
"
return
esac
- COMPREPLY=()
}
_git_apply ()
@@ -796,7 +792,6 @@ _git_apply ()
"
return
esac
- COMPREPLY=()
}
_git_add ()
@@ -811,7 +806,6 @@ _git_add ()
"
return
esac
- COMPREPLY=()
}
_git_archive ()
@@ -856,7 +850,6 @@ _git_bisect ()
__gitcomp_nl "$(__git_refs)"
;;
*)
- COMPREPLY=()
;;
esac
}
@@ -969,7 +962,6 @@ _git_clean ()
return
;;
esac
- COMPREPLY=()
}
_git_clone ()
@@ -993,7 +985,6 @@ _git_clone ()
return
;;
esac
- COMPREPLY=()
}
_git_commit ()
@@ -1027,7 +1018,6 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
}
_git_describe ()
@@ -1152,7 +1142,6 @@ _git_fsck ()
return
;;
esac
- COMPREPLY=()
}
_git_gc ()
@@ -1163,7 +1152,6 @@ _git_gc ()
return
;;
esac
- COMPREPLY=()
}
_git_gitk ()
@@ -1240,7 +1228,6 @@ _git_init ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_files ()
@@ -1259,7 +1246,6 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_remote ()
@@ -1375,7 +1361,6 @@ _git_mergetool ()
return
;;
esac
- COMPREPLY=()
}
_git_merge_base ()
@@ -1391,7 +1376,6 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
}
_git_name_rev ()
@@ -1681,7 +1665,6 @@ _git_config ()
return
;;
*.*)
- COMPREPLY=()
return
;;
esac
@@ -2061,7 +2044,6 @@ _git_remote ()
__gitcomp "$c"
;;
*)
- COMPREPLY=()
;;
esac
}
@@ -2105,7 +2087,6 @@ _git_rm ()
return
;;
esac
- COMPREPLY=()
}
_git_shortlog ()
@@ -2174,8 +2155,6 @@ _git_stash ()
*)
if [ -z "$(__git_find_on_cmdline "$save_opts")" ]; then
__gitcomp "$subcommands"
- else
- COMPREPLY=()
fi
;;
esac
@@ -2188,14 +2167,12 @@ _git_stash ()
__gitcomp "--index --quiet"
;;
show,--*|drop,--*|branch,--*)
- COMPREPLY=()
;;
show,*|apply,*|drop,*|pop,*|branch,*)
__gitcomp_nl "$(git --git-dir="$(__gitdir)" stash list \
| sed -n -e 's/:.*//p')"
;;
*)
- COMPREPLY=()
;;
esac
fi
@@ -2312,7 +2289,6 @@ _git_svn ()
__gitcomp "--revision= --parent"
;;
*)
- COMPREPLY=()
;;
esac
fi
@@ -2337,13 +2313,10 @@ _git_tag ()
case "$prev" in
-m|-F)
- COMPREPLY=()
;;
-*|tag)
if [ $f = 1 ]; then
__gitcomp_nl "$(__git_tags)"
- else
- COMPREPLY=()
fi
;;
*)
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 3/8] completion: add new __gitcompadd helper
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplification of the completion tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c2fb061..19e18a8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
fi
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W "$1" -P "$2" -S "$4" -- "$3"))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -241,9 +246,7 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" \
- -W "$(__gitcomp_1 "${1-}" "${4-}")" \
- -- "$cur_"))
+ __gitcompadd "$(__gitcomp_1 "${1-}" "${4-}")" "${2-}" "$cur_" ""
;;
esac
}
@@ -260,7 +263,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
+ __gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
}
__git_heads ()
@@ -1605,7 +1608,7 @@ _git_config ()
local remote="${prev#remote.}"
remote="${remote%.fetch}"
if [ -z "$cur" ]; then
- COMPREPLY=("refs/heads/")
+ __gitcompadd "refs/heads/"
return
fi
__gitcomp_nl "$(__git_refs_remotes "$remote")"
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH v2 0/8] completion: compgen/compadd cleanups
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
Hi,
These were hinted by SZEDER, so I went ahead and implemented the changes trying
to keep in mind the new zsh completion werapper. The resulting code should be
more efficient, and a known breakage is fixed.
The first two patches are transplanted from another patch series which most
likely is not going to use them.
I also borrowed the tests from another patch series from SZEDER, but they are
not meant to be applied through this series.
SZEDER implemented some of this, but I prefer my version of the patches.
Felipe Contreras (8):
completion: trivial test improvement
completion: get rid of empty COMPREPLY assignments
completion: add new __gitcompadd helper
tmp: completion: add SZEDER's tests
completion: get rid of compgen
tmp: completion: mark SZEDER's tests as fixed
completion: get rid of __gitcomp_1
completion: small optimization
contrib/completion/git-completion.bash | 77 ++++++++++++----------------------
t/t9902-completion.sh | 66 ++++++++++++++++++++++++++++-
2 files changed, 91 insertions(+), 52 deletions(-)
--
1.8.0
^ permalink raw reply
* [RFC/PATCH v2 1/8] completion: trivial test improvement
From: Felipe Contreras @ 2012-11-18 10:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Felipe Contreras,
Björn Gustavsson, Shawn O. Pearce, Robert Zeh,
Peter van der Does, Jonathan Nieder, Jeff King
In-Reply-To: <1353236213-13471-1-git-send-email-felipe.contreras@gmail.com>
Instead of passing a dummy "", let's check if the last character is a
space, and then move the _cword accordingly.
Apparently we were passing "" all the way to compgen, which fortunately
expanded it to nothing.
Lets do the right thing though.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 8fa025f..79a2453 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -50,6 +50,7 @@ run_completion ()
local -a COMPREPLY _words
local _cword
_words=( $1 )
+ test "${1: -1}" == ' ' && _words+=('')
(( _cword = ${#_words[@]} - 1 ))
__git_wrap__git_main && print_comp
}
@@ -156,7 +157,7 @@ test_expect_success '__gitcomp - suffix' '
'
test_expect_success 'basic' '
- run_completion "git \"\"" &&
+ run_completion "git " &&
# built-in
grep -q "^add \$" out &&
# script
--
1.8.0
^ permalink raw reply related
* [PATCH v3 6/6] completion: simplify __gitcomp() test helper
From: Felipe Contreras @ 2012-11-18 10:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1353235917-13059-1-git-send-email-felipe.contreras@gmail.com>
By using print_comp as suggested by SZEDER Gábor.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index fba632f..42db3da 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -69,23 +69,18 @@ test_completion ()
test_cmp expected out
}
-newline=$'\n'
-
# Test __gitcomp
# Arguments are:
# 1: current word (cur)
# -: the rest are passed to __gitcomp
test_gitcomp ()
{
+ local -a COMPREPLY &&
sed -e 's/Z$//' > expected &&
- (
- local -a COMPREPLY &&
- cur="$1" &&
- shift &&
- __gitcomp "$@" &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
+ cur="$1" &&
+ shift &&
+ __gitcomp "$@" &&
+ print_comp &&
test_cmp expected out
}
--
1.8.0
^ 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