On Tue, Apr 17, 2012 at 3:31 AM, SZEDER Gábor <szeder@xxxxxx> 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, and the ones with arguments have a = in there, and the ones that don't, a space. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html