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