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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
