* Auto-repo-repair
From: Enrico Weigelt @ 2012-11-16 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <0c0e34a4-16ab-40a0-9293-af94e34e4290@zcs>
Hi folks,
suppose the following scenario:
I've broken some repo (missing objects), eg by messing something up
w/ alternates, broken filesystem, or whatever. And I've got a bunch
of remotes which (together) contain all of the lost objects.
Now I'd like to run some $magic_command which automatically fetches
all the missing objects and so repair my local repo.
Is this already possible right now ?
thx
--
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: Local clones aka forks disk size optimization
From: Enrico Weigelt @ 2012-11-16 18:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Andrew Ardill, Javier Domingo, git, Sitaram Chamarty
In-Reply-To: <50A622A9.4040709@drmicha.warpmail.net>
> Provide one "main" clone which is bare, pulls automatically, and is
> there to stay (no pruning), so that all others can use that as a
> reliable alternates source.
The problem here, IMHO, is the assumption, that the main repo will
never be cleaned up. But what to do if you dont wanna let it grow
forever ?
hmm, distributed GC is a tricky problem.
maybe it could be easier having two kind of alternates:
a) classical: gc+friends will drop local objects that are
already there
b) fallback: normal operations fetch objects if not accessible
from anywhere else, but gc+friends do not skip objects from there.
And extend prune machinery to put some backup of the dropped objects
to some separate store.
This way we could use some kind of rotating archive:
* GC'ed objects will be stored in the backup repo for some while
* there are multiple active (rotating) backups kept for some time,
each cycle, only the oldest one is dropped (and maybe objects
in a newer backup are removed from the older ones)
* downstream repos must be synced often enough, so removed objects
are fetched back from the backups early enough
You could see this as some heap:
* the currently active objects (directly referenced) are always
on the top
* once they're not referenced, they sink a lever deeper
* when the're referenced again, they immediately jump up to the top
* at some point in time unreferenced objects sink too deep that
they're dropped completely
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: [PATCH] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 18:20 UTC (permalink / raw)
To: Felipe Contreras; +Cc: szeder, git
In-Reply-To: <CAMP44s1RvMSBu2RJqKw9ne4cJyMO4dbFc-gW2HgsN2-uviv=fA@mail.gmail.com>
On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>
>>> Is it possible to just check if this is a login shell?
>>
>> I think it would be nice to allow the user to manually
>> source git-completion.tcsh, in case they want to make
>> manual modifications to it.
>
> Yeah, they could still do that... because they would be running in a
> login shell.
>
> What I meant is that if the user does: tcsh
> my_script_that_has_nothing_to_do_with_completion.sh, they would not be
> executing this whole script.
Oh, I see now.
I can put a check in the script for the existence of the $prompt variable.
This will indicate if it is a login shell or not.
However, a good .cshrc file should already have such a check to avoid
sourcing a bunch of useless things. So, I personally think that we
should not add it to the git-completion.tcsh script but let the tcsh
user decide to do it herself. But I don't mind being overruled :)
>> I think the most user-friendly option is to actually re-generate the
>> script each time. It feels wrong, but it works well :)
>
> I'm not too strongly opposed to add that function to the bash
> completion, but to do it only for tcsh doesn't sound right, specially
> when there are other alternatives.
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.
> Correct me if I'm wrong, but very few people use tcsh.
Less than I originally thought, when I started working
on this patch :-\ But I'm still hoping that the those people
will be a little happier with their git completion.
Marc
>
> --
> Felipe Contreras
^ permalink raw reply
* [PATCH v4] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 18:43 UTC (permalink / raw)
To: Felipe Contreras; +Cc: SZEDER Gábor, git
In-Reply-To: <CAMP44s3rwUw1QaADgm0xVOK3ebPNVSa06QdN5voNniD2acsz0g@mail.gmail.com>
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
As suggested, I put the 'sort | uniq' inside the script.
In that case, I don't need to worry about aliases since 'sort |uniq' will
be executed in bash, for which the tcsh user surely doesn't have aliases setup.
Thanks
Marc
contrib/completion/git-completion.tcsh | 63 ++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 0000000..f0327fc
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+# 1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+# 2) Add the following line to your .tcshrc/.cshrc:
+# source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat << EOF > ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source ${__git_tcsh_completion_original_script}
+
+# Set COMP_WORDS in a way that can be handled by the bash script.
+COMP_WORDS=(\$1)
+
+# The cursor is at the end of parameter #1.
+# We must check for a space as the last character which will
+# tell us that the previous word is complete and the cursor
+# is on the next word.
+if [ "\${1: -1}" == " " ]; then
+ # The last character is a space, so our location is at the end
+ # of the command-line array
+ COMP_CWORD=\${#COMP_WORDS[@]}
+else
+ # The last character is not a space, so our location is on the
+ # last word of the command-line array, so we must decrement the
+ # count by 1
+ COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
+fi
+
+# Call _git() or _gitk() of the bash script, based on the first
+# element of the command-line
+_\${COMP_WORDS[0]}
+
+IFS=\$'\n'
+echo "\${COMPREPLY[*]}" | sort | uniq
+EOF
+
+complete git 'p/*/`bash ${__git_tcsh_completion_script} "${COMMAND_LINE}"`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script} "${COMMAND_LINE}"`/'
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Junio C Hamano @ 2012-11-16 18:52 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Jeff King, Mark Levedahl, git
In-Reply-To: <50A48391.9090207@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> My understanding:
> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case
> the installation is updated frequently.
>
> Peff or Junio, please go ahead with the patch.
>
> If it turns out that we want to support cygwin installations like 1.7.7
> which could be upgraded, but are not upgraded since they are
> "production machines we do not dare to touch" we can still improve
> the autodetection.
OK. I moved the topic forward but we may still want to rename the
name of the macro to have CYGWIN somewhere in the name.
^ permalink raw reply
* Re: Auto-repo-repair
From: Jeff King @ 2012-11-16 19:00 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: git
In-Reply-To: <dbae3a06-c14b-4c06-9863-ae4771968fe1@zcs>
On Fri, Nov 16, 2012 at 06:51:45PM +0100, Enrico Weigelt wrote:
> I've broken some repo (missing objects), eg by messing something up
> w/ alternates, broken filesystem, or whatever. And I've got a bunch
> of remotes which (together) contain all of the lost objects.
>
> Now I'd like to run some $magic_command which automatically fetches
> all the missing objects and so repair my local repo.
>
> Is this already possible right now ?
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).
The simplest thing is usually to re-clone the known-good remotes, then
copy the resulting packfiles into your original repository. You'll have
duplicated objects until your next "gc", but the resulting repack should
skip any corrupted objects and use the known-good ones.
-Peff
^ permalink raw reply
* Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Jeff King @ 2012-11-16 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git, Thomas Rast, Jonathan Nieder
In-Reply-To: <7vzk2i6s9h.fsf@alter.siamese.dyndns.org>
On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > That is a good question. That confirmation step does come after they
> > have typed their cover letter. However, if they are using --compose,
> > they are dumped in their editor with something like:
> >
> > From Jeff King <peff@peff.net> # This line is ignored.
> > GIT: Lines beginning in "GIT:" will be removed.
> > GIT: Consider including an overall diffstat or table of contents
> > GIT: for the patch you are writing.
> > GIT:
> > GIT: Clear the body content if you don't wish to send a summary.
> > From: Jeff King <peff@peff.net>
> > Subject:
> > In-Reply-To:
> >
> > which I think would count as sufficient notice of the address being
> > used.
>
> OK. Tentatively I replaced your old series with these 8 patches
> including the last one, as I tend to agree with the value the
> earlier clean-up in the series gives us in the longer term. As you
> and Felipe discussed, we may want to replace the last one with a
> simpler "don't bother asking" patch, but I think that is more or
> less an orthogonal issue.
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).
-Peff
^ permalink raw reply
* Re: [PATCH v2 5/6] completion: refactor __gitcomp related tests
From: Junio C Hamano @ 2012-11-16 19:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, SZEDER Gábor, Jonathan Nieder
In-Reply-To: <1352644558-9410-6-git-send-email-felipe.contreras@gmail.com>
Not asking for a re-roll but am asking for clarification so that I
can locally update before queuing.
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Lots of duplicated code!
... removed, you mean?
> No functional changes.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> t/t9902-completion.sh | 76 ++++++++++++++++++---------------------------------
> 1 file changed, 27 insertions(+), 49 deletions(-)
>
> 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)
> +# *: arguments to pass to __gitcomp
s/\*/remainder/, perhaps? I think you shift $1 out and do not pass
it to __gitcomp.
And expected output is from the standard input just like
test_completion?
> +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
> '
Nice shrinkage.
^ permalink raw reply
* [PATCH] Add support for a 'pre-push' hook
From: Aske Olsson @ 2012-11-16 19:42 UTC (permalink / raw)
To: git
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>
---
Documentation/git-push.txt | 11 +++-
Documentation/githooks.txt | 12 +++++
builtin/push.c | 6 +++
t/t5542-pre-push-hook.sh | 132 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 160 insertions(+), 1 deletion(-)
create mode 100644 t/t5542-pre-push-hook.sh
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..5807b6a 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run]
[--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [--prune] [-v | --verbose]
[-u | --set-upstream]
- [<repository> [<refspec>...]]
+ [ --no-verify] [<repository> [<refspec>...]]
DESCRIPTION
-----------
@@ -157,6 +157,10 @@ useful if you write an alias or script around 'git push'.
receiver share many of the same objects in common. The default is
\--thin.
+--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,
@@ -430,6 +434,11 @@ Commits A and B would no longer belong to a
branch with a symbolic name,
and so would be unreachable. As such, these commits would be removed by
a `git gc` command on the origin repository.
+HOOKS
+-----
+This command can run the `pre-push` hook. See linkgit:githooks[5] for
+more information.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..847e0f8 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -176,6 +176,18 @@ save and restore any form of metadata associated
with the working tree
(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
for an example of how to do this.
+[[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.
+
+
+
[[pre-receive]]
pre-receive
~~~~~~~~~~~
diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..9c4d2ec 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -16,6 +16,7 @@ static const char * const push_usage[] = {
};
static int thin;
+static int no_verify;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -392,6 +393,7 @@ int cmd_push(int argc, const char **argv, const
char *prefix)
N_("control recursive pushing of submodules"),
PARSE_OPT_OPTARG, option_parse_recurse_submodules },
OPT_BOOLEAN( 0 , "thin", &thin, N_("use thin pack")),
+ OPT_BOOLEAN('0', "no-verify", &no_verify, "bypass pre-push hook"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack",
N_("receive pack program")),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", N_("receive
pack program")),
OPT_BIT('u', "set-upstream", &flags, N_("set upstream for git pull/status"),
@@ -419,6 +421,10 @@ int cmd_push(int argc, const char **argv, const
char *prefix)
set_refspecs(argv + 1, argc - 1);
}
+ if (!no_verify && run_hook(NULL, "pre-push")) {
+ die(_("pre-push hook failed: exiting\n"));
+ }
+
rc = do_push(repo, flags);
if (rc == -1)
usage_with_options(push_usage, options);
diff --git a/t/t5542-pre-push-hook.sh b/t/t5542-pre-push-hook.sh
new file mode 100644
index 0000000..842aa23
--- /dev/null
+++ b/t/t5542-pre-push-hook.sh
@@ -0,0 +1,132 @@
+#!/bin/sh
+
+test_description='pre-push hook'
+
+. ./test-lib.sh
+
+D=`pwd`
+HOOK="master/.git/hooks/pre-push"
+
+# Repo pair
+mk_repo_pair () {
+ rm -rf master mirror &&
+ mkdir mirror &&
+ (
+ cd mirror &&
+ git init &&
+ git config receive.denyCurrentBranch warn
+ )
+ mkdir master &&
+ (
+ cd master &&
+ git init &&
+ git remote add $1 up ../mirror
+ )
+}
+
+# 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"
+}
+
+# nonexecutable hook
+mk_hook_no_exec () {
+rm -f "$HOOK"
+cat > "$HOOK" <<EOF
+#!/bin/sh
+echo 'test run'
+exit 0
+EOF
+}
+
+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 &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git push --no-verify --mirror up
+ )
+'
+
+test_expect_success 'push with succeeding pre-push hook' '
+ mk_repo_pair &&
+ (
+ mk_hook_exec &&
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git push --mirror up
+ )
+'
+
+test_expect_success 'push --no-verify with succeeding pre-push hook' '
+ mk_repo_pair &&
+ (
+ mk_hook_exec &&
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git push --no-verify --mirror up
+ )
+'
+
+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
+ )
+'
+
+test_expect_success 'push --no-verify with failing hook' '
+ mk_repo_pair &&
+ (
+ mk_hook_fail &&
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git push --no-verify --mirror up
+ )
+'
+
+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
+ )
+'
+test_done
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v2 5/6] completion: refactor __gitcomp related tests
From: Felipe Contreras @ 2012-11-16 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, SZEDER Gábor, Jonathan Nieder
In-Reply-To: <7v8va1mkcv.fsf@alter.siamese.dyndns.org>
On Fri, Nov 16, 2012 at 8:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Not asking for a re-roll but am asking for clarification so that I
> can locally update before queuing.
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Lots of duplicated code!
>
> ... removed, you mean?
Yes.
>> No functional changes.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> t/t9902-completion.sh | 76 ++++++++++++++++++---------------------------------
>> 1 file changed, 27 insertions(+), 49 deletions(-)
>>
>> 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)
>> +# *: arguments to pass to __gitcomp
>
> s/\*/remainder/, perhaps? I think you shift $1 out and do not pass
> it to __gitcomp.
Right, by * I meant the rest.
> And expected output is from the standard input just like
> test_completion?
Correct.
>> +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
>> '
>
> Nice shrinkage.
That's a comment about the whole patch series I hope :)
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Felipe Contreras @ 2012-11-16 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Thomas Rast, Jonathan Nieder
In-Reply-To: <20121116190811.GB2310@sigill.intra.peff.net>
On Fri, Nov 16, 2012 at 8:08 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > That is a good question. That confirmation step does come after they
>> > have typed their cover letter. However, if they are using --compose,
>> > they are dumped in their editor with something like:
>> >
>> > From Jeff King <peff@peff.net> # This line is ignored.
>> > GIT: Lines beginning in "GIT:" will be removed.
>> > GIT: Consider including an overall diffstat or table of contents
>> > GIT: for the patch you are writing.
>> > GIT:
>> > GIT: Clear the body content if you don't wish to send a summary.
>> > From: Jeff King <peff@peff.net>
>> > Subject:
>> > In-Reply-To:
>> >
>> > which I think would count as sufficient notice of the address being
>> > used.
>>
>> OK. Tentatively I replaced your old series with these 8 patches
>> including the last one, as I tend to agree with the value the
>> earlier clean-up in the series gives us in the longer term. As you
>> and Felipe discussed, we may want to replace the last one with a
>> simpler "don't bother asking" patch, but I think that is more or
>> less an orthogonal issue.
>
> 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.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4] tcsh-completion re-using git-completion.bash
From: Junio C Hamano @ 2012-11-16 19:59 UTC (permalink / raw)
To: Marc Khouzam; +Cc: Felipe Contreras, SZEDER Gábor, git
In-Reply-To: <CAFj1UpEMugSrGv53ajvCm=F_wOFm4qr1bnsR5NRPsvgC_fRs5Q@mail.gmail.com>
Marc Khouzam <marc.khouzam@gmail.com> writes:
> The current tcsh-completion support for Git, as can be found on the
> Internet, takes the approach of defining the possible completions
> explicitly. This has the obvious draw-back to require constant
> updating as the Git code base evolves.
> ...
> C) Modifications:
> New git-completion.tcsh
>
> Provide a short tcsh script that generates another script
> which extends git-completion.bash. This new script can be
> used by tcsh to perform completion.
>
> Pros:
> 1- tcsh support is entirely isolated in git-completion.tcsh
> 2- new tcsh script can be as complex as needed
> Cons (for tcsh users only):
> 1- requires the user to copy both git-completion.tcsh and
> git-completion.bash to ${HOME}
> 2- requires bash script to have a fixed name and location:
> ${HOME}/.git-completion.bash
> 3- sourcing the new script will generate a third script
>
> Approach (C) was selected avoid any modification to git-completion.bash.
>
> Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
> ---
>
> As suggested, I put the 'sort | uniq' inside the script.
> In that case, I don't need to worry about aliases since 'sort |uniq' will
> be executed in bash, for which the tcsh user surely doesn't have aliases setup.
OK, so does this look OK to everybody (it does, looking at the
difference between v3 and this one, to me)?
The patch may deserve a Reviewed-by: by Felipe, by the way. I can
add one while applying.
Thanks.
^ permalink raw reply
* Re: [PATCH v4] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Khouzam, SZEDER Gábor, git
In-Reply-To: <7v4nkpmi96.fsf@alter.siamese.dyndns.org>
On Fri, Nov 16, 2012 at 8:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Marc Khouzam <marc.khouzam@gmail.com> writes:
>
>> The current tcsh-completion support for Git, as can be found on the
>> Internet, takes the approach of defining the possible completions
>> explicitly. This has the obvious draw-back to require constant
>> updating as the Git code base evolves.
>> ...
>> C) Modifications:
>> New git-completion.tcsh
>>
>> Provide a short tcsh script that generates another script
>> which extends git-completion.bash. This new script can be
>> used by tcsh to perform completion.
>>
>> Pros:
>> 1- tcsh support is entirely isolated in git-completion.tcsh
>> 2- new tcsh script can be as complex as needed
>> Cons (for tcsh users only):
>> 1- requires the user to copy both git-completion.tcsh and
>> git-completion.bash to ${HOME}
>> 2- requires bash script to have a fixed name and location:
>> ${HOME}/.git-completion.bash
>> 3- sourcing the new script will generate a third script
>>
>> Approach (C) was selected avoid any modification to git-completion.bash.
>>
>> Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
>> ---
>>
>> As suggested, I put the 'sort | uniq' inside the script.
>> In that case, I don't need to worry about aliases since 'sort |uniq' will
>> be executed in bash, for which the tcsh user surely doesn't have aliases setup.
>
> OK, so does this look OK to everybody (it does, looking at the
> difference between v3 and this one, to me)?
>
> The patch may deserve a Reviewed-by: by Felipe, by the way. I can
> add one while applying.
That's fine by me.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Junio C Hamano @ 2012-11-16 20:04 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Jonathan Nieder
In-Reply-To: <20121116190811.GB2310@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
> ...
>> OK. Tentatively I replaced your old series with these 8 patches
>> including the last one, as I tend to agree with the value the
>> earlier clean-up in the series gives us in the longer term. As you
>> and Felipe discussed, we may want to replace the last one with a
>> simpler "don't bother asking" patch, but I think that is more or
>> less an orthogonal issue.
>
> 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).
Oh, no, you are correct. I shouldn't have said "the last one", but
instead "the later ones". The first two we should definitely keep,
at least, but the other three are not so clear.
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 20:04 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <CAFj1UpHMc-bHJgSZKY13YH_69TXkz-50g5xpLA6C+Eh0aqcN9A@mail.gmail.com>
On Fri, Nov 16, 2012 at 7:20 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>>> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>
>>>> Is it possible to just check if this is a login shell?
>>>
>>> I think it would be nice to allow the user to manually
>>> source git-completion.tcsh, in case they want to make
>>> manual modifications to it.
>>
>> Yeah, they could still do that... because they would be running in a
>> login shell.
>>
>> What I meant is that if the user does: tcsh
>> my_script_that_has_nothing_to_do_with_completion.sh, they would not be
>> executing this whole script.
>
> Oh, I see now.
>
> I can put a check in the script for the existence of the $prompt variable.
> This will indicate if it is a login shell or not.
> However, a good .cshrc file should already have such a check to avoid
> sourcing a bunch of useless things. So, I personally think that we
> should not add it to the git-completion.tcsh script but let the tcsh
> user decide to do it herself. But I don't mind being overruled :)
Sounds sensible to me.
>>> I think the most user-friendly option is to actually re-generate the
>>> script each time. It feels wrong, but it works well :)
>>
>> I'm not too strongly opposed to add that function to the bash
>> completion, but to do it only for tcsh doesn't sound right, specially
>> when there are other alternatives.
>
> 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 don't see how it could be useful to others, and if we find out that
it could, we can always move the code.
>> Correct me if I'm wrong, but very few people use tcsh.
>
> Less than I originally thought, when I started working
> on this patch :-\ But I'm still hoping that the those people
> will be a little happier with their git completion.
I think they would :) But we don't need to modify bash's script for
that (for now).
Cheers.
--
Felipe Contreras
^ permalink raw reply
* 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
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