From: "SZEDER Gábor" <szeder@fzi.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, "Jonathan Nieder" <jrnieder@gmail.com>,
"SZEDER Gábor" <szeder@ira.uka.de>,
"Junio C Hamano" <gitster@pobox.com>,
"Thomas Rast" <trast@student.ethz.ch>,
"Jeff King" <peff@peff.net>
Subject: Re: [PATCH v2] tests: add initial bash completion tests
Date: Tue, 17 Apr 2012 02:31:00 +0200 [thread overview]
Message-ID: <20120417003100.GB2299@goldbirke> (raw)
In-Reply-To: <1334181423-4391-1-git-send-email-felipe.contreras@gmail.com>
Hi,
I picked up Stephen Boyd's two-patch series[1] to use parse-options to
generate options for git commands, and the following test promply
failed (taken from 5c293a6b (tests: add initial bash completion tests,
2012-04-12)):
test_expect_success 'double dash "git checkout"' '
sed -e "s/Z$//" >expected <<-\EOF &&
--quiet Z
--ours Z
--theirs Z
--track Z
--no-track Z
--merge Z
--conflict=
--orphan Z
--patch Z
EOF
test_completion "git checkout --"
'
Not surprising, the completion script doesn't know about many 'git
checkout' long options. So whenever 'git checkout' learns a new long
option, this list must be updated. This won't be more work than the
update of the completion script, so this is probably OK.
But it got me thinking about what do we actually want to test here?
Whether the completion script returns the right long options in a
specific order upon 'git checkout --<TAB>'? Or whether _git() works
properly and invokes the right command-specific completion function?
Or whether regular options get a trailing space while options
expecting an argument don't? Or is this sort of an integration test
and basically all of the above?
[1] - http://thread.gmane.org/gmane.comp.version-control.git/195158/focus=195158
Best,
Gábor
next prev parent reply other threads:[~2012-04-17 0:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 21:57 [PATCH v2] tests: add initial bash completion tests Felipe Contreras
2012-04-11 23:48 ` Junio C Hamano
2012-04-12 16:15 ` Felipe Contreras
2012-04-12 17:43 ` Junio C Hamano
2012-04-12 23:18 ` Felipe Contreras
2012-04-12 23:26 ` Junio C Hamano
2012-04-13 19:45 ` Junio C Hamano
2012-04-13 9:12 ` SZEDER Gábor
2012-04-13 9:45 ` SZEDER Gábor
2012-04-13 10:48 ` Felipe Contreras
2012-04-13 11:14 ` SZEDER Gábor
2012-04-13 11:56 ` Felipe Contreras
2012-04-13 10:34 ` Felipe Contreras
2012-04-13 10:52 ` SZEDER Gábor
2012-04-13 11:33 ` Thomas Rast
2012-04-13 19:48 ` Junio C Hamano
2012-04-14 2:06 ` Felipe Contreras
2012-04-17 0:31 ` SZEDER Gábor [this message]
2012-04-17 6:32 ` Felipe Contreras
2012-04-17 10:22 ` SZEDER Gábor
2012-04-17 10:27 ` [PATCH] tests: add tests for the __gitcomp() completion helper function SZEDER Gábor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120417003100.GB2299@goldbirke \
--to=szeder@fzi.de \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
--cc=szeder@ira.uka.de \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox