* Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Jeff King @ 2012-11-16 20:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git, Thomas Rast, Jonathan Nieder
In-Reply-To: <CAMP44s2+0vFUwK+ATe-jDTRYG=kE=zFF4X_JAMZExgVw0Vtfgw@mail.gmail.com>
On Fri, Nov 16, 2012 at 08:57:43PM +0100, Felipe Contreras wrote:
> > I'm not sure how orthogonal it is. The latter half of my series is about
> > exposing the user_ident_sufficiently_given() flag. If we go with
> > Felipe's patch, then that exposed information has no users, and it may
> > not be worth it (OTOH, it's possible that some third-party script may
> > want it).
>
> Well, who is using user_ident_sufficiently_given() in the first place?
> I think 'git commit' might be suffering from the same problem that
> prompted you to split it.
It is just `git commit` now. It does not suffer from the problems that
prompted the author/committer split:
http://article.gmane.org/gmane.comp.version-control.git/209635
To expand on what I wrote there, we cannot hit case 2 because we always
ask for the committer within the same process. Case 1 is not
interesting, because we would only fail to show it if is identical to a
non-implicit committer (so even if it was implicit, we know that it is a
sane value).
-Peff
^ permalink raw reply
* Re: [PATCH] Add support for a 'pre-push' hook
From: Matthieu Moy @ 2012-11-16 20:25 UTC (permalink / raw)
To: Aske Olsson; +Cc: git
In-Reply-To: <CAJwKrPYwCE4ExmK09PURMfjYezn6vdCH_BBXU4WCwrnotyV9CA@mail.gmail.com>
Aske Olsson <askeolsson@gmail.com> writes:
> If the script .git/hooks/pre-push exists and is executable it will be
> called before a `git push` command, and when the script exits with a
> non-zero status the push will be aborted.
That sounds like a sane thing to do.
> Documentation/git-push.txt | 11 +++-
> Documentation/githooks.txt | 12 +++++
> builtin/push.c | 6 +++
> t/t5542-pre-push-hook.sh | 132 +++++++++++++++++++++++++++++++++++++++++++++
It would be nice to provide a sample hook in the default template. See
the template/ directory in Git's source code.
> +--no-verify::
> + This option bypasses the pre-push hook.
> + See also linkgit:githooks[5].
> +
> -q::
> --quiet::
> Suppress all output, including the listing of updated refs,
Here, and below: you seem to have whitespace damage. Somebody replaced
tabs with spaces I guess. Using git send-email helps avoiding this.
> +D=`pwd`
Unused variable, left from previous hacking I guess.
> +# hook that always succeeds
> +mk_hook_exec () {
> +cat > "$HOOK" <<EOF
> +#!/bin/sh
> +exit 0
> +EOF
> +chmod +x "$HOOK"
> +}
> +
> +# hook that fails
> +mk_hook_fail () {
> +cat > "$HOOK" <<EOF
> +#!/bin/sh
> +exit 1
> +EOF
> +chmod +x "$HOOK"
> +}
I'd add a "touch hook-ran" in the script, a "rm -f hook-ran" before
launching git-push, and test the file existance after the hook to make
sure it was ran.
> +test_expect_success 'push with no pre-push hook' '
> + mk_repo_pair &&
> + (
> + cd master &&
> + echo one >foo && git add foo && git commit -m one &&
> + git push --mirror up
> + )
> +'
> +
> +test_expect_success 'push --no-verify with no pre-push hook' '
> + mk_repo_pair &&
I don't think you need to re-create the repos for each tests. Tests are
good, but they're better when they're fast so avoiding useless
operations is good.
We try to write tests so that one test failure does not imply failures
of the next tests (i.e. stopping in the middle should not not leave
garbage that would prevent the next test from running), but do not
necessarily write 100% self-contained tests.
> + echo one >foo && git add foo && git commit -m one &&
test_commit ?
> +test_expect_success 'push with failing pre-push hook' '
> + mk_repo_pair &&
> + (
> + mk_hook_fail &&
> + cd master &&
> + echo one >foo && git add foo && git commit -m one &&
> + test_must_fail git push --mirror up
> + )
> +'
It would be cool to actually check that the push was not performed
(verify that the target repo is still pointing to the old revision).
Otherwise, an implementation that would call run_hook after pushing
would pass the tests.
> +test_expect_success 'push with non-executable pre-push hook' '
> + mk_repo_pair &&
> + (
> + mk_hook_no_exec &&
> + cd master &&
> + echo one >foo && git add foo && git commit -m one &&
> + git push --mirror up
> + )
> +'
> +
> +test_expect_success 'push --no-verify with non-executable pre-push hook' '
> + mk_repo_pair &&
> + (
> + mk_hook_no_exec &&
> + cd master &&
> + echo one >foo && git add foo && git commit -m one &&
> + git push --no-verify --mirror up
> + )
> +'
These two tests are not testing much. The hook is not executable, so it
shouldn't be ran, but you do not check whether the hook is ran or not.
At least make the "exit 0" an "exit 1" in the hook.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Add support for a 'pre-push' hook
From: Junio C Hamano @ 2012-11-16 20:30 UTC (permalink / raw)
To: Aske Olsson; +Cc: git
In-Reply-To: <CAJwKrPYwCE4ExmK09PURMfjYezn6vdCH_BBXU4WCwrnotyV9CA@mail.gmail.com>
Aske Olsson <askeolsson@gmail.com> writes:
> If the script .git/hooks/pre-push exists and is executable it will be
> called before a `git push` command, and when the script exits with a
> non-zero status the push will be aborted.
> The hook can be overridden by passing the '--no-verify' option to
> `git push`.
>
> The pre-push hook is usefull to run tests etc. before push. Or to make
> sure that if a binary solution like git-media, git-annex or git-bin is
> used the binaries are uploaded before the push, so when others do a
> fetch the binaries will be available already. This also reduces the
> need for introducing extra (git) commands to e.g. sync binaries.
>
> Signed-off-by: Aske Olsson <askeolsson@gmail.com>
> ---
> ...
> +[[pre-push]]
> +pre-push
> +~~~~~~~~
> +
> +This hook is invoked by 'git push' and can be bypassed with the
> +`--no-verify` option. It takes no parameter, and is invoked before
> +the push happens.
> +Exiting with a non-zero status from this script causes 'git push'
> +to abort.
> ...
> + if (!no_verify && run_hook(NULL, "pre-push")) {
> + die(_("pre-push hook failed: exiting\n"));
> + }
NAK, at least in the current form. At least the system should tell
the hook where it is pushing and what is being pushed.
After working on my notebook, I may want to push to my desktop
machine first to test it, without having to test locally on an
underpowered CPU, but when I am publishing the end result to the
wider world, I do want to test the result beforehand. Without
"where am I pushing", the hook would not help me to enforce testing
only for the latter.
A lazy "git push" without any other argument may be configured in my
repository to push its "maint", "master", "next" and "pu" branches
to the public repository. I may say "git push origin +pu", while on
one of the topic branches, to push only the "pu" branches out before
I am confident that the other branches I'll eventually publish are
ready (it is more likely that I may even *know* they are broken and
do not pass the test in such a case, and that is why I am pushing
only "pu" out). I'd want to run tests only on 'pu' in such a case.
Without "what am I pushing", the hook would not be able to help me
doing that, either.
Besides, there are five valid reasons to add a new hook to the
system, but your version of pre-push does not satisfy any of them:
http://thread.gmane.org/gmane.comp.version-control.git/94111/focus=71069
It is more like "to always cause an action before running a git
operation locally," so you can even write
cat >$HOME/bin/git-mypush <<\EOF
#!/bin/sh
run test || exit
exec git push "$@"
EOF
chmod +x $HOME/bin/git-mypush
and then can run "git mypush" instead of adding this hook.
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: SZEDER Gábor @ 2012-11-16 20:40 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Marc Khouzam, git
In-Reply-To: <CAMP44s3S4c7ciJNurxGdS2o_TDJJDkGK73dtCGji+C1NoV+Jvw@mail.gmail.com>
On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
> > I agree, and this is why I made the proposed
> > __git_complete_with_output () generic. That way it could be
> > used by other shells or programs. But at this time, only tcsh
> > would make use of it.
> >
> > If you think having __git_complete_with_output () could
> > be useful for others, I think we should go with solution (A).
> > If you don't think so, or if it is better to wait until a need
> > arises first, then solution (C) will work fine.
I think it would be useful.
> I don't see how it could be useful to others, and if we find out that
> it could, we can always move the code.
For zsh, perhaps?
As I understand the main issues with using the completion script with
zsh are the various little incompatibilities between the two shells
and bugs in zsh's emulation of Bash's completion-related builtins.
Running the completion script under Bash and using its results in zsh
would solve these issues at the root. And would allow as to remove
some if [[ -n ${ZSH_VERSION-} ]] code.
^ permalink raw reply
* Re: [PATCH v2 1/6] completion: add comment for test_completion()
From: SZEDER Gábor @ 2012-11-16 20:54 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, SZEDER Gábor,
Jonathan Nieder
In-Reply-To: <1352644558-9410-2-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
> So that it's easier to understand what it does.
>
> Also, make sure we pass only the first argument for completion.
> Shouldn't cause any functional changes because run_completion only
> checks $1.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> t/t9902-completion.sh | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index cbd0fb6..5c06709 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -54,10 +54,14 @@ run_completion ()
> __git_wrap__git_main && print_comp
> }
>
> +# Test high-level completion
> +# Arguments are:
> +# 1: typed text so far (cur)
Bash manuals calls this the current command line or words in the
current command line. I'm not sure what you mean with '(cur)' here.
The variable $cur in the completion script (or in bash-completion in
general) is something completely different.
> +# 2: expected completion
> test_completion ()
> {
> test $# -gt 1 && echo "$2" > expected
> - run_completion "$@" &&
> + run_completion "$1" &&
> test_cmp expected out
> }
>
> --
> 1.8.0
^ permalink raw reply
* Re: [PATCH v2 5/6] completion: refactor __gitcomp related tests
From: SZEDER Gábor @ 2012-11-16 21:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King, Jonathan Nieder
In-Reply-To: <1352644558-9410-6-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote:
> Lots of duplicated code!
>
> No functional changes.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> t/t9902-completion.sh | 76 ++++++++++++++++++---------------------------------
> 1 file changed, 27 insertions(+), 49 deletions(-)
Despite the impressive numbers, these tests are more useful without
this cleanup.
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 59cdbfd..66c7af6 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -71,87 +71,65 @@ test_completion ()
>
> newline=$'\n'
>
> -test_expect_success '__gitcomp - trailing space - options' '
> - sed -e "s/Z$//" >expected <<-\EOF &&
> - --reuse-message=Z
> - --reedit-message=Z
> - --reset-author Z
> - EOF
> +# Test __gitcomp.
> +# Arguments are:
> +# 1: typed text so far (cur)
The first argument is not the typed text so far, but the word
currently containing the cursor position.
> +# *: arguments to pass to __gitcomp
> +test_gitcomp ()
> +{
> + sed -e 's/Z$//' > expected &&
> (
> local -a COMPREPLY &&
> - cur="--re" &&
> - __gitcomp "--dry-run --reuse-message= --reedit-message=
> - --reset-author" &&
> + cur="$1" &&
> + shift &&
> + __gitcomp "$@" &&
> IFS="$newline" &&
> echo "${COMPREPLY[*]}" > out
> ) &&
> test_cmp expected out
> +}
> +
> +test_expect_success '__gitcomp - trailing space - options' '
> + test_gitcomp "--re" "--dry-run --reuse-message= --reedit-message=
> + --reset-author" <<-EOF
> + --reuse-message=Z
> + --reedit-message=Z
> + --reset-author Z
> + EOF
> '
>
> test_expect_success '__gitcomp - trailing space - config keys' '
> - sed -e "s/Z$//" >expected <<-\EOF &&
> + test_gitcomp "br" "branch. branch.autosetupmerge
> + branch.autosetuprebase browser." <<-\EOF
> branch.Z
> branch.autosetupmerge Z
> branch.autosetuprebase Z
> browser.Z
> EOF
> - (
> - local -a COMPREPLY &&
> - cur="br" &&
> - __gitcomp "branch. branch.autosetupmerge
> - branch.autosetuprebase browser." &&
> - IFS="$newline" &&
> - echo "${COMPREPLY[*]}" > out
> - ) &&
> - test_cmp expected out
> '
>
> test_expect_success '__gitcomp - option parameter' '
> - sed -e "s/Z$//" >expected <<-\EOF &&
> + test_gitcomp "--strategy=re" "octopus ours recursive resolve subtree" \
> + "" "re" <<-\EOF
> recursive Z
> resolve Z
> EOF
> - (
> - local -a COMPREPLY &&
> - cur="--strategy=re" &&
> - __gitcomp "octopus ours recursive resolve subtree
> - " "" "re" &&
> - IFS="$newline" &&
> - echo "${COMPREPLY[*]}" > out
> - ) &&
> - test_cmp expected out
> '
>
> test_expect_success '__gitcomp - prefix' '
> - sed -e "s/Z$//" >expected <<-\EOF &&
> + test_gitcomp "branch.me" "remote merge mergeoptions rebase" \
> + "branch.maint." "me" <<-\EOF
> branch.maint.merge Z
> branch.maint.mergeoptions Z
> EOF
> - (
> - local -a COMPREPLY &&
> - cur="branch.me" &&
> - __gitcomp "remote merge mergeoptions rebase
> - " "branch.maint." "me" &&
> - IFS="$newline" &&
> - echo "${COMPREPLY[*]}" > out
> - ) &&
> - test_cmp expected out
> '
>
> test_expect_success '__gitcomp - suffix' '
> - sed -e "s/Z$//" >expected <<-\EOF &&
> + test_gitcomp "branch.me" "master maint next pu" "branch." \
> + "ma" "." <<-\EOF
> branch.master.Z
> branch.maint.Z
> EOF
> - (
> - local -a COMPREPLY &&
> - cur="branch.me" &&
> - __gitcomp "master maint next pu
> - " "branch." "ma" "." &&
> - IFS="$newline" &&
> - echo "${COMPREPLY[*]}" > out
> - ) &&
> - test_cmp expected out
> '
>
> test_expect_success 'basic' '
> --
> 1.8.0
>
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 21:03 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Marc Khouzam, git
In-Reply-To: <20121116204017.GX12052@goldbirke>
On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
>> > I agree, and this is why I made the proposed
>> > __git_complete_with_output () generic. That way it could be
>> > used by other shells or programs. But at this time, only tcsh
>> > would make use of it.
>> >
>> > If you think having __git_complete_with_output () could
>> > be useful for others, I think we should go with solution (A).
>> > If you don't think so, or if it is better to wait until a need
>> > arises first, then solution (C) will work fine.
>
> I think it would be useful.
For what?
>> I don't see how it could be useful to others, and if we find out that
>> it could, we can always move the code.
>
> For zsh, perhaps?
Nope.
> As I understand the main issues with using the completion script with
> zsh are the various little incompatibilities between the two shells
> and bugs in zsh's emulation of Bash's completion-related builtins.
> Running the completion script under Bash and using its results in zsh
> would solve these issues at the root. And would allow as to remove
> some if [[ -n ${ZSH_VERSION-} ]] code.
We can remove that code already, because we now have code that is
superior than zsh's bash completion emulation:
http://article.gmane.org/gmane.comp.version-control.git/208173
This is the equivalent of what Marc is doing, except that zsh has no
problems running bash's code. Note there's a difference with zsh's
emulation bash (or rather bourne shell, or k shell), and zsh's
emulation of bash's _completion_. The former is fine, the later is
not.
Of course, people might not be aware of this new script, and would
expect sourcing the bash one to work right away. Maybe at some point
we might throw a warning to suggest them to use my new script. But I
think we should wait a few releases just to make sure that people test
it and nothing is broken.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 1/6] completion: add comment for test_completion()
From: Felipe Contreras @ 2012-11-16 21:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Jeff King, Jonathan Nieder
In-Reply-To: <20121116205457.GY12052@goldbirke>
On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
>> So that it's easier to understand what it does.
>>
>> Also, make sure we pass only the first argument for completion.
>> Shouldn't cause any functional changes because run_completion only
>> checks $1.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> t/t9902-completion.sh | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
>> index cbd0fb6..5c06709 100755
>> --- a/t/t9902-completion.sh
>> +++ b/t/t9902-completion.sh
>> @@ -54,10 +54,14 @@ run_completion ()
>> __git_wrap__git_main && print_comp
>> }
>>
>> +# Test high-level completion
>> +# Arguments are:
>> +# 1: typed text so far (cur)
>
> Bash manuals calls this the current command line or words in the
> current command line. I'm not sure what you mean with '(cur)' here.
The current _word_ text typed so far.
> The variable $cur in the completion script (or in bash-completion in
> general) is something completely different.
I believe bash's completion, this test, and the whole git completion
stuff uses the same definition of 'cur'.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 1/6] completion: add comment for test_completion()
From: Felipe Contreras @ 2012-11-16 21:09 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Jeff King, Jonathan Nieder
In-Reply-To: <CAMP44s333124DkyG5VX+n=p_eHRmPYCu27rsLgLQG8mOVcRBPg@mail.gmail.com>
On Fri, Nov 16, 2012 at 10:06 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
>>> So that it's easier to understand what it does.
>>>
>>> Also, make sure we pass only the first argument for completion.
>>> Shouldn't cause any functional changes because run_completion only
>>> checks $1.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>> t/t9902-completion.sh | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
>>> index cbd0fb6..5c06709 100755
>>> --- a/t/t9902-completion.sh
>>> +++ b/t/t9902-completion.sh
>>> @@ -54,10 +54,14 @@ run_completion ()
>>> __git_wrap__git_main && print_comp
>>> }
>>>
>>> +# Test high-level completion
>>> +# Arguments are:
>>> +# 1: typed text so far (cur)
>>
>> Bash manuals calls this the current command line or words in the
>> current command line. I'm not sure what you mean with '(cur)' here.
>
> The current _word_ text typed so far.
>
>> The variable $cur in the completion script (or in bash-completion in
>> general) is something completely different.
>
> I believe bash's completion, this test, and the whole git completion
> stuff uses the same definition of 'cur'.
Oops, actually in this particular helper this is not actually 'cur'. I
think 'command line' might be more appropriate.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Junio C Hamano @ 2012-11-16 21:20 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Felipe Contreras, Marc Khouzam, git
In-Reply-To: <20121116204017.GX12052@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> writes:
> For zsh, perhaps?
Yeah, I was wondering about that.
If we make zsh completion read output from a little stub in bash
completion, just like Felipe steered this series for tcsh, we do not
have to worry about "zsh does not split words unless emulating a
shell and here is a way to tell zsh to do so" kind of stuff in bash
completion. The point is not about the quality of zsh's emulation
of (k)sh when it is run under that mode, but is about not having to
have that logic in bash-only part in the first place.
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: SZEDER Gábor @ 2012-11-16 21:22 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Marc Khouzam, git
In-Reply-To: <CAMP44s2UVGKa7XkqPxdxQ2ueSMn=Xn4qihy5JWbDovH85n8BwQ@mail.gmail.com>
On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
> On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> > On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
> >> > I agree, and this is why I made the proposed
> >> > __git_complete_with_output () generic. That way it could be
> >> > used by other shells or programs. But at this time, only tcsh
> >> > would make use of it.
> >> >
> >> > If you think having __git_complete_with_output () could
> >> > be useful for others, I think we should go with solution (A).
> >> > If you don't think so, or if it is better to wait until a need
> >> > arises first, then solution (C) will work fine.
> >
> > I think it would be useful.
>
> For what?
For zsh.
> >> I don't see how it could be useful to others, and if we find out that
> >> it could, we can always move the code.
> >
> > For zsh, perhaps?
>
> Nope.
Sure.
> > As I understand the main issues with using the completion script with
> > zsh are the various little incompatibilities between the two shells
> > and bugs in zsh's emulation of Bash's completion-related builtins.
> > Running the completion script under Bash and using its results in zsh
> > would solve these issues at the root. And would allow as to remove
> > some if [[ -n ${ZSH_VERSION-} ]] code.
>
> We can remove that code already, because we now have code that is
> superior than zsh's bash completion emulation:
>
> http://article.gmane.org/gmane.comp.version-control.git/208173
Which depends on the completion script having a wrapper function
around compgen filling COMPREPLY. However, COMPREPLY will be soon
filled by hand-rolled code to prevent expansion issues with compgen,
and there will be no such wrapper.
> This is the equivalent of what Marc is doing, except that zsh has no
> problems running bash's code. Note there's a difference with zsh's
> emulation bash (or rather bourne shell, or k shell), and zsh's
> emulation of bash's _completion_. The former is fine, the later is
> not.
There are a couple of constructs supported by Bash but not by zsh,
which we usually try to avoid.
^ permalink raw reply
* Re: [PATCH] Add support for a 'pre-push' hook
From: Junio C Hamano @ 2012-11-16 21:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Aske Olsson, git
In-Reply-To: <vpq625547ne.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> +# hook that fails
>> +mk_hook_fail () {
>> +cat > "$HOOK" <<EOF
>> +#!/bin/sh
>> +exit 1
>> +EOF
>> +chmod +x "$HOOK"
>> +}
>
> I'd add a "touch hook-ran" in the script, a "rm -f hook-ran" before
> launching git-push, and test the file existance after the hook to make
> sure it was ran.
And if you create that "evidence that it did ran" file without using
"touch", it would be perfect. Unless you are updating the timestamp
of an existing file while preserving the contents of it, it is
misleading to use "touch".
All other points in your review are good. Thanks.
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 21:46 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Marc Khouzam, git
In-Reply-To: <20121116212224.GA12052@goldbirke>
On Fri, Nov 16, 2012 at 10:22 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
>> > As I understand the main issues with using the completion script with
>> > zsh are the various little incompatibilities between the two shells
>> > and bugs in zsh's emulation of Bash's completion-related builtins.
>> > Running the completion script under Bash and using its results in zsh
>> > would solve these issues at the root. And would allow as to remove
>> > some if [[ -n ${ZSH_VERSION-} ]] code.
>>
>> We can remove that code already, because we now have code that is
>> superior than zsh's bash completion emulation:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/208173
>
> Which depends on the completion script having a wrapper function
> around compgen filling COMPREPLY.
No, it does not. Previous incarnations didn't have this dependency:
http://article.gmane.org/gmane.comp.version-control.git/196720
I just thought it was neater this way.
> However, COMPREPLY will be soon
> filled by hand-rolled code to prevent expansion issues with compgen,
> and there will be no such wrapper.
I'm still waiting to see a resemblance of that code, but my bet would
be that there will be a way to fill both COMPREPLY, and call zsh's
compadd. But it's hard to figure that out without any code. Which is
why I'm thinking on doing it myself.
But even in that case, if push comes to shoves, this zsh wrapper can
ultimately read COMPREPLY and figure things backwards, as even more
previous versions did:
http://article.gmane.org/gmane.comp.version-control.git/189310
>> This is the equivalent of what Marc is doing, except that zsh has no
>> problems running bash's code. Note there's a difference with zsh's
>> emulation bash (or rather bourne shell, or k shell), and zsh's
>> emulation of bash's _completion_. The former is fine, the later is
>> not.
>
> There are a couple of constructs supported by Bash but not by zsh,
> which we usually try to avoid.
Yes, and is that a big deal?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, Marc Khouzam, git
In-Reply-To: <7vr4ntkzy4.fsf@alter.siamese.dyndns.org>
On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
>
>> For zsh, perhaps?
>
> Yeah, I was wondering about that.
>
> If we make zsh completion read output from a little stub in bash
> completion, just like Felipe steered this series for tcsh, we do not
> have to worry about "zsh does not split words unless emulating a
> shell and here is a way to tell zsh to do so" kind of stuff in bash
> completion.
Do we worry about that now? If we do, the only reason is because we
hadn't had a proper wrapper, like the one I'm proposing to merge. So,
we had to put things inside if [[ -n ${ZSH_VERSION-} ]]. Those things
would move to my wrapper.
The only exception where we had to change code outside of that chunk
that I'm aware of is '8d58c90 completion: Use parse-options raw output
for simple long options', which is probably fixed in later versions of
zsh, and if not, we could always replace those functions inside my
wrapper.
> The point is not about the quality of zsh's emulation
> of (k)sh when it is run under that mode, but is about not having to
> have that logic in bash-only part in the first place.
As I said, that logic can be moved away _if_ my wrapper is merged. But
then again, that would cause regressions to existing users.
Maybe we should warn them right now that they should be using my
wrapper, and that this method of zsh support would be obsoleted. But
my wrapper probably hasn't received enough testing, so do we really
want to do that right now?
Either way, I'm confident that whatever code we need can be
consolidated in git-completion.zsh, even without having to run bash.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 5/6] completion: refactor __gitcomp related tests
From: Junio C Hamano @ 2012-11-16 23:40 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Felipe Contreras, git, Jeff King, Jonathan Nieder
In-Reply-To: <20121116210242.GZ12052@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> writes:
> On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote:
>> Lots of duplicated code!
>>
>> No functional changes.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> t/t9902-completion.sh | 76 ++++++++++++++++++---------------------------------
>> 1 file changed, 27 insertions(+), 49 deletions(-)
>
> Despite the impressive numbers, these tests are more useful without
> this cleanup.
Is this because consolidation of the duplicated part of the tests
into a single helper makes it harder to instrument one test you are
interested in (or developing) for debugging?
It indeed is a problem, and cutting and pasting the same code to
multiple tests is one way to solve the problem (you can easily
instrument the copy in the test you are interested in while leaving
others intact), but I do not think that is a good solution. A bugfix
or enhancement to the shared (or duplicated) part can be done by
touching one place only after this change, while with the current
code you have to repeat the same fix to all places, no?
>> +# Test __gitcomp.
>> +# Arguments are:
>> +# 1: typed text so far (cur)
>
> The first argument is not the typed text so far, but the word
> currently containing the cursor position.
Care to update this with a follow-up patch, so that I do not have to
keep track of minute details ;-)?
^ permalink raw reply
* Re: [PATCH v2 4/6] completion: consolidate test_completion*() tests
From: Junio C Hamano @ 2012-11-16 23:41 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, SZEDER Gábor, Jonathan Nieder
In-Reply-To: <1352644558-9410-5-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> No need to have two versions; if a second argument is specified, use
> that, otherwise use stdin.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> t/t9902-completion.sh | 30 +++++++++++++-----------------
> 1 file changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 204c92a..59cdbfd 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -60,19 +60,15 @@ run_completion ()
> # 2: expected completion
> test_completion ()
> {
> - test $# -gt 1 && echo "$2" > expected
> + if [ $# -gt 1 ]; then
> + echo "$2" > expected
> + else
> + sed -e 's/Z$//' > expected
> + fi &&
As "$2" could begin with dash, end with \c, etc. that possibly can
be misinterpred by echo, I'd rewrite this as
printf '%s\n' "$2" >expected
Otherwise looked fine; thanks.
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #05; Fri, 16)
From: Junio C Hamano @ 2012-11-16 23:41 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Big thanks go to Jeff who curated topics in flight while I was on
vacation. I merged a couple of topics to 'next', and made the fifth
batch of topics graduate to 'master'. Over the weekend, I'll start
merging maintenance topics to 'maint' in preparation for cutting
1.8.1, hopefully sometime late next week.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 117a91e)
+ commit: fixup misplacement of --no-post-rewrite description
* cr/cvsimport-local-zone (2012-11-04) 2 commits
(merged to 'next' on 2012-11-04 at 292f0b4)
+ cvsimport: work around perl tzset issue
+ git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at eda85ef)
+ get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
* jc/prettier-pretty-note (2012-11-13) 12 commits
(merged to 'next' on 2012-11-14 at 7230f26)
+ format-patch: add a blank line between notes and diffstat
(merged to 'next' on 2012-11-04 at 40e3e48)
+ Doc User-Manual: Patch cover letter, three dashes, and --notes
+ Doc format-patch: clarify --notes use case
+ Doc notes: Include the format-patch --notes option
+ Doc SubmittingPatches: Mention --notes option after "cover letter"
+ Documentation: decribe format-patch --notes
+ format-patch --notes: show notes after three-dashes
+ format-patch: append --signature after notes
+ pretty_print_commit(): do not append notes message
+ pretty: prepare notes message at a centralized place
+ format_note(): simplify API
+ pretty: remove reencode_commit_message()
Emit the notes attached to the commit in "format-patch --notes"
output after three-dashes.
* jc/same-encoding (2012-11-04) 1 commit
(merged to 'next' on 2012-11-04 at 54991f2)
+ reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* jh/symbolic-ref-d (2012-10-21) 1 commit
(merged to 'next' on 2012-11-04 at b0762f5)
+ git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
(merged to 'next' on 2012-11-04 at 790337b)
+ diff_grep: use textconv buffers for add/deleted files
(this branch is used by jk/pickaxe-textconv.)
Fixes inconsistent use of textconv with "git log -G".
* js/hp-nonstop (2012-10-30) 1 commit
(merged to 'next' on 2012-11-09 at fe58205)
+ fix 'make test' for HP NonStop
* mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at bd74252)
+ push/pull: adjust missing upstream help text to changed interface
Follow-on to the new "--set-upstream-to" topic from v1.8.0 to avoid
suggesting the deprecated "--set-upstream".
* mh/notes-string-list (2012-11-08) 5 commits
(merged to 'next' on 2012-11-09 at 7a4c58c)
+ string_list_add_refs_from_colon_sep(): use string_list_split()
+ notes: fix handling of colon-separated values
+ combine_notes_cat_sort_uniq(): sort and dedup lines all at once
+ Initialize sort_uniq_list using named constant
+ string_list: add a function string_list_remove_empty_items()
Improve the asymptotic performance of the cat_sort_uniq notes merge
strategy.
* mh/strbuf-split (2012-11-04) 4 commits
(merged to 'next' on 2012-11-09 at fa984b1)
+ strbuf_split*(): document functions
+ strbuf_split*(): rename "delim" parameter to "terminator"
+ strbuf_split_buf(): simplify iteration
+ strbuf_split_buf(): use ALLOC_GROW()
Cleanups and documentation for strbuf_split.
* mm/maint-doc-commit-edit (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 8dab7f5)
+ Document 'git commit --no-edit' explicitly
* ph/submodule-sync-recursive (2012-10-29) 2 commits
(merged to 'next' on 2012-11-04 at a000f78)
+ Add tests for submodule sync --recursive
+ Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
--------------------------------------------------
[New Topics]
* jl/submodule-rm (2012-11-14) 1 commit
- docs: move submodule section
Documentation correction for d21240f (Merge branch
'jl/submodule-rm', 2012-10-29) that needs to be fast-tracked.
Will merge to 'next' and soon to 'master'.
* sg/complete-help-undup (2012-11-14) 1 commit
- completion: remove 'help' duplicate from porcelain commands
Will merge to 'next' and soon to 'master'.
* bc/do-not-recurse-in-die (2012-11-15) 1 commit
- usage.c: detect recursion in die routines and bail out immediately
Will merge to 'next'.
* cn/config-missing-path (2012-11-15) 1 commit
- config: don't segfault when given --path with a missing value
Will merge to 'next' and soon to 'master'.
* jk/checkout-out-of-unborn (2012-11-15) 1 commit
- checkout: print a message when switching unborn branches
Will merge to 'next'.
* mk/complete-tcsh (2012-11-16) 1 commit
- tcsh-completion re-using git-completion.bash
* mm/status-push-pull-advise (2012-11-16) 1 commit
- status: add advice on how to push/pull to tracking branch
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
- Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
--------------------------------------------------
[Stalled]
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
--------------------------------------------------
[Cooking]
* jk/maint-gitweb-xss (2012-11-12) 1 commit
(merged to 'next' on 2012-11-14 at 7a667bc)
+ gitweb: escape html in rss title
Fixes an XSS vulnerability in gitweb.
* jk/send-email-sender-prompt (2012-11-15) 8 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given static
- t7502: factor out autoident prerequisite
- test-lib: allow negation of prerequisites
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Perhaps keep only the first three patches, and replace the rest
with the one from Felipe that takes a much simpler approach (the
rationale of that patch needs to be cleaned up first, along the
lines Jeff outlined, though).
* mg/replace-resolve-delete (2012-11-13) 1 commit
(merged to 'next' on 2012-11-14 at fa785ae)
+ replace: parse revision argument for -d
Be more user friendly to people using "git replace -d".
* ml/cygwin-mingw-headers (2012-11-12) 1 commit
(merged to 'next' on 2012-11-15 at 22e11b3)
+ Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
(merged to 'next' on 2012-11-13 at e11fafd)
+ Documentation: build html for all files in technical and howto
+ Documentation/howto: convert plain text files to asciidoc
+ Documentation/technical: convert plain text files to asciidoc
+ Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
+ Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
+ Split over-long synopsis in git-fetch-pack.txt into several lines
Will merge to 'master' in the sixth batch.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
Needs some test updates.
* fc/zsh-completion (2012-10-29) 3 commits
- completion: add new zsh completion
- completion: add new __gitcompadd helper
- completion: get rid of empty COMPREPLY assignments
There were some comments on this, but I wasn't clear on the outcome.
Need to take a closer look.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will cook in 'next'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
Need to check reviews, but is probably ready for 'next'.
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.
Will merge to 'master' in the sixth batch.
* fc/completion-test-simplification (2012-11-16) 6 commits
- completion: simplify __gitcomp() test helper
- completion: refactor __gitcomp related tests
- completion: consolidate test_completion*() tests
- completion: simplify tests using test_completion_long()
- completion: standardize final space marker in tests
- completion: add comment for test_completion()
Clean up completion tests. Use of conslidated helper may make
instrumenting one particular test during debugging of the test
itself, but I think that issue should be addressed in some other
way (e.g. making sure individual tests in 9902 can be skipped).
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review.
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
Use textconv filters when searching with "log -S".
* fc/remote-bzr (2012-11-08) 5 commits
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- remote-bzr: add simple tests
- Add new remote-bzr transport helper
New remote helper for bzr.
Will merge to 'next'.
* fc/remote-hg (2012-11-12) 20 commits
- remote-hg: avoid bad refs
- remote-hg: try the 'tip' if no checkout present
- remote-hg: fix compatibility with older versions of hg
- remote-hg: add missing config for basic tests
- remote-hg: the author email can be null
- remote-hg: add option to not track branches
- remote-hg: add extra author test
- remote-hg: add tests to compare with hg-git
- remote-hg: add bidirectional tests
- test-lib: avoid full path to store test results
- remote-hg: add basic tests
- remote-hg: fake bookmark when there's none
- remote-hg: add compat for hg-git author fixes
- remote-hg: add support for hg-git compat mode
- remote-hg: match hg merge behavior
- remote-hg: make sure the encoding is correct
- remote-hg: add support to push URLs
- remote-hg: add support for remote pushing
- remote-hg: add support for pushing
- Add new remote-hg transport helper
New remote helper for hg.
Will merge to 'next'.
* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits
(merged to 'next' on 2012-11-09 at af69926)
+ remote-curl: retry failed requests for auth even with gzip
+ remote-curl: hoist gzip buffer size to top of post_rpc
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
Will merge to 'master' in the sixth batch.
* kb/preload-index-more (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at a750ebd)
+ update-index/diff-index: use core.preloadindex to improve performance
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
Will merge to 'master' in the sixth batch.
* cr/push-force-tag-update (2012-11-12) 5 commits
- push: update remote tags only with force
- push: flag updates that require force
- push: flag updates
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
Needs review.
I'm undecided yet on whether the goal is the right thing to do, but it
does prevent some potential mistakes. I haven't looked closely at the
implementation itself; review from interested parties would be helpful.
* fc/fast-export-fixes (2012-11-08) 14 commits
- fast-export: don't handle uninteresting refs
- fast-export: make sure updated refs get updated
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: make clear the 'done' feature
- remote-testgit: report success after an import
- remote-testgit: exercise more features
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: get rid of non-local functionality
- Add new simplified git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-testgit: fix direction of marks
- fast-export: avoid importing blob marks
Improvements to fix fast-export bugs, including how refs pointing to
already-seen commits are handled. An earlier 4-commit version of this
series looked good to me, but this much-expanded version has not seen
any comments.
Looks like it has been re-rolled, but I haven't checked it out yet.
Needs review.
* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits
(merged to 'next' on 2012-11-13 at 2bf41d9)
+ link_alt_odb_entries(): take (char *, len) rather than two pointers
+ link_alt_odb_entries(): use string_list_split_in_place()
Cleanups in the alternates code. Fixes a potential bug and makes the
code much cleaner.
Will merge to 'master' in the sixth batch.
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* pp/gitweb-config-underscore (2012-11-08) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
Junio raised a good point about the implementation for three-level
variables.
Expecting a re-roll.
* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at e90cc7c)
+ git p4: RCS expansion should not span newlines
I do not have p4 to play with, but looks obviously correct to me.
Will merge to 'master' in the sixth batch.
* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at c57d856)
+ gitweb.perl: fix %highlight_ext mappings
Fixes a clever misuse of perl's list interpretation.
Will merge to 'master' in the sixth batch.
* rr/submodule-diff-config (2012-11-08) 3 commits
- submodule: display summary header in bold
- diff: introduce diff.submodule configuration variable
- Documentation: move diff.wordRegex from config.txt to diff-config.txt
Lets "git diff --submodule=log" become the default via configuration.
Almost there. Looks like a new version has been posted, but I haven't
picked it up yet.
Needs review.
^ permalink raw reply
* Re: [PATCH 6/5] sequencer.c: refrain from adding duplicate s-o-b lines
From: Brandon Casey @ 2012-11-16 23:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git@vger.kernel.org,
Brandon Casey
In-Reply-To: <7v4nkq8fsn.fsf@alter.siamese.dyndns.org>
On Thu, Nov 15, 2012 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> Detect whether the s-o-b already exists in the commit footer and refrain
>> from adding a duplicate.
>
> If you are trying to forbid
>
> git cherry-pick -s $other
>
> from adding s-o-b: A when $other ends with these two existing s-o-b:
>
> s-o-b: A
> s-o-b: B
>
> then I think that is a wrong thing to do.
>
> In such a case, the resulting commit should gain another s-o-b from
> A to record the provenance as a chain of events. A originally wrote
> the patch, B forwarded it (possibly with his own tweaks), and then A
> picked it up and recorded the result to the history, possibly with a
> final tweak or two.
Hmm. I've never thought that it was necessary to add an additional
sob for the patches that I've cherry picked that I had previously
signed-off-on. I considered one sign-off to be enough. In your
example, A is the committer and the patch set already contains A's
sign-off. For me that indicates that A still considers the commit to
comply with whatever s-o-b implies.
We also seem to have a few tools to help people avoid adding duplicate
sob's, like the current behavior of format-patch and the sample
commit-msg hook.
I did some quick searching through the kernel commits to try to find
some examples that could set a precedence. I didn't find anything
that supported either argument. I didn't see any commits that were
cherry-picked _and_ had an existing sob that was not the last sob. I
didn't see any that had duplicate sob lines either. I'm not
mentioning this to say that lack of a prior use should mean we should
actively disallow the practice of adding duplicate sob's, I'm just
providing it as a data point.
I've always thought that the reason that 'commit -s' and 'cherry-pick
-s' checked only the last line of the commit message was simply that a
full scan of the footer had not been implemented.
Whichever behavior is determined to be the right way for git to do it,
format-patch should be brought in-line with the others and be built on
top of the code in sequencer.c. So, if git _should_ create duplicate
sob's then this patch should just be dropped. Duy's unification patch
can just be built on top of sequencer.c:append_signoff() without
bringing over any of the duplicate sob detection from log-tree.c.
-Brandon
^ permalink raw reply
* git log implementation details
From: Nicolas Dufour @ 2012-11-17 1:14 UTC (permalink / raw)
To: git
Hello,
I was wondering how the command "git log" is actually retrieving the
commit log for a given file behind the scene.
Is it by walking down the object tree and scanning each commit/tree
object? Or any cache/index used here?
Thank you,
Nicolas
^ permalink raw reply
* [RFC/PATCH 0/5] completion: compgen/compadd cleanups
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, 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 come from another patch series for convenience.
Take them with a pinch of salt.
Felipe Contreras (5):
completion: get rid of empty COMPREPLY assignments
completion: add new __gitcompadd helper
completion: trivial test improvement
completion: get rid of compgen
completion: refactor __gitcomp_1
contrib/completion/git-completion.bash | 68 +++++++++++++---------------------
t/t9902-completion.sh | 3 +-
2 files changed, 27 insertions(+), 44 deletions(-)
--
1.8.0
^ permalink raw reply
* [RFC/PATCH 1/5] completion: get rid of empty COMPREPLY assignments
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, Jeff King
In-Reply-To: <1353116298-11798-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 | 28 ----------------------------
1 file changed, 28 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e0..7bdd6a8 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 ()
@@ -1158,7 +1148,6 @@ _git_fsck ()
return
;;
esac
- COMPREPLY=()
}
_git_gc ()
@@ -1169,7 +1158,6 @@ _git_gc ()
return
;;
esac
- COMPREPLY=()
}
_git_gitk ()
@@ -1246,7 +1234,6 @@ _git_init ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_files ()
@@ -1265,7 +1252,6 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_remote ()
@@ -1381,7 +1367,6 @@ _git_mergetool ()
return
;;
esac
- COMPREPLY=()
}
_git_merge_base ()
@@ -1397,7 +1382,6 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
}
_git_name_rev ()
@@ -1567,7 +1551,6 @@ _git_send_email ()
return
;;
esac
- COMPREPLY=()
}
_git_stage ()
@@ -1680,7 +1663,6 @@ _git_config ()
return
;;
*.*)
- COMPREPLY=()
return
;;
esac
@@ -2060,7 +2042,6 @@ _git_remote ()
__gitcomp "$c"
;;
*)
- COMPREPLY=()
;;
esac
}
@@ -2104,7 +2085,6 @@ _git_rm ()
return
;;
esac
- COMPREPLY=()
}
_git_shortlog ()
@@ -2173,8 +2153,6 @@ _git_stash ()
*)
if [ -z "$(__git_find_on_cmdline "$save_opts")" ]; then
__gitcomp "$subcommands"
- else
- COMPREPLY=()
fi
;;
esac
@@ -2187,14 +2165,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
@@ -2311,7 +2287,6 @@ _git_svn ()
__gitcomp "--revision= --parent"
;;
*)
- COMPREPLY=()
;;
esac
fi
@@ -2336,13 +2311,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 2/5] completion: add new __gitcompadd helper
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, Jeff King
In-Reply-To: <1353116298-11798-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 7bdd6a8..975ae13 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 ()
@@ -1603,7 +1606,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 3/5] completion: trivial test improvement
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, Jeff King
In-Reply-To: <1353116298-11798-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 cbd0fb6..0b5e1f5 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -51,6 +51,7 @@ run_completion ()
local _cword
_words=( $1 )
(( _cword = ${#_words[@]} - 1 ))
+ test "${1: -1}" == ' ' && (( _cword += 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
* [RFC/PATCH 4/5] completion: get rid of compgen
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, Jeff King
In-Reply-To: <1353116298-11798-1-git-send-email-felipe.contreras@gmail.com>
The functionality we use is very simple, plus, this fixes a known
breakage 'complete tree filename with metacharacters'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 975ae13..ad3e1fe 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -227,7 +227,11 @@ fi
__gitcompadd ()
{
- COMPREPLY=($(compgen -W "$1" -P "$2" -S "$4" -- "$3"))
+ for x in $1; do
+ if [[ "$x" = "$3"* ]]; then
+ COMPREPLY+=("$2$x$4")
+ fi
+ done
}
# Generates completion reply with compgen, appending a space to possible
--
1.8.0
^ permalink raw reply related
* [RFC/PATCH 5/5] completion: refactor __gitcomp_1
From: Felipe Contreras @ 2012-11-17 1:38 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Björn Gustavsson,
Shawn O. Pearce, Robert Zeh, Peter van der Does, Jonathan Nieder,
Felipe Contreras, Jeff King
In-Reply-To: <1353116298-11798-1-git-send-email-felipe.contreras@gmail.com>
It's only used by __gitcomp, so move some code there and avoid going
through the loop again.
We could get rid of it altogether, but it's useful for zsh's completion
wrapper.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ad3e1fe..d92d11e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -58,15 +58,12 @@ __gitdir ()
__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
+ local c=$1
+ case $c in
+ --*=*|*.) ;;
+ *) c="$c " ;;
+ esac
+ printf '%s\n' "$c"
}
# The following function is based on code from:
@@ -249,10 +246,16 @@ __gitcomp ()
--*=)
;;
*)
- local IFS=$'\n'
- __gitcompadd "$(__gitcomp_1 "${1-}" "${4-}")" "${2-}" "$cur_" ""
+ local c IFS=$' \t\n'
+ for c in ${1-}; do
+ c=`__gitcomp_1 "$c${4-}"`
+ if [[ "$c" = "$cur_"* ]]; then
+ COMPREPLY+=("${2-}$c")
+ fi
+ done
;;
esac
+
}
# Generates completion reply with compgen from newline-separated possible
--
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