* 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] 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: 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 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: [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: [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 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
* [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: 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
* 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: 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: 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
* [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: [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
* 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
* 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: cloning a namespace downloads all the objects
From: Jeff King @ 2012-11-16 17:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh Triplett, Git Mailing List, Sitaram Chamarty
In-Reply-To: <7vvcd57b32.fsf@alter.siamese.dyndns.org>
On Fri, Nov 16, 2012 at 08:43:13AM -0800, Junio C Hamano wrote:
> > I have a repo on a server, which contains, as namespaces, the contents
> > of several different repos of varying sizes. When I run a clone
> > command for the smallest of the namespaces (I have a script that
> > intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
> > correct set of refs, but *all* the objects from *all* the namespaces.
> >
> > And since no refs from the other namespaces have come down, a 'git gc
> > --prune=now', run immediately after, reduces the size of
> > ".git/objects" to the size I would expect for just that small
> > namespace.
> >
> > In effect, it is bringing down data that is not reachable and will be
> > wiped out on the next gc.
> >
> > Is this expected?
>
> I do not think so.
>
> This was done with a series between a1bea2c (ref namespaces:
> infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests,
> 2011-07-21); Josh, care to comment on and to look into it?
I'd guess that the "create_full_pack" logic in create_pack_file is to
blame. The client asked for everything we advertised, so we pass "--all"
to pack-objects rather than giving it the specific list of tips.
We'd have to either fix that logic, or teach the pack-objects subprocess
to respect GIT_NAMESPACE when processing --all.
-Peff
^ permalink raw reply
* Re: [PATCH v3] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 17:21 UTC (permalink / raw)
To: Marc Khouzam; +Cc: SZEDER Gábor, git
In-Reply-To: <CAFj1UpGmoEiLeHPh8LaUGLktV55YbTthi1wMNjLDn6vFMSdMwQ@mail.gmail.com>
On Fri, Nov 16, 2012 at 5:12 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> diff --git a/contrib/completion/git-completion.tcsh
> b/contrib/completion/git-completion.tcsh
> new file mode 100644
> index 0000000..76395f9
> --- /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[*]}"
> +EOF
> +
> +complete git 'p/*/`bash ${__git_tcsh_completion_script}
> "${COMMAND_LINE}" | \sort | \uniq`/'
> +complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
> "${COMMAND_LINE}" | \sort | \uniq`/'
This looks good to me. Except that maybe the sort and uniq can be
moved to inside the script.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 17:18 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <CAFj1UpHLf2je_+b1e5B_5thZ03UYVmW=CWhAh63kNRCbke0kQw@mail.gmail.com>
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.
> 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. Correct me if I'm wrong, but very
few people use tcsh.
--
Felipe Contreras
^ permalink raw reply
* Re: cloning a namespace downloads all the objects
From: Junio C Hamano @ 2012-11-16 16:43 UTC (permalink / raw)
To: Josh Triplett; +Cc: Git Mailing List, Sitaram Chamarty
In-Reply-To: <CAMK1S_hdsgXoPcSn__htpGCpmCsAGb9j+m+SvxtO_69eqC92gA@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Hi,
>
> I have a repo on a server, which contains, as namespaces, the contents
> of several different repos of varying sizes. When I run a clone
> command for the smallest of the namespaces (I have a script that
> intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
> correct set of refs, but *all* the objects from *all* the namespaces.
>
> And since no refs from the other namespaces have come down, a 'git gc
> --prune=now', run immediately after, reduces the size of
> ".git/objects" to the size I would expect for just that small
> namespace.
>
> In effect, it is bringing down data that is not reachable and will be
> wiped out on the next gc.
>
> Is this expected?
I do not think so.
This was done with a series between a1bea2c (ref namespaces:
infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests,
2011-07-21); Josh, care to comment on and to look into it?
^ permalink raw reply
* cloning a namespace downloads all the objects
From: Sitaram Chamarty @ 2012-11-16 16:34 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have a repo on a server, which contains, as namespaces, the contents
of several different repos of varying sizes. When I run a clone
command for the smallest of the namespaces (I have a script that
intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
correct set of refs, but *all* the objects from *all* the namespaces.
And since no refs from the other namespaces have come down, a 'git gc
--prune=now', run immediately after, reduces the size of
".git/objects" to the size I would expect for just that small
namespace.
In effect, it is bringing down data that is not reachable and will be
wiped out on the next gc.
Is this expected?
--
Sitaram
^ permalink raw reply
* [PATCH v3] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 16:12 UTC (permalink / raw)
To: Felipe Contreras, SZEDER Gábor, git
In-Reply-To: <CAFj1UpHLf2je_+b1e5B_5thZ03UYVmW=CWhAh63kNRCbke0kQw@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>
---
Here's another version which adds contrib/completion/git-completion.tcsh but
does not modify contrib/completion/git-completion.bash at all.
(Sorry, but I still can't get gmail to stop changing the tabs for spaces)
Thanks in advance.
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..76395f9
--- /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[*]}"
+EOF
+
+complete git 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}" | \sort | \uniq`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}" | \sort | \uniq`/'
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 15:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: szeder, git
In-Reply-To: <CAMP44s1RtOj6LKCNJ8SX8KSA8eNCMZ+4D-VfQ+WtXju-KhG8ng@mail.gmail.com>
On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>>>> 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 executing (versus sourcing) the bash script and
>>>> outputting the completion result for tcsh consumption.
>>>>
>>>> Three solutions were looked at to implement this approach with (A)
>>>> being retained:
>>>>
>>>> A) Modifications:
>>>> git-completion.bash and new git-completion.tcsh
>>>
>>> As I said, I don't think this is needed. It can be done in a single
>>> stand-alone script without modifications to git-completion.bash.
>>>
>>> This works:
>>
>> Thank you for taking the time to try things out.
>>
>> What you suggest below is an improvement on solution (C).
>> I had chosen (A) instead because (C) creates a third script
>> which gets generated each time a new shell is started.
>
> We could generate the script only when it's not already present. The
> disadvantage is that if this script is updated, the helper one would
> not.
I didn't like that too much either.
> One way to solve the problem would be to append the current
> version of git, and figure a way to query it out. Another would be to
> checksum it. But then again, maybe it's more expensive to check the
> version or checksum than just write the file again.
Yeah, I'm also thinking that re-generating the script is not bad enough
to introduce this complexity.
> 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.
I think the most user-friendly option is to actually re-generate the
script each time. It feels wrong, but it works well :)
>>> set called = ($_)
>>
>> I fought with this a lot before posting to the list.
>> It seems that $_ is not set when a double sourcing
>> happens. Testing the solution as an actual user
>> showed me that when I start a new shell it
>> sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
>> and then $_ is empty for some reason.
>>
>> I couldn't find another way to figure out where the script
>> is located, which is why I had to force the user to use
>> ${HOME} for everything.
>
> Ah :(
>
> --
> Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 15:33 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <CAFj1UpEdft+L5KW+tMy6Lqm1eUkHQgwWuXaC0UTUdqwW=ohk-Q@mail.gmail.com>
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>>> 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 executing (versus sourcing) the bash script and
>>> outputting the completion result for tcsh consumption.
>>>
>>> Three solutions were looked at to implement this approach with (A)
>>> being retained:
>>>
>>> A) Modifications:
>>> git-completion.bash and new git-completion.tcsh
>>
>> As I said, I don't think this is needed. It can be done in a single
>> stand-alone script without modifications to git-completion.bash.
>>
>> This works:
>
> Thank you for taking the time to try things out.
>
> What you suggest below is an improvement on solution (C).
> I had chosen (A) instead because (C) creates a third script
> which gets generated each time a new shell is started.
We could generate the script only when it's not already present. The
disadvantage is that if this script is updated, the helper one would
not. One way to solve the problem would be to append the current
version of git, and figure a way to query it out. Another would be to
checksum it. But then again, maybe it's more expensive to check the
version or checksum than just write the file again.
Is it possible to just check if this is a login shell?
>> set called = ($_)
>
> I fought with this a lot before posting to the list.
> It seems that $_ is not set when a double sourcing
> happens. Testing the solution as an actual user
> showed me that when I start a new shell it
> sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
> and then $_ is empty for some reason.
>
> I couldn't find another way to figure out where the script
> is located, which is why I had to force the user to use
> ${HOME} for everything.
Ah :(
--
Felipe Contreras
^ permalink raw reply
* RE: Local clones aka forks disk size optimization
From: Pyeron, Jason J CTR (US) @ 2012-11-16 14:55 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CALZVapmBM78UtjAiNm2VoeWuetCiyxN70mTxbG14SQh5a5RCeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
> -----Original Message-----
> From: Javier Domingo
> Sent: Wednesday, November 14, 2012 8:15 PM
>
> Hi Andrew,
>
> Doing this would require I got tracked which one comes from which. So
> it would imply some logic (and db) over it. With the hardlinking way,
> it wouldn't require anything. The idea is that you don't have to do
> anything else in the server.
>
> I understand that it would be imposible to do it for windows users
Not true, it is a file system issue not an os issue. FAT does not support hard links, but ext2,3,4 and NTFS do.
> (but using cygwin), but for *nix ones yes...
> Javier Domingo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ 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