All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	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 12:22:15 +0200	[thread overview]
Message-ID: <20120417102215.GA22778@goldbirke> (raw)
In-Reply-To: <CAMP44s1CTCPThri6mq0NTvD27WTEiwLTfhHCw+nD+8YwApwL=g@mail.gmail.com>

On Tue, Apr 17, 2012 at 09:32:29AM +0300, Felipe Contreras wrote:
> On Tue, Apr 17, 2012 at 3:31 AM, SZEDER Gábor <szeder@fzi.de> wrote:
> > 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?
> 
> I don't think the order is relevant, just that all the options are
> there, 

The order of options is not relevant in the completion script, because
Bash will sort them alphabetically anyway.  But it is relevant in the
test: it fails if the order is changed either in the completion script
or in the test.

> and the ones with arguments have a = in there, and the ones
> that don't, a space.

Couldn't we check that better with a test or two for __gitcomp()?

If a test for __gitcomp() fails, we would immediately have a fairly
good idea where to look for the cause of the breakage.  However, if
this 'double dash "git checkout"' test fails, there are a bunch of
other things that can possibly cause the failure.

Patch comes in a minute.

Best,
Gábor

  reply	other threads:[~2012-04-17 10:22 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
2012-04-17  6:32   ` Felipe Contreras
2012-04-17 10:22     ` SZEDER Gábor [this message]
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=20120417102215.GA22778@goldbirke \
    --to=szeder@ira.uka.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.