Re: How can git pull be up-to-date and git push fail?

From: Junio C Hamano <junkio@cox.net>
Date: Apr 7, 2007, 21:26 UTC
Message-ID: <7vy7l3c1uz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070407170702.GC18972@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 21 quoted lines

> On Fri, Apr 06, 2007 at 02:44:02PM -0700, Junio C Hamano wrote:
>
>> was no "git push" wrapper).  Back then, the expected use was
>> really:
>
> Thanks for this for the historical information.
>
>> So I'd suspect "git push" (not limited to git-send-pack) without
>> explicit refspecs should only do "matching branch heads" these
>> days, to keep the original spirit but yet to adjust to today's
>> reality....
>
> Agreed. That was actually my initial feeling, but it meant changing the
> semantics of all of the other parts of the refs/* hierarchy with respect
> to publishing, which I was a bit nervous about.
> ...
> BTW, my gut feeling is that send-pack is plumbing, and git-push is
> porcelain, and therefore the decisions about what to push should be made
> at the push layer, and send-pack should only push what it is explicitly
> told to push. But changing the defaults of send-pack at this point is
> probably a bad idea.

Yes, that is exactly why I suggested "git push" without explicit refspecs to drive the plumbings to push only matching branches. So if you are worried about breaking backward compatibility for real men (iow people who use git-send-pack directly), it would be a less impact change to (1) add --matching-heads option to send-pack and perhaps http-push, and change their behaviour only in that case, and (2) pass that option when git-push did not get explicit refspecs to send from the user, either from the command line nor from the config.