Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:<dst>"

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 5, 2018, 12:29 UTC
Message-ID: <xmqq4lcviu6l.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <87k1lr7obd.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 9 quoted lines

> After all sometimes "other" is just the repo on my laptop or server. I
> shouldn't need to jump through hoops to re-push stuff from my "other"
> repo anymore than from the local repo.
>
> Yes refs/remotes/* isn't guaranteed to be "other repo's branches" in the
> same way our local refs/heads/* is, and this series bends over backwards
> to check if someone's (ab)used it for that, but I think for the purposes
> of the default UI we should treat it as "branches from other remotes" if
> we find commit objects there.

I do not think there is *any* disagreement between us that refs/remotes/* is where somebody else's branches are stored.

The fundamental difference between us is what this "push" is doing.

You are limiting yourself to a single use case where you push to publish to the remote repository, as if the work on somebody else's commit were exactly like your own, hence you believe the push should go to refs/heads/* of the receiving repository.

I am also allowing an additional use case I often have to use, where I emulate a fetch done at the receiving repository by pushing into it. I have refs/remotes/* by fetching somebody else's branches locally, and instead of doing the same fetch over there by logging into it and doing "git fetch" interactively, I push refs/remotes/* I happen to have locally into refs/remotes/* there.

And I happen to think both are equally valid workflows, and there is no strong reason to think everybody would intuitively expect a push of my local refs/remotes/* will go to refs/heads/* of the receiving repository like you do. I'd rather want to make sure we do not make wrong guesses and force the user to "recover".

> So I think the *only* thing we should be checking for the purposes of
> this DWYM feature is what local type of object (branch or tag) we find
> on the LHS of the refspec. And if we're sure of its type push to
> refs/{heads,tags}/* as appropriate.

That is insufficient as long as you do not consider refs/remotes/* as one of the equally valid possibilities that sits next to refs/heads and res/tags/.