Jeff King wrote:
> So you would need some heuristics based on whether something was a valid
> refspec, or could be a valid remote name or URL.

All refspecs conform to a very simple format:

    quux
    +quux
    quux:baz
    +quux:baz

All of them fail at git_connect().  The third and fourth are
equivalent and take a little longer to fail than the first two,
because ssh tries to resolve the hostname "quux" or "+quux".

Okay, so I was hoping that we could first attempt to push as usual,
and fallback to pushing with the refspec set to argv[0] (if argc is
1); this approach is foolproof and doesn't involve any guessing.
Unfortunately, it's going to be very hard, as the callstack to the
final git_connect() failure looks like:

    git_connect()
    connect_setup()
    get_refs_via_connect()
    transport_push()
    push_with_options()
    do_push()

Now, it's nearly impossible to propagate the error back from
git_connect() to do_push() and switch the refspec.  It's not a simple
callstack either: there are callbacks being setup and called.

There's one small consolation in all this: all refspecs are match
match the !is_url() condition in transport.c:939 get_transport(), and
no preceding conditions.  This means that there is one place to check
if it could possibly be a ref, that's not very deep in the callstack,
and return something to the caller appropriately.  Currently,
get_transport() always returns a valid struct transport with no extra
information; maybe we can change this?

Duy's approach of using a special "-" is trivial to implement, but
doesn't make me happy.  There's no reason I can't have 'git push
master +pu foo:bar'.

Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to