[RFC/PATCH] Make “git tag --contains <id>” less chatty if <id> is invalid (gsoc)

[RFC/PATCH] Make “git tag --contains <id>” less chatty if <id> is invalid (gsoc)

[Varun Garg]

Hi Git devs,

I am a student interested for Gsoc. With my patch I am able to produce following output.

    $ git tag --contains qq
    error: malformed object name qq

    $ git tag --contains HEAD qq
    fatal: --contains option is only allowed with -l.

    $ git tag --contains 5c5c16af33f3cba2f7ce905514c04c4e173b11dc
    error: no such commit 5c5c16af33f3cba2f7ce905514c04c4e173b11dc

    $ git rev-parse --verify qq
    fatal: Needed a single revision

This makes git less chatty, and solves the problem with  https://public-inbox.org/git/20160323224113.GB12531@sigill.intra.peff.net/.

Here is the patch

$cat less_chatty.patch 
diff --git a/parse-options.c b/parse-options.c
index a23a1e67f..603c77c61 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -160,7 +160,7 @@ static int get_value(struct parse_opt_ctx_t *p,
             return (*opt->callback)(opt, NULL, 0) ? (-1) : 0;
         if (get_arg(p, opt, flags, &arg))
             return -1;
-        return (*opt->callback)(opt, arg, 0) ? (-1) : 0;
+        return (*opt->callback)(opt, arg, 0) ? (-3) : 0;
 
     case OPTION_INTEGER:
         if (unset) {
@@ -506,6 +506,8 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
             goto show_usage_error;
         case -2:
             goto unknown;
+                case -3:
+                        return PARSE_OPT_HELP;
         }
         continue;
 unknown:

What I have done is, created a new case(-3) which is error but not to be displayed. In case 1, function usage_with_options_internal() is called which returns PARSE_OPT_HELP (and doesen't modify given parameters). So directly returning it from 3rd case should directly skip help text without affecting program behavior. This gave me the desired results.

However, when I run the tests, I get following behavior with cherry picking,


$ ./t3502-cherry-pick-merge.sh 
ok 1 - setup
not ok 2 - cherry-pick -m complains of bogus numbers
#    
#        # expect 129 here to distinguish between cases where
#        # there was nothing to cherry-pick
#        test_expect_code 129 git cherry-pick -m &&
#        test_expect_code 129 git cherry-pick -m foo b &&
#        test_expect_code 129 git cherry-pick -m -1 b &&
#        test_expect_code 129 git cherry-pick -m 0 b
#    
ok 3 - cherry-pick a non-merge with -m should fail

I have no idea where and why it is coming. (maybe it wants a more chatty git). Any help would be really appreciated since gsoc deadline is very close and I have to write a proposal.

Regards
Varun garg