Weak option parsing in `git submodule`

I recently faced the consequence of the weak option parsing done by in `git submodule`. Initially tried to add a new submodule using the `git submodule add` sub-command in the following way,

    $ git submodule add ./foo/bar

This cloned the submodule into a new directory named 'bar' in the present directory. This was initially confusing as I expected `git submodule` to use the actual directory itself as it resides inside a sub-directory the main project and thus avoiding the creation of a new clone. Then I came to know that `git submodule` wasn't smart enough yet to identify this, by reading the documentation. Then, after realizing that I would have to specify the path in the command to avoid the redundant clone, I corrected the command without consulting the documentation (thoroughly) to,

    $ git submodule add ./foo/bar --path ./foo/bar

expecting that the path needs to be specified after an argument. This is what triggered the weird consequence of weak option parsing. The output I got for the above command was:

    The following path is ignored by one of your .gitignore files:
    --path
    Use -f if you really want to add it.

That really confused me pretty much (being a person who doesn't know much about how `git submodule` works). Instead of complaining about an inexistent option '--path', it considers '--path' to be the <path> argument which seems to be bad. It doesn't even complain about the extra argument. I also dug to find the reason behind this totally weird message. It seems to be a consequence of the following lousy check ($sm_path is the normalized <path> argument):

    if test -z "$force" &&
            ! git add --dry-run --ignore-missing --no-warn-embedded-repo "$sm_path" > /dev/null 2>&1
    then
            eval_gettextln "The following path is ignored by one of your .gitignore files:
    \$sm_path
    Use -f if you really want to add it." >&2
            exit 1
    fi

    The lack of checking for the reason behind why `git add` fails seems to
    be the reason behind that weird message.

    Ways to fix this:

    1. Fix this particular issue by adding a '--' after the '--no-warn-
    embedded-repo' option in the above check. But that would also
    require that we allow other parts of the script to accept weird
    paths such as '--path'. Not so useful/helpful.

    2. Check for the actual return value of `git add` in the check and
    act accordingly. Also, check if there are unnecessary arguments for
    `submodule add`.

    3. Tighten option parsing in the `git-submodule` script to ensure
    this doesn't happen in the long term and helps users to get more
    relevant error messages.

    I find 3 to be a long term solution but not sure if it's worth trying
    as there are efforts towards porting `git submodule` to C. So, I guess
    we should at least do 2 as a short-term solution.

    Thoughts??

    -- 
    Sivaraam

    QUOTE:

    “The most valuable person on any team is the person who makes everyone
    else on the team more valuable, not the person who knows the most.”

          - Joel Spolsky

    Sivaraam?

    You possibly might have noticed that my signature recently changed from
    'Kaartic' to 'Sivaraam' both of which are parts of my name. I find the
    new signature to be better for several reasons one of which is that the
    former signature has a lot of ambiguities as it is a common name (NOTE:
    it's not a common spelling, just a common name). So, I switched
    signatures before it's too late.

    That said, I won't mind you calling me 'Kaartic' if you like it [of
    course ;-)]. You can always call me using either of the names.

    KIND NOTE TO THE NATIVE ENGLISH SPEAKER:

    As I'm not a native English speaker myself, there might be mistaeks in
    my usage of English. I apologise for any mistakes that I make.

    It would be "helpful" if you take the time to point out the mistakes.

    It would be "super helpful" if you could provide suggestions about how
    to correct those mistakes.

    Thanks in advance!