Re: Minor annoyance with git push
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 20, 2008, 17:54 UTC
- Message-ID
- <7vk5kz7btw.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20080220140306.GA6928@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> ... 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.
Show 7 quoted lines
>> 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?