Jeff King <peff@xxxxxxxx> writes:
> ... In fact, I half-expected this to
> just work without a patch, since "git push origin HEAD" already works.
> However, we don't treat command line refspecs and config refspecs the
> same way, which IMHO is a needless inconsistency. How about this:
>
> diff --git a/builtin-push.c b/builtin-push.c
> index 9f727c0..ca90150 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -68,8 +68,7 @@ static int do_push(const char *repo, int flags)
> if (!refspec
> && !(flags & TRANSPORT_PUSH_ALL)
> && remote->push_refspec_nr) {
> - refspec = remote->push_refspec;
> - refspec_nr = remote->push_refspec_nr;
> + set_refspecs(remote->push_refspec, remote->push_refspec_nr);
> }
> errs = 0;
> for (i = 0; i < remote->url_nr; i++) {
Yeah, we are on the same page. See the patch I sent out last night ;-)
> At which point this now works as you described:
>
> git config remote.origin.push HEAD
Exactly.
>> I was hoping we can do without the "remote.*.push = HEAD" if we
>> can detect the remote is a shared repository while talking to
>> it, but I think it is a bit too much magic, because we cannot
>> visualize what the pushing side and the receiving side are
>> negotiating.
>
> How are you detecting that the remote is a shared repository?
I am not. I only said "... may even be able to" ;-).
The autodetection is not even the first step to tackle this
issue anyway. The "HEAD" magic (or if somebody comes up with a
better design, that one) comes first, deciding if such an
autodetection is even a good idea comes next, and then iff we
decide that it is a good idea finally comes the task of finding
out how we do so.
I'd presume that the upload-pack side can internally check "int
shared_repository" and the protocol extension that conveys that
information to the other end is easy enough. As always, dumb
transports are second class citizens and need their own hacks.
> By the core.sharedrepository config option? I use several
> shared repositories, and I never set that variable; instead
> ...
It is _your_ problem that you do not use published interface,
isn't it?
-
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
